Bitcoin Forum
November 15, 2018, 01:10:41 AM *
News: Latest Bitcoin Core release: 0.17.0 [Torrent].
 
   Home   Help Search Login Register More  
Pages: « 1 [2] 3 »  All
  Print  
Author Topic: RBF transactions to be enabled at the next core update  (Read 4122 times)
shorena
Copper Member
Legendary
*
Offline Offline

Activity: 1484
Merit: 1278


No I dont escrow anymore.


View Profile WWW
January 19, 2016, 08:36:03 AM
 #21

-snip-
Maybe I have misspoke in some way due to my lack of technical understanding of RBF. I guess the conflicting transaction would also have RBF enabled, allowing it to be accepted by the nodes.

By enabling RBF you would essentially announce "this can be double spend", which would significantly reduce your chance to use this maliciously.

-snip-
Today when someone buys a cup of coffee from Starbucks with their credit card, it is Starbucks that bears the costs of accepting the Credit Card. I don't see why it should be any different with Bitcoin, so Starbucks could receive a payment with a very low/no fee and then could use a CPFP transaction with a sufficiently high fee to get both transactions to confirm.

CPFP is still possible. RBF does not change this.
1542244241
Hero Member
*
Offline Offline

Posts: 1542244241

View Profile Personal Message (Offline)

Ignore
1542244241
Reply with quote  #2

1542244241
Report to moderator
1542244241
Hero Member
*
Offline Offline

Posts: 1542244241

View Profile Personal Message (Offline)

Ignore
1542244241
Reply with quote  #2

1542244241
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1542244241
Hero Member
*
Offline Offline

Posts: 1542244241

View Profile Personal Message (Offline)

Ignore
1542244241
Reply with quote  #2

1542244241
Report to moderator
1542244241
Hero Member
*
Offline Offline

Posts: 1542244241

View Profile Personal Message (Offline)

Ignore
1542244241
Reply with quote  #2

1542244241
Report to moderator
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1582
Merit: 1739


bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl


View Profile WWW
January 19, 2016, 12:37:21 PM
 #22

Today when someone buys a cup of coffee from Starbucks with their credit card, it is Starbucks that bears the costs of accepting the Credit Card. I don't see why it should be any different with Bitcoin, so Starbucks could receive a payment with a very low/no fee and then could use a CPFP transaction with a sufficiently high fee to get both transactions to confirm.
Credit cards are a pull system where the merchant is taking money rather than giving them money. Bitcoin is a push system where you give merchants the money. Bitcoin puts the onus of sending transactions and getting then confirmed on the sender, not the receiver. Thus it stands to reason that bitcoin continue with that idea and put the burden on the sender and not the receiver.

However, I am not averse to CPFP transactions. I think it would be better if we had both RBF and CPFP enabled so that both senders and receivers can do something to get their transactions confirmed.

Quickseller
Copper Member
Legendary
*
Offline Offline

Activity: 1596
Merit: 1202

in 2 min-groin injury, dildo on field, & 6-9 score


View Profile WWW
January 19, 2016, 05:10:50 PM
 #23

-snip-
Maybe I have misspoke in some way due to my lack of technical understanding of RBF. I guess the conflicting transaction would also have RBF enabled, allowing it to be accepted by the nodes.

By enabling RBF you would essentially announce "this can be double spend", which would significantly reduce your chance to use this maliciously.
I was responding to theymos's comment that was implying it would be necessary to have some level of technological knowledge to perform a malicious double spend with RBF
Quote from: theymos
I really doubt Core is ever going to provide an easy UI for fraudulently double-spending

Quote from: shorena
CPFP is still possible. RBF does not change this.
Right, however it appears to me that the core devs are pushing RBF much stronger then CPFP. I am questioning why it is not the opposite

3PjXm2XYDKLV5mN3oiKzNTyVvSkqP3ujeq <-- tipping address Advertise here
shorena
Copper Member
Legendary
*
Offline Offline

Activity: 1484
Merit: 1278


No I dont escrow anymore.


View Profile WWW
January 19, 2016, 06:49:47 PM
 #24

-snip-
Maybe I have misspoke in some way due to my lack of technical understanding of RBF. I guess the conflicting transaction would also have RBF enabled, allowing it to be accepted by the nodes.

