Jeffrey Paul [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-19 📝 Original message:It seems to me that FSS ...
📅 Original date posted:2015-06-19
📝 Original message:It seems to me that FSS RBF must enforce identical OP_RETURN data on the output scripts as the first seen transaction, as well, to safely continue support for various other applications built atop the blockchain.
Is there a canonical implementation of FSS RBF around somewhere I can review?
Best,
-jp
--
Jeffrey Paul +1 (312) 361-0355
5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2
> On 19.06.2015, at 15:52, Chun Wang <1240902 at gmail.com> wrote:
>
> Before F2Pool's launch, I performed probably the only successful
> bitcoin double spend in the March 2013 fork without any mining power.
> [ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad
> the full RBF is. We are going to switch to FSS RBF in a few hours.
> Sorry.
>
>> On Fri, Jun 19, 2015 at 9:44 PM, Peter Todd <pete at petertodd.org> wrote:
>>> On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
>>> It is disappointing that F2Pool would enable full RBF when the safe
>>> alternative, first-seen-safe RBF, is also available, especially since the
>>> fees they would gain by supporting full RBF over FSS RBF would likely be
>>> negligible. Did they consider using FSS RBF instead?
>>
>> Specifically the following is what I told them:
>>
>>> We are
>>> interested in the replace-by-fee patch, but I am not following the
>>> development closely, more background info is needed, like what the
>>> difference between standard and zeroconf versions? Thanks.
>>
>> Great!
>>
>> Basically both let you replace one transaction with another that pays a
>> higher fee. First-seen-safe replace-by-fee adds the additional criteria
>> that all outputs of the old transaction still need to be paid by the new
>> transaction, with >= as many Bitcoins. Basically, it makes sure that if
>> someone was paid by tx1, then tx2 will still pay them.
>>
>> I've written about how wallets can use RBF and FSS-RBF to more
>> efficiently use the blockchain on the bitcoin-development mailing list:
>>
>> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
>> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html
>>
>> Basically, for the purpose of increasing fees, RBF is something like %50
>> cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
>>
>> In addition, for ease of implementation, my new FSS-RBF has a number of
>> other restrictions. For instance, you can't replace multiple
>> transactions with one, you can't replace a transaction whose outputs
>> have already been spent, you can't replace a transaction with one that
>> spends additional unconfirmed inputs, etc. These restrictions aren't
>> "set in stone", but they do make the code simpler and less likely to
>> have bugs.
>>
>> In comparison my previous standard RBF patch can replace multiple
>> transactions with one, can replace long chains of transactions, etc.
>> It's willing to do more computation before deciding if a transaction
>> should be replaced, with more complex logic; it probably has a higher
>> chance of having a bug or DoS attack.
>>
>> You've probably seen the huge controversy around zeroconf with regard to
>> standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
>> it also doesn't make it any more dangerous, so politically with regard
>> to zeroconf it makes no difference. You *can* still use it doublespend
>> by taking advantage of how different transactions are accepted
>> differently, but that's true of *every* change we've ever made to
>> Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
>> zeroconf in the same way.
>>
>>
>> Having said that... honestly, zeroconf is pretty broken already. Only
>> with pretty heroic measures like connecting to a significant fraction of
>> the Bitcoin network at once, as well as connecting to getblocktemplate
>> supporting miners to figure out what transactions are being mined, are
>> services having any hope of avoiding getting ripped off. For the average
>> user their wallets do a terrible job of showing whether or not an
>> unconfirmed transaction will go through. For example, Schildbach's
>> Bitcoin wallet for Android has no code at all to detect double-spends
>> until they get mined, and I've been able to trick it into showing
>> completely invalid transactions. In fact, currently Bitcoin XT will
>> relay invalid transactions that are doublepsends, and Schildbach's
>> wallet displays them as valid, unconfirmed, payments. It's really no
>> surprise to me that nearly no-one in the Bitcoin ecosystem accepts
>> unconfirmed transactions without some kind of protection that doesn't
>> rely on first-seen-safe mempool behavior. For instance, many ATM's these
>> days know who their customers are due to AML requirements, so while you
>> can deposit Bitcoins and get your funds instantly, the protection for
>> the ATM operator is that they can go to the police if you rip them off;
>> I've spoken to ATM operators who didn't do this who've lost hundreds or
>> even thousands of dollars before giving up on zeroconf.
>>
>> My big worry with zeroconf is a service like Coinbase or Shapeshift
>> coming to rely on it, and then attempting to secure it by gaining
>> control of a majority of hashing power. For instance, if Coinbase had
>> contracts with 80% of the Bitcoin hashing power to guarantee their
>> transactions would get mined, but 20% of the hashing power didn't sign
>> up, then the only way to guarantee their transactions could be for the
>> 80% to not build on blocks containing doublespends by the 20%. There's
>> no way in a decentralized network to come to consensus about what
>> transactions are or are not valid without mining itself, so you could
>> end up in a situation where unless you're part of one of the big pools
>> you can't reliably mine at all because your blocks may get rejected for
>> containing doublespends.
>>
>> One of my goal with standard replace-by-fee is to prevent this scenario
>> by forcing merchants and others to implement ways of accepting zeroconf
>> transactions safely that work in a decentralized environment regardless
>> of what miners do; we have a stronger and safer Bitcoin ecosystem if
>> we're relying on math rather than trust to secure our zeroconf
>> transactions. We're also being more honest to users, who right now often
>> have the very wrong impression that unconfirmed transactions are safe to
>> accept - this does get people ripped off all too often!
>>
>>
>> Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am
>> waiting to get some feedback:
>>
>> https://github.com/bitcoin/bitcoin/pull/6176
>>
>> Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
>> working on porting it to v0.10.2, and once that's done I'm going to put
>> up a bounty for anyone who can find a DoS attack in the patch. If no-one
>> claims the bounty after a week or two I think I'll start feeling
>> confident about using it in production.
>>
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
📝 Original message:It seems to me that FSS RBF must enforce identical OP_RETURN data on the output scripts as the first seen transaction, as well, to safely continue support for various other applications built atop the blockchain.
Is there a canonical implementation of FSS RBF around somewhere I can review?
Best,
-jp
--
Jeffrey Paul +1 (312) 361-0355
5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2
> On 19.06.2015, at 15:52, Chun Wang <1240902 at gmail.com> wrote:
>
> Before F2Pool's launch, I performed probably the only successful
> bitcoin double spend in the March 2013 fork without any mining power.
> [ https://bitcointalk.org/index.php?topic=152348.0 ] I know how bad
> the full RBF is. We are going to switch to FSS RBF in a few hours.
> Sorry.
>
>> On Fri, Jun 19, 2015 at 9:44 PM, Peter Todd <pete at petertodd.org> wrote:
>>> On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote:
>>> It is disappointing that F2Pool would enable full RBF when the safe
>>> alternative, first-seen-safe RBF, is also available, especially since the
>>> fees they would gain by supporting full RBF over FSS RBF would likely be
>>> negligible. Did they consider using FSS RBF instead?
>>
>> Specifically the following is what I told them:
>>
>>> We are
>>> interested in the replace-by-fee patch, but I am not following the
>>> development closely, more background info is needed, like what the
>>> difference between standard and zeroconf versions? Thanks.
>>
>> Great!
>>
>> Basically both let you replace one transaction with another that pays a
>> higher fee. First-seen-safe replace-by-fee adds the additional criteria
>> that all outputs of the old transaction still need to be paid by the new
>> transaction, with >= as many Bitcoins. Basically, it makes sure that if
>> someone was paid by tx1, then tx2 will still pay them.
>>
>> I've written about how wallets can use RBF and FSS-RBF to more
>> efficiently use the blockchain on the bitcoin-development mailing list:
>>
>> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07813.html
>> http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07829.html
>>
>> Basically, for the purpose of increasing fees, RBF is something like %50
>> cheaper than CPFP, and FSS-RBF is something like %25 cheaper.
>>
>> In addition, for ease of implementation, my new FSS-RBF has a number of
>> other restrictions. For instance, you can't replace multiple
>> transactions with one, you can't replace a transaction whose outputs
>> have already been spent, you can't replace a transaction with one that
>> spends additional unconfirmed inputs, etc. These restrictions aren't
>> "set in stone", but they do make the code simpler and less likely to
>> have bugs.
>>
>> In comparison my previous standard RBF patch can replace multiple
>> transactions with one, can replace long chains of transactions, etc.
>> It's willing to do more computation before deciding if a transaction
>> should be replaced, with more complex logic; it probably has a higher
>> chance of having a bug or DoS attack.
>>
>> You've probably seen the huge controversy around zeroconf with regard to
>> standard replace-by-fee. While FSS RBF doesn't make zeroconf any safer,
>> it also doesn't make it any more dangerous, so politically with regard
>> to zeroconf it makes no difference. You *can* still use it doublespend
>> by taking advantage of how different transactions are accepted
>> differently, but that's true of *every* change we've ever made to
>> Bitcoin Core - by upgrading to v0.10 from v0.9 you've also "broken"
>> zeroconf in the same way.
>>
>>
>> Having said that... honestly, zeroconf is pretty broken already. Only
>> with pretty heroic measures like connecting to a significant fraction of
>> the Bitcoin network at once, as well as connecting to getblocktemplate
>> supporting miners to figure out what transactions are being mined, are
>> services having any hope of avoiding getting ripped off. For the average
>> user their wallets do a terrible job of showing whether or not an
>> unconfirmed transaction will go through. For example, Schildbach's
>> Bitcoin wallet for Android has no code at all to detect double-spends
>> until they get mined, and I've been able to trick it into showing
>> completely invalid transactions. In fact, currently Bitcoin XT will
>> relay invalid transactions that are doublepsends, and Schildbach's
>> wallet displays them as valid, unconfirmed, payments. It's really no
>> surprise to me that nearly no-one in the Bitcoin ecosystem accepts
>> unconfirmed transactions without some kind of protection that doesn't
>> rely on first-seen-safe mempool behavior. For instance, many ATM's these
>> days know who their customers are due to AML requirements, so while you
>> can deposit Bitcoins and get your funds instantly, the protection for
>> the ATM operator is that they can go to the police if you rip them off;
>> I've spoken to ATM operators who didn't do this who've lost hundreds or
>> even thousands of dollars before giving up on zeroconf.
>>
>> My big worry with zeroconf is a service like Coinbase or Shapeshift
>> coming to rely on it, and then attempting to secure it by gaining
>> control of a majority of hashing power. For instance, if Coinbase had
>> contracts with 80% of the Bitcoin hashing power to guarantee their
>> transactions would get mined, but 20% of the hashing power didn't sign
>> up, then the only way to guarantee their transactions could be for the
>> 80% to not build on blocks containing doublespends by the 20%. There's
>> no way in a decentralized network to come to consensus about what
>> transactions are or are not valid without mining itself, so you could
>> end up in a situation where unless you're part of one of the big pools
>> you can't reliably mine at all because your blocks may get rejected for
>> containing doublespends.
>>
>> One of my goal with standard replace-by-fee is to prevent this scenario
>> by forcing merchants and others to implement ways of accepting zeroconf
>> transactions safely that work in a decentralized environment regardless
>> of what miners do; we have a stronger and safer Bitcoin ecosystem if
>> we're relying on math rather than trust to secure our zeroconf
>> transactions. We're also being more honest to users, who right now often
>> have the very wrong impression that unconfirmed transactions are safe to
>> accept - this does get people ripped off all too often!
>>
>>
>> Anyway, sorry for the rant! FWIW I updated my FSS-RBF patch and am
>> waiting to get some feedback:
>>
>> https://github.com/bitcoin/bitcoin/pull/6176
>>
>> Suhas Daftuar did find a pretty serious bug in it, now fixed. I'm
>> working on porting it to v0.10.2, and once that's done I'm going to put
>> up a bounty for anyone who can find a DoS attack in the patch. If no-one
>> claims the bounty after a week or two I think I'll start feeling
>> confident about using it in production.
>>
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 000000000000000003188926be14e5fbe2f8f9c63c9fb8e2ba4b14ab04f1c9ab
>>
>> ------------------------------------------------------------------------------
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development