Initial replace-by-fee implementation is now available on testnet

[Zeilap]

Is there a subtle issue with recursive fee calculation that's prevented it being implemented?

In fact I've already got most of a recursive fee calculation implementation written, including unit tests. But because recursive fee calc is required to make the patch robust against certain types of DoS attacks, I want to hold off on making that code available to give people time to experiment with tx replacement, in particular how they're merchant code handles it, while still discouraging miners from using it on mainnet. Similarly that vector-vs-set bug you found was a very nice catch, but again, I'm going to hold off fixing it for another two or three weeks.

Ok, I wrote some code to do it and was making sure I hadn't missed some obvious-to-you-but-not-me issue before creating a pull request.
I'll create a patch and send you privately instead - you may find it useful even if you've already done most of the work already.

[1713540029]

1713540029

[1713540029]

1713540029

[1713540029]

1713540029

[1713540029]

1713540029

[1713540029]

1713540029

[1713540029]

1713540029

[Matthew N. Wright]

http://bitcoin.stackexchange.com/questions/10733/what-is-replace-by-fee

Did you ask and answer that question yourself?

[Peter Todd]

How does this patch behave with regards to chained transactions?
Say the output of TX1 is spent in TX2 (both unconfirmed).
Now TX1 gets replaced - From my understanding of the code this means that TX2 can never confirm, because it's inpoints are not existing anymore. Or am i missing something?

Exactly. Basically when TX1 is removed, every transaction that depends on it gets removed too.

Sidenote:
Although i run myself a site which heavily relies on unconfirmed transactions I fully support implementing this. I agree with the opinion that this behaviour is inevitable in the future, so we should better prepare for it sooner than later. And if this means I have to close down or rewrite my site - so be it. Was fun while it lasted

Yeah, it's unfortunate there aren't any easy answers here. Had Satoshi done this from the start we would already have various solutions implemented, but now it will take some time to do so, and frankly there just won't be the consensus required to make any of those solutions without making the need clear first.

Having said that, if replace-by-fee is widely adopted many sites, particularly gambling, have an interesting option: withhold large winning payouts until the input transaction confirms, and if the customer tries to cancel the transaction the moment they see they have lost, create a "counter" double-spend that takes their full bet and sends it to fees. A rational miner will see your "punishment" transaction and mine that rather than the customers attempt at canceling the transaction.

There will be a window where not enough miners have adopted replace-by-fee to make this work reliably enough to be useful, but if adoption is high it's a pretty good solution. Just make sure you record every transaction so you can prove the customers fraud after the fact, and be careful to only create the punishment transaction if the txout to you, rather than the change txout, is modified. You'll also have to think a bit about how the winning number is calculated.

In any case for your site as always make sure you can detect double-spends so you can limit your losses when they start happening in large numbers.

[Peter Todd]

Ok, I wrote some code to do it and was making sure I hadn't missed some obvious-to-you-but-not-me issue before creating a pull request.
I'll create a patch and send you privately instead - you may find it useful even if you've already done most of the work already.

Thanks! My version is a pretty agressive mempool rewrite, so a simpler alternative would definitely be appreciated and valuable.

[Zaih]

Whilst I don't fully understand the concept behind this and why you're doing it, I don't see how this is going to be that worth while..

It's just going to take all legitimacy out of 0 confirmation transactions, thus making it harder for people to accept payments. As was posted in this thread: https://bitcointalk.org/index.php?topic=200090.0

Sorry if I'm being ignorant, but I can't possibly see how the down sides outweigh the positives.

I assume there will be possible solutions to get around these issues within the near future maybe?

[kjj]

Whilst I don't fully understand the concept behind this and why you're doing it, I don't see how this is going to be that worth while..

It's just going to take all legitimacy out of 0 confirmation transactions, thus making it harder for people to accept payments. As was posted in this thread: https://bitcointalk.org/index.php?topic=200090.0

