Bitcoin Wiki - User contributions [en]

Hardfork Wishlist

2014-01-24T06:50:08Z

WargeGeoshington: /* Transaction behavior changes */ nevermind, see how achievable in soft-fork now

The '''Hardfork Wishlist''' is to record changes to Bitcoin that might be desirable, but that will require a "hard" block-chain split (everybody must upgrade, old software will not accept blocks/transactions created with the new [[Protocol rules|rules]], considering them to be [[Invalid block|invalid blocks]]).

This page is ''not'' for changes that can be accomplished in way that is compatible with old software (for example, by making transactions [[Nonstandard block|nonstandard]] or by [[Discouraged block|discouraging blocks]]).

== Changes to hard-coded limits ==
* Replace hard-coded maximum block size (1,000,000 bytes) and maximum number of signature operations per block (20,000) with ???.

== Major structural changes ==
* "Flip the chain", instead of committing to new transactions, commit to the summaries of open transactions: [https://bitcointalk.org/index.php?topic=505.0] [https://bitcointalk.org/index.php?topic=21995.0] [https://en.bitcoin.it/wiki/User:DiThi/MTUT#PROPOSAL:_Merkle_tree_of_unspent_transactions_.28MTUT.29.2C_for_serverless_thin_clients_and_self-verifiable_prunned_blockchain.] [https://bitcointalk.org/index.php?topic=88208.0]
* Increased efficiency for merged mining: restructure the primary header to make the bitcoin specific data non-mandatory. (e.g. the block chain specific stuff would go into second header connected by a header tree), making the primary headers pure timestamps and nonces.
* Switch to block hashing algorithm secure against block withholding attacks.

== Transaction behavior changes==
* Improved signature types to allow for partial malleability of outputs. (e.g. make it easier to add a fee onto someone elses transaction, or to take fees from a transaction without outputs set aside for that putpose)
* Elimination of output scripts: all transactions pay-to-scripthash, probably with a single byte indicating the scripthash type. Other than reducing effective output script secrecy (which is not possible without OP_EVAL anyways) this is believed to be costless, and the secrecy can be recovered with recursive OP_EVAL. The motivation here is that data in outputs is far more expensive than inputs because some outputs may be never prunable, and pay-to-scripthash minimizes output size without harming total size.
* Allow soft-spending of generation outputs without confirmations (outputs of these transactions might also appear as generation themselves)
* Allow additional inputs to generation transactions
* Add new signature hashtype to include value of TxOut being spent, in the hash to be signed. Doing this would remove the requirement that offline signing devices be sent all supporting transactions with the transaction-to-be-signed, just to confirm the transaction fee.

== Cryptographic changes==
* Pervasive ECC public key-recovery to reduce transaction sizes (can be done partially without breaking compatibility completely)
* [http://ed25519.cr.yp.to/ Ed25519] (variant*) for much faster validation operations. (variant because the normal way Ed25519 is specified is not key recovery compatible)
* Support for a post-quantum signature scheme. [http://en.wikipedia.org/wiki/Lamport_signature Lamport signatures] have nice intuitive security properties, but it and all other similar schemes have extreme space requirements that would require structural changes to the blockchain to accommodate, (e.g. flip-chain+paytoscripthash+extensive pruning). Additional signature types could be kludged into the existing system with script extensions but would be better supported natively.

== Currency changes==
''Please don't list anything here which would significantly change the committed overall economics of the system, it's safe to assume anything with significant economic impact will _never_ be changed in Bitcoin<ref>[http://bitcointalk.org/index.php?topic=45468.msg542375#msg542375 Suggested MAJOR change to Bitcoin]</ref>, because such changes would undermine the trust people have in the system, though they may form the basis of an interesting [[alternative chain]].
* Increase currency divisibility.

== Navel gazing / Protocol housekeeping==
* Byte order consistency (big endian)
* Eliminate redundancies in the variable length integer encodings, possibly switch to a standard.
* Avoiding hashes covering malleable fields

== Bug fixes ==
* CHECKMULTISIG popping one-too-many items off the stack
* Difficulty adjustment periods should overlap (prevent potential 'timejacking') Note: An ideal adjustment algorithm would ensure there is no easy dispute on "next target" for any block. Eg, it should not be possible for MinerX to set his block time 2 hours in the future to achieve a slightly higher difficulty and win any same-block-height race by default.
* Difficulty adjustment should adapt to sudden hashrate loss. Note: all altchains which have attempted this have created significant security vulnerabilities in the process. Also interested parties could encourage mining by including high fee transactions in every block so avoiding need for this change.
* Scripts should be fully enabled after a careful audit.
* Miners/relays should not be able to inject extra arbitrary data into transactions?
* Use the previous block hash as an explicit or implicit prev_in in coinbases when hashing them to make it ~impossible to get a duplicate coinbase, thus removing the need for a pruning node to remember coinbase hashes to prevent duplicates consistently with the rest of the network
* coinbases must be parseable.
This changes would involve converting old blocks:
* uint64_t for timestamp field in blocks.

==See Also==
*[[Prohibited changes]]

==References==
<references />

[[Category:Technical]]
[[Category:Developer]]

Hardfork Wishlist

2014-01-24T03:59:48Z

WargeGeoshington: /* Transaction behavior changes */ permanent-forwarding-order idea

The '''Hardfork Wishlist''' is to record changes to Bitcoin that might be desirable, but that will require a "hard" block-chain split (everybody must upgrade, old software will not accept blocks/transactions created with the new [[Protocol rules|rules]], considering them to be [[Invalid block|invalid blocks]]).

This page is ''not'' for changes that can be accomplished in way that is compatible with old software (for example, by making transactions [[Nonstandard block|nonstandard]] or by [[Discouraged block|discouraging blocks]]).

== Changes to hard-coded limits ==
* Replace hard-coded maximum block size (1,000,000 bytes) and maximum number of signature operations per block (20,000) with ???.

== Major structural changes ==
* "Flip the chain", instead of committing to new transactions, commit to the summaries of open transactions: [https://bitcointalk.org/index.php?topic=505.0] [https://bitcointalk.org/index.php?topic=21995.0] [https://en.bitcoin.it/wiki/User:DiThi/MTUT#PROPOSAL:_Merkle_tree_of_unspent_transactions_.28MTUT.29.2C_for_serverless_thin_clients_and_self-verifiable_prunned_blockchain.] [https://bitcointalk.org/index.php?topic=88208.0]
* Increased efficiency for merged mining: restructure the primary header to make the bitcoin specific data non-mandatory. (e.g. the block chain specific stuff would go into second header connected by a header tree), making the primary headers pure timestamps and nonces.
* Switch to block hashing algorithm secure against block withholding attacks.

== Transaction behavior changes==
* Improved signature types to allow for partial malleability of outputs. (e.g. make it easier to add a fee onto someone elses transaction, or to take fees from a transaction without outputs set aside for that putpose)
* Elimination of output scripts: all transactions pay-to-scripthash, probably with a single byte indicating the scripthash type. Other than reducing effective output script secrecy (which is not possible without OP_EVAL anyways) this is believed to be costless, and the secrecy can be recovered with recursive OP_EVAL. The motivation here is that data in outputs is far more expensive than inputs because some outputs may be never prunable, and pay-to-scripthash minimizes output size without harming total size.
* Allow soft-spending of generation outputs without confirmations (outputs of these transactions might also appear as generation themselves)
* Allow additional inputs to generation transactions
* Add new signature hashtype to include value of TxOut being spent, in the hash to be signed. Doing this would remove the requirement that offline signing devices be sent all supporting transactions with the transaction-to-be-signed, just to confirm the transaction fee.
* Allow a "permanent forwarding order" in the blockchain, which by-rule irrevocably declares that any future transaction outputs directed at the retired-target are no longer spendable via the old key, but some new replacement key. (Requires hard-fork because older software oblivious to the forwarding-order could create or accept/forward blocks with no-longer-valid transactions through a forwarded address.)

== Cryptographic changes==
* Pervasive ECC public key-recovery to reduce transaction sizes (can be done partially without breaking compatibility completely)
* [http://ed25519.cr.yp.to/ Ed25519] (variant*) for much faster validation operations. (variant because the normal way Ed25519 is specified is not key recovery compatible)
* Support for a post-quantum signature scheme. [http://en.wikipedia.org/wiki/Lamport_signature Lamport signatures] have nice intuitive security properties, but it and all other similar schemes have extreme space requirements that would require structural changes to the blockchain to accommodate, (e.g. flip-chain+paytoscripthash+extensive pruning). Additional signature types could be kludged into the existing system with script extensions but would be better supported natively.

== Currency changes==
''Please don't list anything here which would significantly change the committed overall economics of the system, it's safe to assume anything with significant economic impact will _never_ be changed in Bitcoin<ref>[http://bitcointalk.org/index.php?topic=45468.msg542375#msg542375 Suggested MAJOR change to Bitcoin]</ref>, because such changes would undermine the trust people have in the system, though they may form the basis of an interesting [[alternative chain]].
* Increase currency divisibility.

== Navel gazing / Protocol housekeeping==
* Byte order consistency (big endian)
* Eliminate redundancies in the variable length integer encodings, possibly switch to a standard.
* Avoiding hashes covering malleable fields

== Bug fixes ==
* CHECKMULTISIG popping one-too-many items off the stack
* Difficulty adjustment periods should overlap (prevent potential 'timejacking') Note: An ideal adjustment algorithm would ensure there is no easy dispute on "next target" for any block. Eg, it should not be possible for MinerX to set his block time 2 hours in the future to achieve a slightly higher difficulty and win any same-block-height race by default.
* Difficulty adjustment should adapt to sudden hashrate loss. Note: all altchains which have attempted this have created significant security vulnerabilities in the process. Also interested parties could encourage mining by including high fee transactions in every block so avoiding need for this change.
* Scripts should be fully enabled after a careful audit.
* Miners/relays should not be able to inject extra arbitrary data into transactions?
* Use the previous block hash as an explicit or implicit prev_in in coinbases when hashing them to make it ~impossible to get a duplicate coinbase, thus removing the need for a pruning node to remember coinbase hashes to prevent duplicates consistently with the rest of the network
* coinbases must be parseable.
This changes would involve converting old blocks:
* uint64_t for timestamp field in blocks.

==See Also==
*[[Prohibited changes]]

==References==
<references />

[[Category:Technical]]
[[Category:Developer]]

Distributed markets

2013-10-26T04:14:49Z

WargeGeoshington: /* Detour: a financial distributed hashmap */ bitcoin-based insertion/leases

Bitcoin allows us to create '''distributed markets''' for the trading of securities, like stocks and bonds. Such markets have no central clearing house and can support securities of a size too small to be practical with todays techniques. It's also possible to build a P2P replacement for ''investment funds''.

This page was written by [mailto:mike@plan99.net Mike Hearn]. Contact him if you have any questions. Jeff Garzik has started implementing some of these ideas in his [https://github.com/jgarzik/smartcoin smartcoin] project.

== Introduction ==

Let's start by defining some terms.

A ''bond'' is a securitized loan. That means somebody who wants a loan can sell some bonds and whoever owns that bond receives the re-payments and any interest that accrues. The bond, being an asset like any other, is transferable - if you get tired of receiving the repayments you can sell the bond to somebody else. Once the full amount of the bond has been repaid, we say it has reached maturity. Some bonds never mature and yield interest payments in perpetuity.

A ''stock'' is somewhat similar to a bond, except it never matures, yields irregular dividend payments instead of regular interest payments and confers voting rights upon the owner. In this document we will talk mostly about bonds, but the same ideas can be applied to build a stock market too.

A ''ratings agency'' evaluates the creditworthiness of bond sellers and assigns bonds a consistent score (AAA, AA, junk, etc).

''Sahai-Waters CP-ABE'' is a recent advance based on pairing-based encryption. Standard Bitcoin payments are point-to-point: I must know the target of my payment by knowing their key/address, and then I can send value to that target alone. Bitcoin script allows some flexibility, eg, by allowing threshold signatures or password based coins. But we lack the ability to pay to anyone who satisfies an arbitrary policy. Ciphertext-policy attribute based encryption (CP-ABE) allows you to encrypt some data such that anyone in possession of a key with attributes that match a formula can decrypt it.

== Detour: a financial distributed hashmap ==

A common problem encountered when designing advanced financial markets on top of Bitcoin is the need for a place to temporarily store small pieces of data, keyed by hash. This is because the block chain is not always the right place to put non-trivial amounts of data. The Kademlia protocol and similar designs have solved this problem, albiet in a way that is vulnerable to a variety of DoS and Sybil attacks. But there is no network designed specifically for use in Bitcoin related systems. Today, their most common usage is in file sharing networks that are typically used for copyright infringement.

A separate Kademlia network can be built that is optimized solely for financial usage. Nodes would restrict the size of the stored data and artificially throttle the serving of it, thus discouraging storage of movies, games, MP3s and other such things. Initial insertion or value longevity could be made subject to proof of a Bitcoin stake (aged balances or posted bond), deterring garbage. This means users who are interested in the financial applications but don't wish to assist file sharing can donate their resources to the network without issue.

== A P2P bond network ==

We start with the familiar structure of an independent P2P broadcast network that connects to the financial hashmap. There is no need for an alternative block chain. Bonds can be modeled as if they were [[Smart Property]].

<nowiki>
message OutPoint {
required bytes tx_hash = 1;
required int index = 2;
}

message Issuer {
enum AuthType {
PUBLIC_KEY,
EMAIL_ADDRESS,
// Could add more in future, like EV SSL.
}
required AuthType auth_type = 1;

// Only one of the following should be set, according to authtype.
optional bytes pubkey = 2;
optional string email = 3;

// Name of the issuer as it will appear in the software, eg, a real name or company name.
required string display_name = 4;
// The script the issuer wants to receive the payments on.
required bytes pay_to_script = 5;
}

message Bond {
required OutPoint start_point = 1;
required Issuer issuer = 3;
required int value = 2;
required int coupon_value = 3;

// You could model more complex repayment schedules in future.
required int repayment_value = 4;

// UNIX time of when the bond was issued.
required int timestamp = 5;

// URL of the peer issuing the bond. This can be http://<home ip>:12345/ or
// perhaps a Tor onion address.
required string peer_url = 6;
}
</nowiki>

The issuer, timestamp and value fields should be self explanatory. The bond message would be inserted into the hashmap so others who know its hash can find it.

The start point identifies an output on the Bitcoin network that is created by the bond issuer. That output has a special form: it is of zero value and contains a script like this:

"BOND" <hash of bond message> 2DROP <issuer pubkey> CHECKSIG

This output tracks the current owner of the bond. The owner receives the repayments and any accrued interest. Of course a newly issued bond is special, it starts out being owned by the issuer.

The bond market client app that runs on your desktop follows the block chain, looking for Bitcoin transactions of that form. When it finds one, it downloads the bond message from the hashmap and shows the details in the UI.

If the bond owner wishes to sell the bond, a sale message is broadcast on the exchange p2p network:

<nowiki>
message ProposedBondSale {
required bytes bond_hash = 1;
required int requested_value = 2;
required bytes pay_to_script = 3;
required string peer_url = 4;
}
</nowiki>

If somebody wishes to buy that bond and sees the broadcast, they construct a transaction that spends requested_value of their own money to the pay_to_script, and add an input that connects to the zero-valued output of the current bondholder, and adds an output of the same BOND form to their own key. They pass it to the selling peer who checks that it looks valid and if so, signs for it then broadcasts thus atomically transferring the bond and the money.

By scanning the block chain for payments to the current owner of the bond, and checking them against the repayment schedule, the software can automatically calculate which bonds are delinquent and which are mature. Issuers of delinquent bonds would show up in the UI as in debt until sufficient sums were paid to the owners pubkey.

== Pay to policy outputs ==

Creating a decentralized bond market is a good start, but real financial markets are more complex. Often there is a layer of abstraction between buyer and seller: an investment fund. The funds encapsulate general instructions from the clients, such as "buy low risk municipal bonds" or "invest in energy stocks" and translates that into a stream of purchases and sales of specific assets. Funds compete on how they choose the specific assets and therefore what return they get.

Bitcoin payments today must be to a specific, concrete owner. By combining Bitcoin with CP-ABE we can instead make payments to a '''policy'''. A policy is a formula over a set of attributes. Attributes are arbitrary strings or string=integer pairs. Example policies include:

# ''ceo or (accounts_department AND manager)'' - a policy that allows the CEO of the company access, or a manager in the accounts department, but not any other kind of manager or member of accounting.
# ''master_key OR (3 OF (a, b, c, d, e))'' - a threshold policy that is overridable by a master key. Your key must have at least 3 of the 5 lettered attributes to be usable.
# ''verification_class=MtGoxBasicKYC AND common_name=MikeHearn AND access_level > 5'' - a policy that requires a key with a basic identity assertion of a specific name, verified according to the MtGox basic class, and which has an "access level" above a certain number.
# ''debt_rating(bobs_rating_agency) > 3 AND mining_bond AND interest_rate > 2300 AND interest_rate < 5000 AND repayment_months < 6'' - a policy stating that it can be unlocked by anyone in posession of a key that asserts it was issued for a mining bond with better than a rating of "3" (imagine an AAA like rating system), that will repay fully within 6 months and with an interest rate between 2.3 and 5%.

The policy is encoded into the ciphertext at encryption time, and the result can only be unlocked by a key that matches the policy. Keys attributes are assigned by an issuing authority.

It may at first appear that some of the policies expressed above are also expressable with script. For instance, if each attribute is considered to be a separate private key, you could try expressing the first example as a script that uses some CHECKSIGs along with boolean operators. But there are some problems with that approach.

The first problem is that people can collude to give themselves "superkeys". The Sahai-Waters scheme is collusion-resistant. In the first example, a manager who is not in accounting could team up with somebody who's not a manager but in the right department, and combine their keys to be able to spend the companies money. With CP-ABE the keys cannot be combined to merge attributes like that.

The second problem is that script cannot contain signatures over anything other than transactions, and only limited forms at that. So you cannot have numeric assertions in outputs because you have no way to verify the inputs are legitimate.

The third problem is that script rapidly becomes inefficient if you want complex policies over hundreds or thousands of attributes. CP-ABE policies can be quite large whilst remaining feasible.

There is a final reason to explore CP-ABE: whilst keys cannot be merged together to elevate privilege, you ''can'' remove attributes and thus delegated weakened power to others. In the first example, the manager of the accounts department does not need to get a new key issued from the key authority when a new employee joins: he can just remove the "manager" attribute from his key and generate a new key for the employee himself.

In the straightforward CP-ABE scheme, there must be exactly one key issuing authority that verifies the client deserves the attributes they're about to be given and then mints the keys. It is possible to decentralize the scheme to become [http://eprint.iacr.org/2010/351.pdf multi-authority CP-ABE] using the Lewko-Waters design.

Whilst some ABE schemes allow for hiding of the policy, the most expressive types make the policy public as part of the ciphertext. Fortunately this constraint is not a problem for us, indeed, it is an advantage.

An implementation of single-authority CP-ABE (as well as KP-ABE where keys contain policies and ciphertexts contain attributes) is available in [http://code.google.com/p/libfenc/ libfenc]. Multi-authority CP-ABE is available in a Python library called Charm. There are obviously many applications of this technique. Here we will explore only one.

== Investment funds ==

Rather than wait for specific bonds to become available and then manually evaluate each one by hand, we can construct a kind of distributed investment fund by sending money to a Bitcoin private key that is then encrypted under a policy and uploaded into the financial hashmap:

"POLICY" <hash of InvestmentFundAdvertisement message> 2DROP <pubkey> CHECKSIG

Policy-locked ciphertexts are potentially quite large, depending on the size of the policy (a comparison against a large number like a date can use over a kilobyte), so it makes sense to use the same hash disassociation used in the bond protocol above in order to minimize block chain size.

The hash would actually identify a data structure containing the ciphered private key:

<nowiki>
message InvestmentFundAdvertisement {
required bytes owner_pubkey = 1; // The key that will control the bond once sold.
required bytes ciphertext = 2; // Policy is embedded within this.
}
</nowiki>

As the bond market client crawls the block chain, it may encounter policy locked coins. By downloading the ciphertext from the hashmap, it can identify what conditions would unlock the coins and advertise that in the client. Somebody who is looking for business opportunities may see a message like this in their GUI:

There are ''200 BTC'' available to any bond issuer meeting the following criteria:
# Must be a mining bond.
# Must be repaid entirely within 6 months.
# Must yield an interest rate between 2.3% and 5%
# Debt must be rated as AA or better by one of {MtGox Ratings, Moodys, Standard&Poors}.
# These assertions must have been issued within the last month

Therefore demand is communicated to suppliers. By submitting such policy-locked coins, investors can send a message to the markets indicating that more mining capacity should be built.

To be able to find the private key and take the coins, you must obtain a key that matches these attributes by talking to the various issuing authorities. Once you have such a key, any coins sent to such a policy can be taken by yourself. By requiring attributes such as "issued_in=2012/06" the policies can be expired when needed (at the cost of an additional block chain transaction to update the hash).

Talk:Hardfork Wishlist

2013-08-15T02:17:05Z

WargeGeoshington: /* 'Permanent Forwarding' */ clarifying wording of last comment inplace

==Proposals which reduce security==
"Difficulty adjustment should adapt to sudden hashrate loss"

It's really hard to construct ''general'' proofs, but I believe that _all_ such schemes substantially reduce the cost of performing forged chain attacks against isolated nodes. I gave an argument of this here, assuming a particular decrease handling improvement: [https://bitcointalk.org/index.php?topic=46498.msg556137#msg556137]

Beyond those problems schemes with asymmetric difficulty creates non-linearities which make it profitable for miners as a group to game the system: e.g. turn off until it falls fast, then turn on until it catches back up. The current mostly linear system doesn't enable this even if the miners conspire.

One of my concerns about this page is that lots of ideas sound just fantastic until you consider their costs, or sound great so long as you don't mind their particular costs. Because these changes must be adopted by consensus and because people evaluate costs differently it's hard to find things that win the cost/benefit analysis for almost everyone.

In my opinion, the drop risk is inconsequential: Having the average txn time go to 20 minutes for a month isn't really a big deal... and if there is a bigger drop then the slow txn processing time will be the least of our problems. The costs here are not speculative, altchains with "improved" difficulty adjustments have been exploited several times. The benefit is purely speculative and primarily matters only if bitcoin is already failing.

Perhaps we should change the page to tabular layout so that we can link to for and against arguments for features where ones exist? --[[User:Gmaxwell|Gmaxwell]] 19:59, 4 January 2012 (GMT)

:And yet another variant of this: * Replace the 10 minute block finding target with a dynamic target decided by the market [https://bitcointalk.org/index.php?topic=79837.0]. This one misses that the interblock time is important for convergence, also a naive implementation would change the payout schedule. --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 03:03, 28 July 2012 (GMT)

Trying to eliminate hard-coded time parameters means working in the "Partially Synchronous" communications model [http://www.podc.org/dijkstra/2007.html]. It's also equivalent to building a "partition tolerant" system in the sense of P in the CAP theorem. This is a difficult problem, and most proposed solutions to it are going to be broken. Still it's a fundamental goal, and it deserves its own section in the wishlist.
--[[User:Amiller|Amiller]] ([[User talk:Amiller|talk]]) 08:46, 9 August 2012 (GMT)

===OP_FAIL FAILS===

I've removed this suggestion:

<blockquote>
'''Futureproofing'''
* Add a few new opcodes called OP_FAIL''n'' or repurpose them from OP_NOP''n''. These would immediately fail a transaction, and like OP_NOP''n'', would be available as new opcodes for future purposes, but without the burden of old clients dangerously understanding them as "do nothing".
</blockquote>

Because it's idiotic. You could already use undefined opcodes for this— but even that is stupid, the reason the the OP_NOPs are useful for futureproofing is specifically because they pass. The fact that they pass is what enables you to run a mixed network. If you use an opcode that always fails for old nodes as an extension mechanism the instant that it gets mined the network forks. --[[User:Gmaxwell|Gmaxwell]] 17:13, 19 February 2012 (GMT)

== Removed 'Proof of Stake' ==

I've removed:
* Augment [[Proof of work]] with [[Proof of Stake]] as the mechanism for generating blocks.

As non-viable due to being economically significant. --[[User:Gmaxwell|Gmaxwell]] 14:42, 12 March 2012 (GMT)

Economic theory unambiguously indicates that the current protocol will fail eventually. It will need to be changed either before or when this happens.
A proof-of-stake system is likely the only viable long-term solution. Preparing for a forseeable problem is only prudent. --[[User:Cunicula|Cunicula]] 7 April 2012

== Merkle trees, lite clients, coinbase commitments, UTXOs ==

There have been at least four generations now of essentially the same proposal. I just added etotheipi's and DiThi's. The language for them has changed has many times. Should this be consolidated somewhere else? For what it's worth, I now prefer "hash graph" as the general term including chains, trees, and skiplists.
--[[User:Amiller|Amiller]] ([[User talk:Amiller|talk]]) 08:37, 9 August 2012 (GMT)

== 'Permanent Forwarding' ==

As roughly sketched in the proposal bullet, this proposes some kind of new blockchain transaction-like directive to indicate permanent retirement of an old key and by-rule delegation of outputs to a new key. (This could solve some usability problems with prominently-advertised, but then lost or compromised, or suspected-compromised, keys.)

This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. [[User:WargeGeoshington|WargeGeoshington]] ([[User talk:WargeGeoshington|talk]]) 10:52, 13 June 2013 (GMT)

* Something like this really makes sense as a higher level of abstraction - part of a merged-mined timestamp block, for example. Clients would just consult this database for forwarding information when sending, and use the output for the new destination instead. It doesn't need to involve miners or other nodes at all. Even if you wanted miners to block sending to the forwarded output, that would be at most a soft-fork (making something formerly legal, now illegal). BUT, since addresses are single-use, I'm not sure it makes sense to do this at the address level at all - and it's effectively "default" in the payment protocol. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 19:11, 13 June 2013 (GMT)

:: The idea that it's sender's responsibility to check some database is interesting... but makes senders reliant on having a full copy of this arbitrarily-large database. (It destroys the useful property, "all I need is to know my own inputs", for sending.) And what of old clients/nodes/miners that don't know to check the forwarding-database? They issue bad transactions to dead addresses. They'll mine/forward bad blocks with transactions related to dead-addresses, rejected by newer software. Meanwhile, even if the forwarding notation is squeezed into blocks in a backward-compatible (or by-indirect-reference) fashion, as soon as someone spends an auto-forwarded-by-rule amount, that transaction looks illegal to old nodes, causing old nodes to reject post-forwarding blocks. Pre-feature and post-feature software can't understand each others' blockchains, and grow indepedently if people keep running the old software. Isn't that the very definition of a 'hard fork'? (If not, can you fill me in with a better definition?)

:: In idealized theory -- and perhaps in Satoshi's vision -- addresses are single-use. But that's not protocol-required and in practice, many users/apps reuse addresses and advertise long-lived addresses... which gives rise to the exact security/usability problem this proposal attempts to address.

:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington|WargeGeoshington]] ([[User talk:WargeGeoshington|talk]]) 05:15, 15 June 2013 (GMT)

*** You can break address-compatibility without a hardfork. A soft-fork is sufficient to ban usage of forwarded addresses, as well. As new features such as HD wallets and the payment protocol becomes more widespread, address reuse should quickly decline out of usage anyway, making this a solution begging for a problem in the long-term (and remember, a hardfork is a long-term thing...). --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 02:50, 16 June 2013 (GMT)

:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington|WargeGeoshington]] ([[User talk:WargeGeoshington|talk]]) 18:42, 12 August 2013 (GMT)

***** A hard fork is where the blockchain protocol changes such that blocks which were considered invalid previously, are now considered valid. Addresses are a concept that don't even enter into the equation really. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 07:27, 13 August 2013 (GMT)

:::::: Exactly, so a public, permanent forwarding order, via a new directive in the blockchain, would be seen as invalid to (or cause malfunction by) old software. Alternatively, a block created by old software, illegally spending from an address that's been permanently-forwarded, because the old software didn't recognize the forwarding-order, would be considered invalid to later software. Strong forwarding support means incompatible blocks. The wishlist idea is for this kind of strong protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington|WargeGeoshington]] ([[User talk:WargeGeoshington|talk]]) 02:14, 15 August 2013 (GMT)

Talk:Hardfork Wishlist

2013-08-15T02:14:42Z

WargeGeoshington: /* 'Permanent Forwarding' */

==Proposals which reduce security==
"Difficulty adjustment should adapt to sudden hashrate loss"

It's really hard to construct ''general'' proofs, but I believe that _all_ such schemes substantially reduce the cost of performing forged chain attacks against isolated nodes. I gave an argument of this here, assuming a particular decrease handling improvement: [https://bitcointalk.org/index.php?topic=46498.msg556137#msg556137]

Beyond those problems schemes with asymmetric difficulty creates non-linearities which make it profitable for miners as a group to game the system: e.g. turn off until it falls fast, then turn on until it catches back up. The current mostly linear system doesn't enable this even if the miners conspire.

One of my concerns about this page is that lots of ideas sound just fantastic until you consider their costs, or sound great so long as you don't mind their particular costs. Because these changes must be adopted by consensus and because people evaluate costs differently it's hard to find things that win the cost/benefit analysis for almost everyone.

In my opinion, the drop risk is inconsequential: Having the average txn time go to 20 minutes for a month isn't really a big deal... and if there is a bigger drop then the slow txn processing time will be the least of our problems. The costs here are not speculative, altchains with "improved" difficulty adjustments have been exploited several times. The benefit is purely speculative and primarily matters only if bitcoin is already failing.

Perhaps we should change the page to tabular layout so that we can link to for and against arguments for features where ones exist? --[[User:Gmaxwell|Gmaxwell]] 19:59, 4 January 2012 (GMT)

:And yet another variant of this: * Replace the 10 minute block finding target with a dynamic target decided by the market [https://bitcointalk.org/index.php?topic=79837.0]. This one misses that the interblock time is important for convergence, also a naive implementation would change the payout schedule. --[[User:Gmaxwell|Gmaxwell]] ([[User talk:Gmaxwell|talk]]) 03:03, 28 July 2012 (GMT)

Trying to eliminate hard-coded time parameters means working in the "Partially Synchronous" communications model [http://www.podc.org/dijkstra/2007.html]. It's also equivalent to building a "partition tolerant" system in the sense of P in the CAP theorem. This is a difficult problem, and most proposed solutions to it are going to be broken. Still it's a fundamental goal, and it deserves its own section in the wishlist.
--[[User:Amiller|Amiller]] ([[User talk:Amiller|talk]]) 08:46, 9 August 2012 (GMT)

===OP_FAIL FAILS===

I've removed this suggestion:

<blockquote>
'''Futureproofing'''
* Add a few new opcodes called OP_FAIL''n'' or repurpose them from OP_NOP''n''. These would immediately fail a transaction, and like OP_NOP''n'', would be available as new opcodes for future purposes, but without the burden of old clients dangerously understanding them as "do nothing".
</blockquote>

Because it's idiotic. You could already use undefined opcodes for this— but even that is stupid, the reason the the OP_NOPs are useful for futureproofing is specifically because they pass. The fact that they pass is what enables you to run a mixed network. If you use an opcode that always fails for old nodes as an extension mechanism the instant that it gets mined the network forks. --[[User:Gmaxwell|Gmaxwell]] 17:13, 19 February 2012 (GMT)

== Removed 'Proof of Stake' ==

I've removed:
* Augment [[Proof of work]] with [[Proof of Stake]] as the mechanism for generating blocks.

As non-viable due to being economically significant. --[[User:Gmaxwell|Gmaxwell]] 14:42, 12 March 2012 (GMT)

Economic theory unambiguously indicates that the current protocol will fail eventually. It will need to be changed either before or when this happens.
A proof-of-stake system is likely the only viable long-term solution. Preparing for a forseeable problem is only prudent. --[[User:Cunicula|Cunicula]] 7 April 2012

== Merkle trees, lite clients, coinbase commitments, UTXOs ==

There have been at least four generations now of essentially the same proposal. I just added etotheipi's and DiThi's. The language for them has changed has many times. Should this be consolidated somewhere else? For what it's worth, I now prefer "hash graph" as the general term including chains, trees, and skiplists.
--[[User:Amiller|Amiller]] ([[User talk:Amiller|talk]]) 08:37, 9 August 2012 (GMT)

== 'Permanent Forwarding' ==

As roughly sketched in the proposal bullet, this proposes some kind of new blockchain transaction-like directive to indicate permanent retirement of an old key and by-rule delegation of outputs to a new key. (This could solve some usability problems with prominently-advertised, but then lost or compromised, or suspected-compromised, keys.)

This new categorical directive would not be understood by older nodes/mining software, so they'd reject blocks containing the directive. Even if it could be crafted to be ignored by older nodes... they'd then accept transactions/blocks which spend outputs from the 'dead' key according to old rules, leaving contradictory info in the shared chain. Thus as far as I can tell, to work this feature requires a hard fork. Of course, if there's a way to implement the same benefit in a compatible way, I'd appreciate hearing about it here on the talk page or elsewhere on the wiki. [[User:WargeGeoshington|WargeGeoshington]] ([[User talk:WargeGeoshington|talk]]) 10:52, 13 June 2013 (GMT)

* Something like this really makes sense as a higher level of abstraction - part of a merged-mined timestamp block, for example. Clients would just consult this database for forwarding information when sending, and use the output for the new destination instead. It doesn't need to involve miners or other nodes at all. Even if you wanted miners to block sending to the forwarded output, that would be at most a soft-fork (making something formerly legal, now illegal). BUT, since addresses are single-use, I'm not sure it makes sense to do this at the address level at all - and it's effectively "default" in the payment protocol. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 19:11, 13 June 2013 (GMT)

:: The idea that it's sender's responsibility to check some database is interesting... but makes senders reliant on having a full copy of this arbitrarily-large database. (It destroys the useful property, "all I need is to know my own inputs", for sending.) And what of old clients/nodes/miners that don't know to check the forwarding-database? They issue bad transactions to dead addresses. They'll mine/forward bad blocks with transactions related to dead-addresses, rejected by newer software. Meanwhile, even if the forwarding notation is squeezed into blocks in a backward-compatible (or by-indirect-reference) fashion, as soon as someone spends an auto-forwarded-by-rule amount, that transaction looks illegal to old nodes, causing old nodes to reject post-forwarding blocks. Pre-feature and post-feature software can't understand each others' blockchains, and grow indepedently if people keep running the old software. Isn't that the very definition of a 'hard fork'? (If not, can you fill me in with a better definition?)

:: In idealized theory -- and perhaps in Satoshi's vision -- addresses are single-use. But that's not protocol-required and in practice, many users/apps reuse addresses and advertise long-lived addresses... which gives rise to the exact security/usability problem this proposal attempts to address.

:: So, you (and several others I've floated this to) think this is an "interesting idea". Maybe there's a way to do it with a soft fork (though I don't yet see it; it seems any such approach would be fragile or not offer the full benefits). There's a way to get the full benefits if it were in a 'hard fork'. So why shouldn't this idea appear on a page that's a unprioritized "wishlist", about changes that "might be desirable"? By deleting it you prevent evaluation and discussion of its possible value and possible implementations. --[[User:WargeGeoshington|WargeGeoshington]] ([[User talk:WargeGeoshington|talk]]) 05:15, 15 June 2013 (GMT)

*** You can break address-compatibility without a hardfork. A soft-fork is sufficient to ban usage of forwarded addresses, as well. As new features such as HD wallets and the payment protocol becomes more widespread, address reuse should quickly decline out of usage anyway, making this a solution begging for a problem in the long-term (and remember, a hardfork is a long-term thing...). --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 02:50, 16 June 2013 (GMT)

:::: Maybe we're using different definitions of hard vs. soft forks. I see a 'hard fork' as a situation where old software, if it keeps running as nodes/miners, generates transactions and blocks that are not accepted by the post-hard-fork mainline. (A compatibility break that forces upgrades.) Is this definition wrong or imprecise? If not, how would a soft fork prevent someone with non-upgraded software from (a) sending a payment to an obsolete address which is then (b) minted into a block by miners running the old software? [[User:WargeGeoshington|WargeGeoshington]] ([[User talk:WargeGeoshington|talk]]) 18:42, 12 August 2013 (GMT)

***** A hard fork is where the blockchain protocol changes such that blocks which were considered invalid previously, are now considered valid. Addresses are a concept that don't even enter into the equation really. --[[User:Luke-jr|Luke-jr]] ([[User talk:Luke-jr|talk]]) 07:27, 13 August 2013 (GMT)

:::::: Exactly, so a public, permanent forwarding order via a new feature in the blockchain would be seen as invalid to old software. (Alternatively, a block created by old software, spending from an address that's been permanently-forwarded because it didn't recognize the forwarding-order, would be considered invalid to later software.) The wishlist idea is for protocol-support for irreversible forwarding; how can that happen short of a hard fork? -[[User:WargeGeoshington|WargeGeoshington]] ([[User talk:WargeGeoshington|talk]]) 02:14, 15 August 2013 (GMT)

Talk:Hardfork Wishlist

2013-08-12T18:42:19Z

WargeGeoshington: /* 'Permanent Forwarding' */

Talk:Hardfork Wishlist

2013-06-15T05:15:17Z

WargeGeoshington: /* 'Permanent Forwarding' */ why proper 'forwarding' needs a 'hard fork' to work well

Talk:Hardfork Wishlist

2013-06-13T10:56:11Z

WargeGeoshington: more on pre/post forwarding incompatibility

Talk:Hardfork Wishlist

2013-06-13T10:52:35Z

WargeGeoshington: desire for explanation of why this interesting idea wouldn't need a hard fork

Hardfork Wishlist

2013-06-13T10:39:48Z

WargeGeoshington: I don't believe it can be done without a hard fork, I'd love to see ideas about it, maybe on the Discussion page?

This page is to record changes to Bitcoin that might be desirable, but that will require a "hard" block-chain split (everybody must upgrade, old software will not accept blocks/transactions created with the new [[Protocol rules|rules]], considering them to be [[Invalid block|invalid blocks]]).

This page is *not* for changes that can be accomplished in way that is compatible with old software (for example, by making transactions [[Nonstandard block|nonstandard]] or by [[Discouraged block|discouraging blocks]]).

====Changes to hard-coded limits====
* Replace hard-coded maximum block size (1,000,000 bytes) and maximum number of signature operations per block (20,000) with ???.

====Major structural changes====
* "Flip the chain", instead of committing to new transactions, commit to the summaries of open transactions: [https://bitcointalk.org/index.php?topic=505.0] [https://bitcointalk.org/index.php?topic=21995.0] [https://en.bitcoin.it/wiki/User:DiThi/MTUT#PROPOSAL:_Merkle_tree_of_unspent_transactions_.28MTUT.29.2C_for_serverless_thin_clients_and_self-verifiable_prunned_blockchain.] [https://bitcointalk.org/index.php?topic=88208.0]
* Increased efficiency for merged mining: restructure the primary header to make the bitcoin specific data non-mandatory. (e.g. the block chain specific stuff would go into second header connected by a header tree), making the primary headers pure timestamps and nonces.
* Switch to block hashing algorithm secure against block withholding attacks.

====Transaction behavior changes====
* Improved signature types to allow for partial malleability of outputs. (e.g. make it easier to add a fee onto someone elses transaction, or to take fees from a transaction without outputs set aside for that putpose)
* Elimination of output scripts: all transactions pay-to-scripthash, probably with a single byte indicating the scripthash type. Other than reducing effective output script secrecy (which is not possible without OP_EVAL anyways) this is believed to be costless, and the secrecy can be recovered with recursive OP_EVAL. The motivation here is that data in outputs is far more expensive than inputs because some outputs may be never prunable, and pay-to-scripthash minimizes output size without harming total size.
* Allow soft-spending of generation outputs without confirmations (outputs of these transactions might also appear as generation themselves)
* Allow additional inputs to generation transactions
* Add new signature hashtype to include value of TxOut being spent, in the hash to be signed. Doing this would remove the requirement that offline signing devices be sent all supporting transactions with the transaction-to-be-signed, just to confirm the transaction fee.
* Allow insertion of "permanent forwarding directive" transaction, so that a well-known public address with a (suspected or soon-to-be) compromised private key can be replaced for all signing/paying purposes with a new address. (This directive might only be insertable if approved by N-of-M prior declared guardian keys. The directive might involve a one-time fee, after which the old address is null and the new address replaces it in perpetuity, or might include a declared service fee that can be deducted to miners on each future use of the new-key to draw on dead-key outputs.)

====Cryptographic changes====
* Pervasive ECC public key-recovery to reduce transaction sizes (can be done partially without breaking compatibility completely)
* [http://ed25519.cr.yp.to/ Ed25519] (variant*) for much faster validation operations. (variant because the normal way Ed25519 is specified is not key recovery compatible)
* Support for a post-quantum signature scheme. [http://en.wikipedia.org/wiki/Lamport_signature Lamport signatures] have nice intuitive security properties, but it and all other similar schemes have extreme space requirements that would require structural changes to the blockchain to accommodate, (e.g. flip-chain+paytoscripthash+extensive pruning). Additional signature types could be kludged into the existing system with script extensions but would be better supported natively.

====Currency changes====
''Please don't list anything here which would significantly change the committed overall economics of the system, it's safe to assume anything with significant economic impact will _never_ be changed in Bitcoin<ref>[http://bitcointalk.org/index.php?topic=45468.msg542375#msg542375 Suggested MAJOR change to Bitcoin]</ref>, because such changes would undermine the trust people have in the system, though they may form the basis of an interesting [[alternative chain]].
* Increase currency divisibility.

====Navel gazing / Protocol housekeeping====
* Byte order consistency (big endian)
* Eliminate redundancies in the variable length integer encodings, possibly switch to a standard.
* Avoiding hashes covering malleable fields

====Bug fixes====
* CHECKMULTISIG popping one-too-many items off the stack
* Difficulty adjustment periods should overlap (prevent potential 'timejacking') Note: An ideal adjustment algorithm would ensure there is no easy dispute on "next target" for any block. Eg, it should not be possible for MinerX to set his block time 2 hours in the future to achieve a slightly higher difficulty and win any same-block-height race by default.
* Difficulty adjustment should adapt to sudden hashrate loss. Note: all altchains which have attempted this have created significant security vulnerabilities in the process. Also interested parties could encourage mining by including high fee transactions in every block so avoiding need for this change.
* Scripts should be fully enabled after a careful audit.
* Miners/relays should not be able to inject extra arbitrary data into transactions?
* Use the previous block hash as an explicit or implicit prev_in in coinbases when hashing them to make it ~impossible to get a duplicate coinbase, thus removing the need for a pruning node to remember coinbase hashes to prevent duplicates consistently with the rest of the network
* coinbases must be parseable.
This changes would involve converting old blocks:
* uint64_t for timestamp field in blocks.

==See Also==
*[[Prohibited changes]]

==References==
<references />

[[Category:Technical]]
[[Category:Developer]]

Hardfork Wishlist

2013-05-24T21:41:24Z

WargeGeoshington: /* Transaction behavior changes */ corrected bullet

Hardfork Wishlist

2013-05-24T21:40:46Z

WargeGeoshington: /* Transaction behavior changes */ permanent 'forwarding' of key privs

This page is to record changes to Bitcoin that might be desirable, but that will require a "hard" block-chain split (everybody must upgrade, old software will not accept blocks/transactions created with the new [[Protocol rules|rules]], considering them to be [[Invalid block|invalid blocks]]).

This page is *not* for changes that can be accomplished in way that is compatible with old software (for example, by making transactions [[Nonstandard block|nonstandard]] or by [[Discouraged block|discouraging blocks]]).

====Changes to hard-coded limits====
* Replace hard-coded maximum block size (1,000,000 bytes) and maximum number of signature operations per block (20,000) with ???.

====Major structural changes====
* "Flip the chain", instead of committing to new transactions, commit to the summaries of open transactions: [https://bitcointalk.org/index.php?topic=505.0] [https://bitcointalk.org/index.php?topic=21995.0] [https://en.bitcoin.it/wiki/User:DiThi/MTUT#PROPOSAL:_Merkle_tree_of_unspent_transactions_.28MTUT.29.2C_for_serverless_thin_clients_and_self-verifiable_prunned_blockchain.] [https://bitcointalk.org/index.php?topic=88208.0]
* Increased efficiency for merged mining: restructure the primary header to make the bitcoin specific data non-mandatory. (e.g. the block chain specific stuff would go into second header connected by a header tree), making the primary headers pure timestamps and nonces.
* Switch to block hashing algorithm secure against block withholding attacks.

====Transaction behavior changes====
* Improved signature types to allow for partial malleability of outputs. (e.g. make it easier to add a fee onto someone elses transaction, or to take fees from a transaction without outputs set aside for that putpose)
* Elimination of output scripts: all transactions pay-to-scripthash, probably with a single byte indicating the scripthash type. Other than reducing effective output script secrecy (which is not possible without OP_EVAL anyways) this is believed to be costless, and the secrecy can be recovered with recursive OP_EVAL. The motivation here is that data in outputs is far more expensive than inputs because some outputs may be never prunable, and pay-to-scripthash minimizes output size without harming total size.
* Allow soft-spending of generation outputs without confirmations (outputs of these transactions might also appear as generation themselves)
* Allow additional inputs to generation transactions
* Add new signature hashtype to include value of TxOut being spent, in the hash to be signed. Doing this would remove the requirement that offline signing devices be sent all supporting transactions with the transaction-to-be-signed, just to confirm the transaction fee.
• Allow insertion of "permanent forwarding directive" transaction, so that a well-known public address with a (suspected or soon-to-be) compromised private key can be replaced for all signing/paying purposes with a new address. (This directive might only be insertable if approved by N-of-M prior declared guardian keys. The directive might involve a one-time fee, after which the old address is null and the new address replaces it in perpetuity, or might include a declared service fee that can be deducted to miners on each future use of the new-key to draw on dead-key outputs.)

====Cryptographic changes====
* Pervasive ECC public key-recovery to reduce transaction sizes (can be done partially without breaking compatibility completely)
* [http://ed25519.cr.yp.to/ Ed25519] (variant*) for much faster validation operations. (variant because the normal way Ed25519 is specified is not key recovery compatible)
* Support for a post-quantum signature scheme. [http://en.wikipedia.org/wiki/Lamport_signature Lamport signatures] have nice intuitive security properties, but it and all other similar schemes have extreme space requirements that would require structural changes to the blockchain to accommodate, (e.g. flip-chain+paytoscripthash+extensive pruning). Additional signature types could be kludged into the existing system with script extensions but would be better supported natively.

====Currency changes====
''Please don't list anything here which would significantly change the committed overall economics of the system, it's safe to assume anything with significant economic impact will _never_ be changed in Bitcoin<ref>[http://bitcointalk.org/index.php?topic=45468.msg542375#msg542375 Suggested MAJOR change to Bitcoin]</ref>, because such changes would undermine the trust people have in the system, though they may form the basis of an interesting [[alternative chain]].
* Increase currency divisibility.

====Navel gazing / Protocol housekeeping====
* Byte order consistency (big endian)
* Eliminate redundancies in the variable length integer encodings, possibly switch to a standard.
* Avoiding hashes covering malleable fields

====Bug fixes====
* CHECKMULTISIG popping one-too-many items off the stack
* Difficulty adjustment periods should overlap (prevent potential 'timejacking') Note: An ideal adjustment algorithm would ensure there is no easy dispute on "next target" for any block. Eg, it should not be possible for MinerX to set his block time 2 hours in the future to achieve a slightly higher difficulty and win any same-block-height race by default.
* Difficulty adjustment should adapt to sudden hashrate loss. Note: all altchains which have attempted this have created significant security vulnerabilities in the process. Also interested parties could encourage mining by including high fee transactions in every block so avoiding need for this change.
* Scripts should be fully enabled after a careful audit.
* Miners/relays should not be able to inject extra arbitrary data into transactions?
* Use the previous block hash as an explicit or implicit prev_in in coinbases when hashing them to make it ~impossible to get a duplicate coinbase, thus removing the need for a pruning node to remember coinbase hashes to prevent duplicates consistently with the rest of the network
* coinbases must be parseable.
This changes would involve converting old blocks:
* uint64_t for timestamp field in blocks.

==See Also==
*[[Prohibited changes]]

==References==
<references />

[[Category:Technical]]
[[Category:Developer]]