Bitcoin Forum

(reposting the bitcoin-development email for visibility)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

After some consultation with affected sites by myself and Peter we have decided
to release an initial replace-by-fee implementation and setup a server using
those rules on testnet. This implementation does not include recursive fee
evaluation, and is therefore vulnerable to DoS attack, so hopefully that will
continue to allow adoption to proceed gradually. We can-not recommend mining on
mainnet with it. It does not include an "undo" RPC command or an adjust fees,
and Peter says he has not implemented one yet.  Patches are welcome.

Specifically there were requests from vulnerable parties, which interestingly
included a site that knew they had bugs related to replacement but not
financial vulnerabilities, to put up a server on testnet to check wallet code.
The vulnerable requested to remain undisclosed. An additional consideration was
the upcoming anti-dust rules which are yet another example of why zero-conf is
so much more dangerous to accept than single-conf. Two of the people contacting
us brought up that issue in fact.

The code is on github:

    https://github.com/petertodd/bitcoin/tree/replace-by-fee

and a replace-by-fee server operating on testnet is available at
testnet-replace-by-fee.bitcoin.petertodd.org To test you will need to use the
raw transaction API and manually create the replacement transaction. Do note
that your wallet will retain the existing one and no mechanism yet exists to
delete the old transaction from your wallet. Again, a certain amount of
"cludgyness" to this is intentional to discourage premature non-testing use.


Regarding the reward, I've decided Peter will collect the full amount even
though the work is not %100 complete (the mempool aspect) due to his concern
about staging an implementation properly, working with vulnerable sites, and
overall genuine interest in the actual issues at hand rather than the reward.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iQEcBAEBCAAGBQJRi3LeAAoJEEWCsU4mNhiPwscH/2CI0d3h/3jix3iyz2I9I8Sz
6nbP8eA01l9kzG37cH1rFAbt7C+fL/nardV4U1qmiwC0MN7NPpX6BFn5eQ2PUKbu
41+AnjgWicB2tnCC07ngboQ1JCeZ+RTfATepuMxEdWFBsc8ZQXs0apWS01FT+TDq
J/a7QkhNfTaAQzXyqmLp0TQO7/Z7ysmCftOhtGbfvfhF2o23BuphQiRVA9IOoUuj
Fgb5wrfQqJ8TjvXRXAUQ7SUlzfN9BlPxMkTc6NhbcgIpuq1Kb43mLoDl3s2irH4A
GtjRtobV5Cfozm1r+8KPtIYEoQoj0PqTjO5YMwD/vTaRfNzdS4Tse5LQLGT6Jug=
=M1mj
-----END PGP SIGNATURE-----

Peter who?

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

Peter Todd

For context on that:


That thread is:

Reminder: zero-conf is not safe; $1000USD reward posted for replace-by-fee patch
 - http://bitcointalk.org/index.php?topic=179612.0

Yup. The reward was initially $500 and increased to $1000 after I pointed out to jdillon that replace-by-fee needed recursive fee evaluation, IE Luke's child-pays-for-parent concept, or it would be susceptible to DoS attacks. That code is easily $500 of engineering time for a prototype.

To be clear, replace by fee was initially something I proposed, and jdillon decided to offer a reward to actually implement it a few days later. Like myself he has strong feelings about ensuring mining remains decentralized and free from regulations.

To be sure: this only adds priority to a transaction right?
it doesn't modify the outputs?

because if not, someone could just fork the client to make an alt-coin that allows you to pay a fee to replace a transaction.
hence why they are paying for this...

Nope. This is pure replace-by-fee, under any circumstance where two transactions would spend the same inputs. For instance I could have a transaction with a whole bunch of inputs and outputs, and another one that spends only one of those inputs and has one output. If the fee-per-KB of the second was higher than the first, and the total fee paid by the second was also higher, then the first transaction and all dependents would be removed from the mempool and the second added in it's place.

Among other things, I intend to implement an "undo" button that simply creates a transaction spending one of the inputs of an unconfirmed transaction in your wallet with a higher fee, sending the remainder back to your wallet.

But then anyone can send a transaction to satoshidice and then, if he loses, send another transaction with more fees sending the coins to himself???

Can't wait to see the hundreds of noobs complaining, "i sent xcoin to a trader when i show the btc coming at blockchain but they never arrived!!"

Or the merchants saying "this destroy instant payments, unless you reduce your 10 min confirmation to 2 we're moving to ltc..."