Sorry if I'm being ignorant, but I can't possibly see how the down sides outweigh the positives.

I assume there will be possible solutions to get around these issues within the near future maybe?

0 confirmation transactions are not legitimate, never have been, never will be.  People need to stop pretending that they are.

[Maged]

Also, if the network doesn't operate on this principle, it will be because we've implemented ways to punish those who do otherwise

Why do you keep assuming this? What's wrong with simply rejecting the block discouraging mechanism as a bad idea and keeping the situation as it is? Just because we may currently have some protection for zero-conf transactions, doesn't mean we have to add more. It's already good enough!

[kjj]

Also, if the network doesn't operate on this principle, it will be because we've implemented ways to punish those who do otherwise

Why do you keep assuming this? What's wrong with simply rejecting the block discouraging mechanism as a bad idea and keeping the situation as it is? Just because we may currently have some protection for zero-conf transactions, doesn't mean we have to add more. It's already good enough!

I'm sorry dude, but you are wrong about this.  Most blocks are already assembled by software other than bitcoind.  Also, we have to accept that people using the stock client for mining are certainly capable of getting and applying this patch.  We can discourage patches like this from the main client, but we can't keep them off the network.

The some protection that you and other see is an illusion.  If even a single miner is running this code, or similar code in some other block assembly software, then no transaction is safe until confirmed.  The bulk of them may continue to get confirmed as everyone expects, but that is luck, not safety.

[Maged]

Also, if the network doesn't operate on this principle, it will be because we've implemented ways to punish those who do otherwise

Why do you keep assuming this? What's wrong with simply rejecting the block discouraging mechanism as a bad idea and keeping the situation as it is? Just because we may currently have some protection for zero-conf transactions, doesn't mean we have to add more. It's already good enough!

I'm sorry dude, but you are wrong about this.  Most blocks are already assembled by software other than bitcoind.  Also, we have to accept that people using the stock client for mining are certainly capable of getting and applying this patch.  We can discourage patches like this from the main client, but we can't keep them off the network.

Of course not! I fully expect a small percentage of miners to deploy this, and that's OK! That does not mean that we should encourage this behavior as a community by building it into the main client by default, however.

The some protection that you and other see is an illusion.

Code-wise, it is indeed an illusion. But that doesn't automatically mean that the human element in this is also an illusion.

If even a single miner is running this code, or similar code in some other block assembly software, then no transaction is safe until confirmed.  The bulk of them may continue to get confirmed as everyone expects, but that is luck, not safety.

Huh? They don't even need to run this code for that to be the case right now. All you need is for a miner to restart their node and a double-spend can get through just as easily. Remember that fork we had?

For the hundredth time, this has nothing to do with safety, but with playing the odds. Fast food restaurants realized that they can save several seconds per transaction by not having people sign their credit card receipt, meaning that they would automatically lose any chargeback. And yet, that savings more than made up for the additional losses that policy brought about. This issue is not just black and white, nor is it even 50 shades of grey.

[kjj]

Also, if the network doesn't operate on this principle, it will be because we've implemented ways to punish those who do otherwise

Why do you keep assuming this? What's wrong with simply rejecting the block discouraging mechanism as a bad idea and keeping the situation as it is? Just because we may currently have some protection for zero-conf transactions, doesn't mean we have to add more. It's already good enough!

I'm sorry dude, but you are wrong about this.  Most blocks are already assembled by software other than bitcoind.  Also, we have to accept that people using the stock client for mining are certainly capable of getting and applying this patch.  We can discourage patches like this from the main client, but we can't keep them off the network.

Of course not! I fully expect a small percentage of miners to deploy this, and that's OK! That does not mean that we should encourage this behavior as a community by building it into the main client by default, however.

The some protection that you and other see is an illusion.

Code-wise, it is indeed an illusion. But that doesn't automatically mean that the human element in this is also an illusion.