By enabling RBF you would essentially announce "this can be double spend", which would significantly reduce your chance to use this maliciously.
I was responding to theymos's comment that was implying it would be necessary to have some level of technological knowledge to perform a malicious double spend with RBF
Quote from: theymos
I really doubt Core is ever going to provide an easy UI for fraudulently double-spending

It might still allow an easy way to do RBF, e.g. by using the exact same inputs (or more if needed) and only allowing you to increase the fee, but not allowing you to change the non-change outputs. If the only long term change is a different relay policy it will not change much for the majority of users.

Quote from: shorena
CPFP is still possible. RBF does not change this.
Right, however it appears to me that the core devs are pushing RBF much stronger then CPFP. I am questioning why it is not the opposite

As I dont belong to that group I can only guess, but my guess is that - similar to what knightdk wrote - its not in the spirit of bitcoin and thus has less priority. AFAIK its mainly a miner side implementation anyway. From what I read about "SPV Mining" most miners run custom code, so developing code for CFPF in core might be seen as a waste of time.
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1582
Merit: 1739


bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl


View Profile WWW
January 19, 2016, 07:46:08 PM
 #25

Quote from: shorena
CPFP is still possible. RBF does not change this.
Right, however it appears to me that the core devs are pushing RBF much stronger then CPFP. I am questioning why it is not the opposite

As I dont belong to that group I can only guess, but my guess is that - similar to what knightdk wrote - its not in the spirit of bitcoin and thus has less priority. AFAIK its mainly a miner side implementation anyway. From what I read about "SPV Mining" most miners run custom code, so developing code for CFPF in core might be seen as a waste of time.
Also they are making a feature that satoshi originally had actually work well. Satoshi originally had a feature to replace transactions but it had a DoS problem. The solution was to require a fee increase, thus RBF, which they are only now implementing.

theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 3206
Merit: 3926


View Profile
January 19, 2016, 10:53:39 PM
 #26

In order for a 0-confirmation transaction to get double spent (assuming you have zero influence on any amount of mining hardware/pool) without RBF, as a general rule most of the network needs to have not seen the transaction, AND the transaction needs to either not have been seen by the miners' nodes or not be a transaction that the miners will generally confirm.

Exploiting policy differences is the easiest way, and I'm not sure that you can ever really eliminate it because people will always have different policies. But there are other ways:

I think that you'll have a pretty good success ratio if you send the transaction directly to the merchant and simultaneously send the double-spend directly to some miners. The merchant and the peers around him will have one version, but miners will have the other. If the merchant is not running several nodes, then he probably won't even see the the double-spend until it gets into a block, since his surrounding peers won't relay a transaction that they view as a double-spend.

And there's always the Finney attack. If you're a miner, you can (for no additional cost) continuously try to double-spend your 0-conf transactions. If you happen to mine a block while the transaction still has 0 confirmations, then you double-spend it, and nothing can stop this.

Quote
Wouldn't it be possible for someone to sign a transaction that relies on input x, and has a "high" fee, save this transaction to a text file (or wherever), then sign a separate transaction that also relies on input x and has a "low" fee, and has the appropriate flags that "enable" RBF, and broadcast this transaction. Then they could simply use "sendrawtransaction' (which is significantly easier to use then "createrawtransaction" imo) to broadcast the conflicting transaction.

The Core GUI won't let you create conflicting transactions like that. You could do it by messing around with wallet backups or something, but again, it takes a fair bit of extra effort.

With Core's implementation of opt-in RBF, you can't (from the perspective of any given network node) replace an RBF-disabled transaction with an RBF-enabled transaction, and you can't replace a transaction with one having a lower fee. You can replace an RBF-enabled transaction with an RBF-disabled transaction.

Quote
This doesn't mean that others will not write guides on how to fraudulently double spend transactions, and that people will not design wallets/programs to help people fraudulently double spend transactions.

Probably, but that can happen with non-RBF transactions as well.

Quote
I am having difficulty finding reasons why RBF is better then CPFP and/or RBF is being implemented in core while CPFP is not supported (for the most part).

AFAIK CPFP isn't ruled out for Core. It's in Luke's fork. I'm not sure why it's not in Core. Maybe there are some performance problems with the existing code or something.

I see them as being complementary. If the sender is taking responsibility for confirmation, then he should use RBF; otherwise, if the recipient is taking responsibility then the recipient can use CPFP and the sender can opt out of RBF.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
BlindMayorBitcorn
Legendary
*
Offline Offline

Activity: 1176
Merit: 1051