etc... or am i wrong?

I think this is a terrible idea.

If it was "higher fee with superset of outputs of first spend" then that'd be fine.

Zero-confirmation transactions will never be safe because of potential Finney attacks. But we don't need (and, in my opinion, shouldn't) make them less safe by encouraging anti-social behavior via default mining policy.

Yes, evoorhees is well aware of that and has been contacted.

They will be introducing off-chain betting in the near future so it won't be an issue for them soon. I and John are discouraging mainnet miners from making use of this patch immediately through a variety of methods to give people time to respond.

yes, what is the idea of the patch?, i thought it was to make transactions stuck on limbo ( because of lack of insufficient fees) to go thru.
the fee , and the change, should be the only thing changed here.

Otherwise you are implementing charge-back, and for that, wouldn't it be easy-er to just make the bitcoin-qt wait, by default, internally 1 minute before really sending the transaction to the network?  

Let the problem be solved client-sided? there you have your cancel button!


Who is this johndillion? Could it be the Chinese-man moving around 500 bitcoins all the time against SD ?
 :S

I see this by analogy to security research vulnerability disclosure.

Right now, tons of people* are acting as if they were safe, when they really are not.  They've been warned, over and over again.  Until the tool gets posted to metasploit for one-click use, they will not really accept that they are in danger.

I'm pretty sure there have been other bitcoin patches accepted or rejected on the basis of avoiding lulling users into a false sense of security.  In the end, it doesn't matter.  Eventually, the network will operate on the principle embodied in this patch.  The miners that aren't already using their own tools for block generation can get this if they want it.

That said, I'm not sure that I'd want to sign off on this either.  Inevitable or not, it does kinda feel icky.

*  I don't believe that tons of people are actually accepting zero confirmation transactions.  I suspect that there are a dozen people on these forums (incorrectly) whining about this patch making 0-conf unsafe for every person actually accepting them.

Yup.

Also, if the network doesn't operate on this principle, it will be because we've implemented ways to punish those who do otherwise, and all the ways to do that involve ad-hoc secondary consensus mechanisms that make the network more fragile, and make it harder to run a profitable mining pool on a limited budget. Remember that there is no magic way to know if a transaction is a double-spend - you're limited network bandwidth can easily mean you just don't see the original transaction where a bigger, more centralized mining pool with a fast network connection will maintain a more view of the mempool that is more consistent with other large pools.


Indeed. Part of the reason why I decided I'd write the patch and collect the reward was because I knew if I did so I would have some control over how it was "released into the wild" - someone else might just want to for the money and not bother to do responsible disclosure. Heck, I was thinking of turning down the reward, but with John also donating to my blocksize video... well, Bitcoins are fungible. In any case I'm pretty sure his intentions are honorable after the discussions I've had with him.

yes, i understand zero-confirmations it's unsafe, the problem is the users, does everyone understand? they don't want to wait 10 minutes for a confirmation

of their online pizza purchase... they want it now.

I will support this and to keep the block-size the same if the bitcoin speed was increased to 2 minutes for example.
Then no problem waiting for confirmations.

Use a service layered on top of bitcoin, that provides the instant+secure guarantees you want.

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

Businesses that accept zero-confirmation transactions are surely quite aware that they are not perfectly safe, but some (e.g. bitpay IIRC) still find it in their interest to accept them anyway, and incorporate the risk of loss into their prices.  Simply assuming they're stupid to do so in order to justify unintentionally harming their business model seems a bit... insensitive.

Wouldn't bitpay, for example, lose the universality of the Bitcoin payment network by switching to something like this?  Part of what makes them so convenient is that customers don't have to sign up for special accounts.

That service may not be at all what you'd expect either: the bitcoin-otc.com P2P exchange provides a P2P reputations system. You could combine that with a simple "payment protocol" of just PGP signing your trades, and a mechanism to retrieve double-spent transactions from your wallet to make it easy to prove to others that you were defrauded. The initial implementation doesn't have to be fancy, just something an expert could use to verify someone else's claims, but it'd still be significantly better than what bitcoin-otc has right now.


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.


The "service" layered on top doesn't need to be an account tied to one vendor. I mentioned bitcoin-otc above; another approach is to purchase a fidelity bond tied to a pseudonym, and use that bond to vouch that you will not double-spend some given payment. Break that promise and the recipient can publish the fraud, invalidating the bond.

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?

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 :D

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.