If even a single miner is running this code, or similar code in some other block assembly software, then no transaction is safe until confirmed.  The bulk of them may continue to get confirmed as everyone expects, but that is luck, not safety.

Huh? They don't even need to run this code for that to be the case right now. All you need is for a miner to restart their node and a double-spend can get through just as easily. Remember that fork we had?

For the hundredth time, this has nothing to do with safety, but with playing the odds. Fast food restaurants realized that they can save several seconds per transaction by not having people sign their credit card receipt, meaning that they would automatically lose any chargeback. And yet, that savings more than made up for the additional losses that policy brought about. This issue is not just black and white, nor is it even 50 shades of grey.

I guess I had thought it obvious that none of this discussion applies when a merchant is actively managing their risks through other means.  I have no objection to people making the choice to be unsafe.  Hell, I don't even like seatbelt laws.

What I don't like is people thinking that the network is providing them some safety, when it isn't.  Your quote clearly indicates that you think that the network is providing "some protection for zero-conf transactions", but the network isn't doing that.  The network is providing absolutely no protection until the transaction is confirmed, because confirmation is the only protection that the network is capable of providing.  If someone wants to operate on hope, they can.  But we need to stop telling them that hope and safety are the same thing.

[Belkaar]

My site also accepts 0-confirmation transactions, not because I'm ignorant, but because it needs to in order to compete with paypal-backed ones.

At the moment it is too much hassle to do a double-spend on the unconfirmed transaction for small amounts up to 100$. I ran it this way for 2 years without a single successful double spend (or noticeable attempt for that matter).

Putting this in the code will force minimum 1 confirmation for every 1.50$ transaction which is not uncommon to be 20-30 minutes, which makes bitcoin unusable for brick-and-mortar-stores, bitcoin ATMs as well as instant-delivery online stores.
No one wants to wait 20 minutes for a small transaction and no one needs to as long as the effort needed to do the attack outweighs the gains. It works well, why change this?

Please explain to me why this is inevitable? Every miner that implements this will make bitcoins more useless and thus less valuable, which in my opinion will cost far more than a little extra fees gained.

[jdillon]

Please explain to me why this is inevitable? Every miner that implements this will make bitcoins more useless and thus less valuable, which in my opinion will cost far more than a little extra fees gained.

You have to understand the position Gavin is in right now. It's kinda like the position the phone companies found themselves in, starting in the 60's. They had built a completely insecure phone system, one so insecure that a blind seven year old boy figured out how to activate phone switches and get calls for free by accident. Turned out all you had to do was whistle a 2600Hz tone into your phone and the local switch would activate.

When it comes to zero-conf transactions Bitcoin is just like those 60's era phone companies, and all you have to do to double-spend a site like yours is just broadcast two different transactions at the same time to different parts of the network. You'll see one or the other, and there's a 50:50 chance that your payment is the one that gets mined.

When hackers, known as "phreaking" back then, started seriously exploiting the tremendously insecure phone system, what do you think the phone companies did? Obviously they fixed the problem right? Fuck no, engineers are expensive, but lawyers and politicians are cheap!

So they got laws passed to make sure phreaking was illegal, even going as far as to make it illegal to tell others how to do it, or sell equipment to help the process. (not many people can whistle 2600Hz exactly) Of course that didn't solve the problem at all and phreaking continued to be a problem for decades. Eventually the phone system was fixed so signalling happened out-of-band and phreaking become impossible, with nearly all telephone switches upgraded by the 1990's.

Gavin wants to go down the same stupid path that the phone systems did. It's understandable why, his salary is paid by the Bitcoin Foundation, which in turn is heavily funded by payment-using non-anonymous companies like bitcoinstore, bitinstant, zipbit, eCardOne, CoinLab etc. etc. Most of these companies are still startups that are burning capital fast, and they need Bitcoin payments to become big NOW NOW NOW. Anything that might delay that could easily put these companies out of business and make their investors lose a lot of money.