View Profile
January 28, 2016, 02:38:57 AM
 #27

Jeff Garzik already proposed a correct and clean solution for the (infrequent and unimportant) so-called "problem" of "stuck transactions", which was way simpler than Peter Todd's massively unpopular and needlessly complicated RBF: Simply allow "stuck transactions" to time-out after 72 hours

Quote
RBF also doesn't solve the problem of "ensuring a quick confirmation".

    If there are only 20 seats on the bus and 25 people that want to ride, there is no ticket price where everyone gets a seat. Capacity problems can't be fixed with a "fee market", they are fixed by adding seats, which in this case means raising the blocksize cap. – /u/Vibr8gKiwi
Undecided

Forgive my petulance and oft-times, I fear, ill-founded criticisms, and forgive me that I have, by this time, made your eyes and head ache with my long letter. But I cannot forgo hastily the pleasure and pride of thus conversing with you.
letsplayagame
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
January 28, 2016, 09:09:50 AM
 #28

Jeff Garzik already proposed a correct and clean solution for the (infrequent and unimportant) so-called "problem" of "stuck transactions", which was way simpler than Peter Todd's massively unpopular and needlessly complicated RBF: Simply allow "stuck transactions" to time-out after 72 hours

Quote
RBF also doesn't solve the problem of "ensuring a quick confirmation".

    If there are only 20 seats on the bus and 25 people that want to ride, there is no ticket price where everyone gets a seat. Capacity problems can't be fixed with a "fee market", they are fixed by adding seats, which in this case means raising the blocksize cap. – /u/Vibr8gKiwi
Undecided

Not everyone will care about a quick confirmation and only a small percentage of the transactions in each block will decide to use the RBF "fee market".

We are a long time away from a situation where everyone who wants to use RBF will generally not be able to do so. The seats on the RBF bus will remain mostly empty for a long time.

Maybe an airplane would make a better analogy. Pretend RBF passengers are first class. They make up a small percentage of the plane occupants. If first class fills up and someone is willing to pay enough to fly (RBF), they are still given a seat. Someone from coach will be bumped to the next flight either voluntarily or voluntarily. They flight makes room for RBF passengers.

Chess, Bitcoin, Privacy and Freedom
Code:
Make BTC Donations via XMR.TO or Shapeshift XMR: 47nMGDMQxEB8CWpWT7QgBLDmTSxgjm9831dVeu24ebCeH8gNPG9RvZAYoPxW2JniKjeq5LXZafwdPWH7AmX2NVji3yYKy76
piotr_n
Legendary
*
Offline Offline

Activity: 1960
Merit: 1039


aka tonikt


View Profile WWW
February 17, 2016, 07:31:14 PM
 #29

Sorry, I'd like to start kind of a different thread as I am actually interested in the machinery of it.
I know it's in the specs, but I hate reading those, mostly because they are too often useless.
And I really care to know it.

Can anyone please explain how it actually works that a transaction gets replaced in the memory pool?
What is the algorithm of recognizing that it is a replace-fee transaction, and not just some other shit?
How do you e.g. deal a new tx that would try/suppose to replace two (of more) txs in the existing memory pool?

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2562
Merit: 1669



View Profile
February 18, 2016, 01:36:40 AM
 #30

Sorry, I'd like to start kind of a different thread as I am actually interested in the machinery of it.
I know it's in the specs, but I hate reading those, mostly because they are too often useless.
And I really care to know it.
Won't read the spec. Won't read the code. ... why would anyone expect you to read an answer here?  Next time try offering money when you want to demand one on one spoon-feeding.

Until then you get copy-pasta:


Summary

This policy specifies two ways a transaction can signal that it is replaceable.

    Explicit signaling: A transaction is considered to have opted in to allowing replacement of itself if any of its inputs have an nSequence number less than (0xffffffff - 1).
    Inherited signaling: Transactions that don't explicitly signal replaceability are replaceable under this policy for as long as any one of their ancestors signals replaceability and remains unconfirmed.

Implementation Details

The initial implementation expected in Bitcoin Core 0.12.0 uses the following rules:

One or more transactions currently in the mempool (original transactions) will be replaced by a new transaction (replacement transaction) that spends one or more of the same inputs if,

    The original transactions signal replaceability explicitly or through inheritance as described in the above Summary section.
    The replacement transaction pays an absolute higher fee than the sum paid by the original transactions.
    The replacement transaction does not contain any new unconfirmed inputs that did not previously appear in the mempool. (Unconfirmed inputs are inputs spending outputs from currently unconfirmed transactions.)
    The replacement transaction must pay for its own bandwidth in addition to the amount paid by the original transactions at or above the rate set by the node's minimum relay fee setting. For example, if the minimum relay fee is 1 satoshi/byte and the replacement transaction is 500 bytes total, then the replacement must pay a fee at least 500 satoshis higher than the sum of the originals.
    The number of original transactions to be replaced and their descendant transactions which will be evicted from the mempool must not exceed a total of 100 transactions.

The initial implementation may be seen in Bitcoin Core PR#6871 and specifically the master branch commits from 5891f870d68d90408aa5ce5b597fb574f2d2cbca to 16a2f93629f75d182871f288f0396afe6cdc8504 (inclusive).




Bitcoin will not be compromised
piotr_n
Legendary
*
Offline Offline

Activity: 1960
Merit: 1039


aka tonikt


View Profile WWW
February 18, 2016, 07:29:19 AM
 #31

Won't read the spec. Won't read the code. ... why would anyone expect you to read an answer here?  Next time try offering money when you want to demand one on one spoon-feeding.

Until then you get copy-pasta:

[...]
Thank you, that's what I needed.
Yes, I have read it. It's clear and prompt, so very helpful.

Sharing is caring, my friend.
Many people like helping other people, just because it feels nice.
Others may have different, less generous reasons, but I don't mind, as long as I get what I asked for.
So thank you for helping me, whatever reason you had.

Check out gocoin - my original project of full bitcoin node & cold wallet written in Go.
PGP fingerprint: AB9E A551 E262 A87A 13BB  9059 1BE7 B545 CDF3 FD0E
Jet Cash
Legendary
*
Offline Offline

Activity: 1064
Merit: 1293


I don't merit Spambies


View Profile WWW
February 19, 2016, 04:47:37 PM
 #32

I was anti-RBF when I  first read about it, but as it is an opt-in feature, I think it is handy to include it in the system. I want to start accepting Bitcoin donations on behalf of a charitty, and I want to convert them to fiat currency myself. I already send them Sterling at no cost to either of us, and it would be nice if I could move the Bitcoins at no cost as well. Time isn't important, so I wondered if I could send the coins at zero-fee, and if it looked as if they weren't going to confirm, then I could add a fee. Of course, the other alternative is to wait until it dies, and then re-send it.

There is another posibility. I could sell a domain name as an agent for another person. If I accepted a Bitcoin payment with a time-lock, then I could wait until the name has transferred, and then use RBF to re-route the payment to the owner. ( will that be possibnle? ).

theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 3206
Merit: 3926


View Profile
February 19, 2016, 05:01:49 PM
 #33

Another nice thing about 0.12 in this area is that mempool transactions will by default expire after 72 hours. Previously they'd stick around until the node was restarted, which made it difficult to predict when the network had forgotten about the unconfirmed transaction and it was time to resend it or create a conflicting one with a higher fee.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
BlindMayorBitcorn
Legendary
*
Offline Offline

Activity: 1176
Merit: 1051



View Profile
February 19, 2016, 05:10:04 PM
 #34

Another nice thing about 0.12 in this area is that mempool transactions will by default expire after 72 hours. Previously they'd stick around until the node was restarted, which made it difficult to predict when the network had forgotten about the unconfirmed transaction and it was time to resend it or create a conflicting one with a higher fee.

Bonus points! Smiley

Forgive my petulance and oft-times, I fear, ill-founded criticisms, and forgive me that I have, by this time, made your eyes and head ache with my long letter. But I cannot forgo hastily the pleasure and pride of thus conversing with you.
letsplayagame
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


View Profile
February 19, 2016, 07:08:19 PM
 #35

I do not see the problem with RBF. Almost nobody is going to abuse it for low value transactions (like Starbucks). The economic incentive is not high enough to cheat for very small transactions.  For large transactions merchants can just demand multiple confirmations which they should be doing anyway regardless of the introduction of RBF.

Having said that is the drawback of allowing both RBF and CPFP?

Chess, Bitcoin, Privacy and Freedom
Code:
Make BTC Donations via XMR.TO or Shapeshift XMR: 47nMGDMQxEB8CWpWT7QgBLDmTSxgjm9831dVeu24ebCeH8gNPG9RvZAYoPxW2JniKjeq5LXZafwdPWH7AmX2NVji3yYKy76
BlindMayorBitcorn
Legendary
*
Offline Offline

