Topic: Initial replace-by-fee implementation is now available on testnet - page 2. (Read 16158 times)

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://bitcointalksearch.org/topic/greedy-developers-want-to-call-off-bitcoin-mass-adoption-long-term-down-trend-200090

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?

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

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.

Did you ask and answer that question yourself?

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.

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

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.

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.

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

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

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.

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.

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.

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

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.

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.

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?

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.

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

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.