Unfortunately the real work required to actually make zero-conf payments secure is going to take time that those startups just don't have. So from Gavin we get trite, insubstantial comments like "+1" rather than actually dealing with real technical issues.

The danger is if we don't succeed in getting replace-by-fee accepted and zero-conf transactions made safe with real security. Just like the phone companies, we'll see this issue become one of regulation both within Bitcoin and from outside authorities. Gavin's other big goal is to get the blocksize limit removed, which makes it impossible to mine on a small scale or anonymously, which means it's easy for regulators to start tracking down mining operations and punishing them for mining "illegal" transactions. One form of illegal transaction will of course be double-spends, but the only way to avoid accidentally mining a double-spend is to use a central authority to determine what transactions are or are valid. (remember that the whole point of Bitcoin mining is to answer that question!)

The sad thing is investors like myself get excluded from all these decisions. I don't belong to the Bitcoin Foundation because they require accurate identity information from every one of their members. Why would I want to be on a list of Bitcoin owners that may be given or leaked to governments around the world? There may be lots of "John Dillons" out there, but only one is living at my address. As Gregory Maxwell pointed out elsewhere how it's hard for decentralized software to get funding for development, which means centralization gets pushed instead. My $1000 reward to make replace-by-fee happen is something myself and my partners have decided to do as a way to start changing that and we intend further efforts in the future.

As for you, I'm sorry you've been lied to, but Bitcoin just isn't as fast as PayPal yet.

[Belkaar]

First of all thanks for taking the time.

When it comes to zero-conf transactions Bitcoin is just like those 60's era phone companies, and all you have to do to double-spend a site like yours is just broadcast two different transactions at the same time to different parts of the network. You'll see one or the other, and there's a 50:50 chance that your payment is the one that gets mined.

As I understand it it is not that simple. If it were there would be a satoshi-dice bot that does it. Please correct me if I'm off here:
To successfully double-spend you need to

A) send two transactions spending to different parts of the network and hope that transaction A reaches your target earlier and transaction b reaches the miner of the next block, which is way below 50%.

or B) send transaction A to your target and mine the next block yourself, which makes the success rate your percentage of hash rate (if you go this route you may as well be doing confirmed block double spends)

or C) mine away and if you find a block hold it back, do your transaction and then publish the block, which has a 100% success rate minus the risk that someone finds a block while you hold one back. This however requires good timing of you purchase.

So you need to be either a big miner or very lucky. So its not just downloading an auto-doublespend-tool (2600Hz whistle).

Gavin wants to go down the same stupid path that the phone systems did. It's understandable why, his salary is paid by the Bitcoin Foundation, which in turn is heavily funded by payment-using non-anonymous companies like bitcoinstore, bitinstant, zipbit, eCardOne, CoinLab etc. etc. Most of these companies are still startups that are burning capital fast, and they need Bitcoin payments to become big NOW NOW NOW. Anything that might delay that could easily put these companies out of business and make their investors lose a lot of money.

While the funding part may be true I heavily doubt that Gavins primary concern is the profitability of bitcoin businesses. Thats not his job.

As for you, I'm sorry you've been lied to, but Bitcoin just isn't as fast as PayPal yet.

I have never been lied to. I knew exactly how everything worked and assumed the risk to create a viable service. I just would have never guessed that a pay-to-doublespend feature would ever be included. If it does, bad for me.

Besides: This also concerns you as an investor. Bitcoin value heavily depends on its usability.

[Belkaar]

Another thing that just popped into my head:
Why stop at unconfirmed transactions?

If its all about miners getting the maximum fees, why not make a replace-by fee possible for transaction already in blocks?
You can't really implement a cancel-button into an end-user-app that potentially only works for 10 seconds.

If the replacement fee is higher than the last blocks combined fees it would make sense to orphan the last block and mine a new one at height-1 .

[Pieter Wuille]

I'm in the middle about this.