Did you ask and answer that question yourself?

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


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.

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

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.

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.

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.

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

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.

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.

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 (http://en.wikipedia.org/wiki/Joybubbles) 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 (http://en.wikipedia.org/wiki/2600_Hz) 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.

First of all thanks for taking the time.

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).


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

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.

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 .

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...

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.

+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.



This is full of hyperbole and exaggeration, much like the recent thread on dust (https://bitcointalk.org/index.php?topic=196138.msg2123771#msg2123771).  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

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.

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.


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.


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


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.

Oh dear.

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:


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.

jgarzik: So on the blocksize issue we do roughly agree on the problem, if not as much the solution, and we do agree that I do not make a good diplomat. That is a good start.


Nubarius: The likes of you will be in for a rude awakening about how little Bitcoin has to offer as a payment systems as mints around the world create lovely little chip-to-chip secure hardware dongles as a means to combat Bitcoin. That, or they will combat Bitcoin directly by destroying its decentralization. One or the other.

It could be. Or it could be that you're making wrong assumptions about how human society and economic incentives work.

Gavin is correct, this patch is a ridiculous idea. It doesn't matter that anyone could write it at any time, no rational miner will use it.

There are some very odd ideas at work here about economic rationality. Rational does not mean "motivated by short term profit at any cost". The most rational choice for a miner is to do whatever maximises the value of the Bitcoins they're mining. Making it hard to use unconfirmed transactions would very clearly reduce the value of Bitcoin for large numbers of people, meaning fewer merchants, a smaller ecosystem and less demand, which suppresses the exchange rate. As miners have costs in dollars but income in Bitcoins they're very much motivated to maximise the value (and thus utility) of the whole system.

Bitcoin is at heart a system that manages risk. Being in a block doesn't mean "safe" vs "unsafe", re-orgs can cause transactions to become double spent at any time. So to make blanket statements about the safety of transactions is unsound: you cannot justify an assertion like "unconfirmed transactions are unsafe" without providing proof of what you say.

I assert that unconfirmed transactions are safe enough for many users today, and can be made safer in future. As evidence I cite the lack of complaints about double spending from merchants, easily measured by the lack of media coverage of such events. I also cite the wide acceptance of such transactions and the ability to build double spend alerts to increase the trustworthiness of the broadcast channel. I would need to see equally compelling evidence there's a problem to change my mind on that, and if you have to put in large efforts and use arguments like "it's inevitable" then you aren't showing evidence there's a problem, you're deliberately trying to create one from scratch. Not the same thing at all.

John Dillon is indeed a terrible diplomat, I've had him on my ignore list for a while. There are plenty of productive things he could be doing to increase the utility of Bitcoin for everyone, but instead has chosen to focus on controversial changes that if successful would lower Bitcoins overall utility. He thinks he is doing this for the greater good, but this idea is at best controversial and at worst flatly incorrect. If it's truly inevitable he doesn't need to do anything, as it will happen anyway, and he'd avoid annoying a lot of people he might want to work with in future. If it's not inevitable then he's still better off doing nothing. Regardless, I am not worried about this overly much because as I said, I don't believe miners will use it, nor (given the failure rate in the presence of <100% adoption) will end users.

Here's a version suitable for mainnet:

https://github.com/petertodd/bitcoin/tree/replace-by-fee

It's got DoS attack resistance by simply punting on cases where it matters, so running a node with the patch shouldn't cause any problems. The big "punt" is it doesn't do child-pays-for-parent, so to resist DoS attacks via long unconfirmed chains it simply won't do a replacement if any outputs are spent.This has the advantage of being dead simple; the code is quite similar to satoshi's original replacement code. I've done some testing on testnet, but if you want to mine on mainnet, keep in mind that you may be risking an invalid block if there's something I missed. You can -addnode=replace-by-fee.bitcoin.petertodd.org to peer with a node with that patch.

I haven't written any of the useful infrastructure like an "undo" button or way to change fees automatically, and it will leave unconfirmed tx's in your wallet. (fixable with -salvagewallet) I'm not going to get a chance to fix any of that immediately; I've got a child-pays-for-parent mempool rewrite I want to finish first. Patches for that stuff are very welcome.


jdillon: change the title if you get a chance...

Horrible idea... it sounds great to have "undo" button until you think about double spending. If I could I will not accept this idea.