Activity: 1176
Merit: 1051



View Profile
February 19, 2016, 07:15:27 PM
 #36

I do not see the problem with RBF. Almost nobody is going to abuse it for low value transactions (like Starbucks). The economic incentive is not high enough to cheat for very small transactions.  For large transactions merchants can just demand multiple confirmations which they should be doing anyway regardless of the introduction of RBF.

Having said that is the drawback of allowing both RBF and CPFP?

AFAIK CPFP isn't ruled out for Core. It's in Luke's fork. I'm not sure why it's not in Core. Maybe there are some performance problems with the existing code or something.

I see them as being complementary. If the sender is taking responsibility for confirmation, then he should use RBF; otherwise, if the recipient is taking responsibility then the recipient can use CPFP and the sender can opt out of RBF.

Forgive my petulance and oft-times, I fear, ill-founded criticisms, and forgive me that I have, by this time, made your eyes and head ache with my long letter. But I cannot forgo hastily the pleasure and pride of thus conversing with you.
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 19, 2016, 08:02:28 PM
 #37

So this means that when a transaction is broadcasted it has a flag saying that RBF can be enabled, or that it can't?

If all of the inputs of a transaction have nSequence = UINT_MAX or UINT_MAX-1, then they have RBF disabled. Sending transactions with nSequence = UINT_MAX is the default for ~all wallets.
Does this mean that transactions that need to change nSequence so they can use CHECKLOCKTIMEVERIFY will be forced to enable RBF?

James

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 3206
Merit: 3926


View Profile
February 19, 2016, 08:26:51 PM
 #38

Does this mean that transactions that need to change nSequence so they can use CHECKLOCKTIMEVERIFY will be forced to enable RBF?

No, the special sequence value UINT_MAX-1 disables RBF but also allows CLTV. UINT_MAX disables both.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1089


View Profile WWW
February 19, 2016, 08:43:02 PM
 #39

Does this mean that transactions that need to change nSequence so they can use CHECKLOCKTIMEVERIFY will be forced to enable RBF?

No, the special sequence value UINT_MAX-1 disables RBF but also allows CLTV. UINT_MAX disables both.
what about CHECKSEQUENCEVERIFY? That appears to be broken by this as there is no dynamic range available for different sequence values. And relative block addressing is also broken [or forced to use RBF, which is same as broken to many]

Why does it make sense to give RBF such a large range?

What about micropayment protocols that track transactions with sequenceid, or any other use of sequenceid.

I would suggest using the LSB as the RBF flag, so it only uses one bit, which would only cause issues for sequenceid used for relative blocks for small intervals (though that can be fixed by dividing the sequenceid by two for relative block addressing). its usage as timestamp wont suffer much being limited to just the even numbered timestamps.

It also says that if ANY of the inputs has such a sequenceid, the RBF is enabled. Does that mean for all outputs? What if it is signed as SIGHASH_SINGLE? If so, why does an unrelated input/output affect the others. Even if this case isnt broken, having any input affect all of them could break some coinshuffle protocols where the inputs and outputs are pretty independent.

RBF sounds like a nice option to have, but by it using up 2^32-2 out of 2^32 values, basically we are saying sequenceid is for use by RBF and it will override other uses of sequenceid.

James

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
gmaxwell
Moderator
Legendary
*
qt
Offline Offline

Activity: 2562
Merit: 1669



View Profile
February 19, 2016, 10:45:42 PM
 #40

what about CHECKSEQUENCEVERIFY? That appears to be broken by this as there is no dynamic range available for different sequence values. And relative block addressing is also broken [or forced to use RBF, which is same as broken to many]
CSV doesn't exist yet; but sequence locks generally _require_ replacement in order to be usable: Otherwise someone could race with a less mature sequence and mempool preclude the more mature sequence.

I believe the rational in the design is that any transaction which is not marked _final_ will ultimately be subject to some kind of replacement. The conservative behavior for wallets that don't understand the details is that they should consider anything non-final ... as... non-final.  As other use cases come up the policy could be further restricted to specify what kinds of replacement should happen in what cases. BIP125 is very generic, which means that further changes to limit it's behavior are less likely to create surprise exposure for anyone.


Bitcoin will not be compromised
Pages: « 1 [2] 3 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!