One the one hand, I do understand the reason for a change like this. If miners become (short-term) selfish/rational, and start implementing behaviour like the one implemented by this patch, I will completely be in favor of making it the default - as anything else would indeed just be a false sense of security. It would remove the "best-effort attempt" by the network to secure 0-conf transactions, and force people to find real solutions for fast transactions, instead of relying on behaviour that cannot be guaranteed. And perhaps that is inevitable anyway. And looking at Bitcoin as an experiment, it's so much more interesting to aim for a system that doesn't require specific parties to act in the best interest (especially non-rationally) of the community anyway...

On the other hand, it's not true that doing double-spending 0-conf transactions is trivial now. Not particularly hard, but not as easy as whistling in a telephone either. So in that sense, the network right now does provide some 0-conf security. Not much, and nothing guaranteed, but it works, and there is economic infrastructure that relies on it. I don't think they're even wrong about relying on it, if they're willing to eat the costs from damage caused by it (on the other hand, perhaps few can actually estimate the risk correctly, and will get hurt when their business becomes profitable enough to attack...). Anyway, what I'm getting at is that this is a drastic change if we'd put it in mainline, and drastic changes may be more damaging than the actual problem we're solving. Perhaps we need time to outgrow relying on 0-conf security.

So: I don't know. I like the idea of aligning miner's short-term self interest (even if they don't exploit that right now) with the policy implemented by the reference client. But perhaps not immediately...

[justusranvier]

The issue of zero conf transaction security is not a problem - it's a business opportunity. Here's one way to solve it:

Mining pools start offering double spend protection on a subscription-only basis. The way it works is the customer submits a transaction to the pool, and the pool either immediately rejects it because there is already a conflicting transaction in the in-progress block, or it accepts it, includes in the next block, and refuses to include conflicting transactions. Now a merchant can get instant notification about whether a transaction is valid or not, with a degree of assurance equal to that pool's fraction of the network hashing power.

Individual merchants who want to accept zero conf transactions don't even need to set this up individually. They could subscribe to a service that negotiates bulk rates with enough pools to account for X% of the network's hashing power.

[jgarzik]

I'm in the middle about this.

One the one hand, I do understand the reason for a change like this.

On the other hand, it's not true that doing double-spending 0-conf transactions is trivial now.

So: I don't know. I like the idea of aligning miner's short-term self interest (even if they don't exploit that right now) with the policy implemented by the reference client. But perhaps not immediately...

+1

Ultimately the change is too aggressive and anti-social right now.  Absolutely the miners market may change and make double-spending trivial, but that does not seem to justify removing hope of using a feature that businesses do rely on in the field today.

The userbase uses them, for better or worse.

Gavin wants to go down the same stupid path that the phone systems did. It's understandable why, his salary is paid by the Bitcoin Foundation, which in turn is heavily funded by payment-using non-anonymous companies like bitcoinstore, bitinstant, zipbit, eCardOne, CoinLab etc. etc. Most of these companies are still startups that are burning capital fast, and they need Bitcoin payments to become big NOW NOW NOW. Anything that might delay that could easily put these companies out of business and make their investors lose a lot of money.
[...]
Gavin's other big goal is to get the blocksize limit removed, which makes it impossible to mine on a small scale or anonymously,

This is full of hyperbole and exaggeration, much like the recent thread on dust.  However, it is fair to address the subject on a more reasoned level, because there is a valid point buried in there.

There is definitely a contingent of companies that seemingly want to change the blocksize limit immediately, from 1MB to infinity, to fix "this awful scaling problem" they see.  They want to sell the message that bitcoin can scale to Visa/MC levels tomorrow.  There should be absolutely no impediment to sending millions of transactions, for fractions of a penny apiece.

We absolutely do want to grow the network and encourage as many bitcoin users to use bitcoin as possible (well, I do at least, and I think Gavin does too)...  but one cannot ignore a key attribute conferring by a limit like the 1MB limit:  it encourages engineering efficiencies to be sought.  Programmers have an incentive to actively seek ways to reduce the number of transactions, or reduce transaction size, when faced with a limited resource.

Some business models simply don't care about that part of the equation.  It's not a conspiracy by Gavin and the Bitcoin Foundation funders, it is simply one facet of some bitcoin businesses.  They make money with increased transaction volume.  That's fine, but a key economic counter-point is that these businesses are not bearing the costs of the mining/blockchain impact of a million-TX-per-day policy.

Off-chain transactions should handle a resource limitation in a scalable fashion, but no one has good working prototypes.  Gavin has rightly pointed out, in Gavin/retep exchanges, that off-chain transactions remain a scalability solution in theory, while we know for certain that increasing the blocksize limit will enable increased transaction volume.

The danger in following that logic too far is that you de facto eliminate most incentives towards creating an off-chain transaction system/network and related businesses, or really as mentioned above, any need for transactional efficiency.  It also has impact on who is a bitcoin miner, selecting out anonymous miners as jdillon predicts.

I don't think anybody has The Answer right now, and my main preference is to avoid making decisions that dramatically and immediately change bitcoin's economics.  $Topic might do that, hurting payment companies for no good reason.  Removing the blocksize limit also injects chaos for unclear value.

Ultimately it is a complicated, zen balance of factors:  too-harsh limits, and you potentially choke off bitcoin utility just when it is being adopted, and eliminate some business models.  too-lax limits, and you choke off certain technologies, encourage spam, and eliminate some other business models.

My current personal preference for a blocksize limit solution is

Code:

     for each (144*365) blocks,
          limit += 1MB

As that's something that cannot be gamed by miners or payment companies.  But most payment companies do indeed react in horror at any impediment to "send as many transactions as possible."

Definitely in the middle here too.  Not as aggressive as Gavin or Mike Hearn, but not as conservative as "1MB forever" people either.  1MB was clearly a temporary solution.  (that does not imply simply removing it is without negative impact)

If the answer isn't clear, and the system isn't broken right now, err on the side of doing nothing.  The answer was clear, with the recent data spam / dust changes.  Not clear at all, with blocksize limits and the impact on fees thereof.

[Peter Todd]

Ultimately the change is too aggressive and anti-social right now.  Absolutely the miners market may change and make double-spending trivial, but that does not seem to justify removing hope of using a feature that businesses do rely on in the field today.

The userbase uses them, for better or worse.

The userbase will keep using them until you force them not too. This can either happen in the future, when a lot more money is at stake, or it can happen now.

Off-chain transactions should handle a resource limitation in a scalable fashion, but no one has good working prototypes.  Gavin has rightly pointed out, in Gavin/retep exchanges, that off-chain transactions remain a scalability solution in theory, while we know for certain that increasing the blocksize limit will enable increased transaction volume.

The majority of actual payments, as opposed to internal Bitcoin activity like selling mining equipment, is probably conducted with off-chain transactions right now: The Silk Road, The Black Market Reloaded and similar services all use 100% off-chain transactions. Sure, it makes for nice PR to point to people selling socks and other niches, but the reality is most of that business is from Bitcoin enthusiasts and investors; it's not genuine economic activity. It's no surprise to me that the only Bitcoin transactions anyone I know of has told me about, or asked me help to perform, is buying from the silk road and buying proxy services. For that genuine economic activity anonymity is key, particularly the former.

The other genuine economic activity, and what I suspect is where the majority of Bitcoin's market cap is derived, is investors seeking a decentralized asset that is free from regulation. Jon Matonis has written about the issue better than me, but what I hear from the people who have been donating to my efforts, in particular my video project, is they are pissed. They own thousands, and for some tens of thousands, of dollars worth of Bitcoins and/or mining equipment yet they see Gavin and The Bitcoin Foundation as not caring about privacy and decentralization. What they do see them caring about is internet startups with shoddy business models that would be better served by something like MintChip. These are the people who saw Cypress as a turning point for Bitcoin, and they want the degree of privacy they enjoy to be their choice, not someone elses.

In any case, why should I personally work on any off-chain tx systems? That just means I get attacked even more by all the people, Gavin included, constantly pushing conspiracy theories that I'm only pushing this issue because I want people to be forced to use my off-chain tx systems. Indeed, it's why I'm talking at the conference: to raise the issue and make sure as many talented developers as possible understand what ideas are out there, so they can build their *own* systems. Diversity is a good thing.

The danger in following that logic too far is that you de facto eliminate most incentives towards creating an off-chain transaction system/network and related businesses, or really as mentioned above, any need for transactional efficiency.  It also has impact on who is a bitcoin miner, selecting out anonymous miners as jdillon predicts.

It's more than that: it makes privacy more difficult for everyone. SPV mode leaks information for instance about what is in your wallet; if you can't afford to run a node yourself you have to rely on someone else to do so. With large blocks you will be paying for your Bitcoin network access in the future, either with cash or with your privacy, or even both: https://bitcointalk.org/index.php?topic=197169.msg2051415#msg2051415

Ultimately it is a complicated, zen balance of factors:  too-harsh limits, and you potentially choke off bitcoin utility just when it is being adopted, and eliminate some business models.  too-lax limits, and you choke off certain technologies, encourage spam, and eliminate some other business models.

My current personal preference for a blocksize limit solution is

Code:

     for each (144*365) blocks,
          limit += 1MB

The moment you do that, literally on year one, you are making the decision to make it far harder to use Bitcoin anonymously for the benefit of the people using blockchain space for the least important, lowest value transactions; right now that's getting paid for clicking on ads on the internet.

But the real issue is what values do we have? The people advocating the raise the blocksize better be really clear about what they think is or is not important, and that includes what they think of anonymity, privacy and freedom from regulation and authority.

[marcus_of_augustus]

Oh dear.

[Nubarius]

My current personal preference for a blocksize limit solution is

Code:

     for each (144*365) blocks,
          limit += 1MB

The problem I see with this is that the growing adoption of Bitcoin is likely to follow an exponential rather than linear trend during the next few years. A linear growth in the maximum block size would mean that blocks keep getting smaller relative to the demand of transactions. An approach I find more sensible would be:

Code:

     for each (144*365) blocks,
          limit *= 2

But then, after a few years this would be tantamount to an infinite size (which is fine with me; my basic assumption being that Bitcoin should essentially be a payment system, its store-of-value properties being a consequence of its usefulness for payments, and not the other way around. I don't believe in the idea of Bitcoin as some sort of digital gold for a minority of Tor-connected übernerds).

Now back to topic...

While I find it perfectly legitimate to work on a pay-to-edit-transactions system, and I think it is good that such possibilities are explored and tested by the core developers, I don't think this is in line with what users expect Bitcoin to be, and I think it will never make it as a basic part of Bitcoin functionality. In fact, I don't even see how such a feature would be attractive to miners. Users would understand a feature like 'this transaction can still be cancelled during the next 24 hours', which can be implemented as a third-party system that simply schedules the actual Bitcoin transactions, but a mechanism that's only available before the transaction gets into a block offers no such time-window guarantee, which would put off potential users. Because of that, I think that there's no real demand from users for that 'feature' and that miners won't have any incentive to support it. But for the sake of argument let's suppose some miners feel tempted by the idea that they can profit from the odd user that wants to pay a fee to edit/undo an already published transaction. My feeling is that a reputation system would naturally grow where people would know which miners are known to have reneged on transactions they've relayed and which ones stick to their original transactions. I haven't thought much about this, but I suppose services that list unconfirmed transactions like blockchain.info could devise some sort of reliability metric for unconfirmed transactions based on statistics about the past behaviour of known IP's.