Re: [bitcoin-dev] Concern about "Inscriptions". (ashneverdawn)

Re: [bitcoin-dev] Concern about "Inscriptions". (ashneverdawn)

[Hugo L]

[-- Attachment #1: Type: text/plain, Size: 13453 bytes --]

I don't think it's anyone's place to judge which types of transactions
should be allowed or not on the network, in fact, when it comes to privacy
and censorship resistance, it would be better if we were not even able to
distinguish different types of transactions from one another in the first
place.

We have limited resources on the blockchain and so they should go to the
highest bidder. This is already how the network functions and how it
ensures it's security.

Rather than thinking about this as "spam", I think it's useful to
objectively think about it in terms of value to the marketplace (fees
they're willing to pay) against cost to the network (storage consumed). It
comes down to supply and demand.

If the rate of growth of the blockchain is too high, Ordinals aren't the
cause, it's rather that the theoretical limit of the amount of storage that
can be added per block isn't sufficiently limited. (Whether they are used
to produce Ordinals or something else)



On Sun, Jul 30, 2023, 5:51 PM , <
bitcoin-dev-request@lists.linuxfoundation.org> wrote:

> Send bitcoin-dev mailing list submissions to
>         bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
>         bitcoin-dev-request@lists.linuxfoundation.org
>
> You can reach the person managing the list at
>         bitcoin-dev-owner@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Concern about "Inscriptions". (rot13maxi)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 30 Jul 2023 18:34:12 +0000
> From: rot13maxi <rot13maxi@protonmail.com>
> To: L?o Haf <leohaf@orangepill.ovh>, "vjudeu@gazeta.pl"
>         <vjudeu@gazeta.pl>
> Cc: Bitcoin Protocol Discussion
>         <bitcoin-dev@lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
> Message-ID:
>
> <RIqguuebFmAhEDqCY_0T8KRqHBXEfcvPw6-MbDIyWsAWpLenFFeOVx88-068QFZr7xowg-6Zg988HsRCKdswtZC6QUKPXnrTyTAc_l5jphg=@
> protonmail.com>
>
> Content-Type: text/plain; charset="utf-8"
>
> Hello,
>
> > This cat and mouse game can be won by bitcoin defenders. Why ? Because
> it is easier to detect these transactions and make them a standardization
> rule than to create new types of spam transactions.
>
> One of the things discussed during the mempoolfullrbf discussion is that a
> small (~10%) of nodes willing to relay a class of transaction is enough for
> that class of transaction to consistently reach miners. That means you
> would need to get nearly the entire network to run updated relay policy to
> prevent inscriptions from trivially reaching miners and being included in
> blocks. Inscription users have shown that they are willing and able to send
> non-standard transactions to miners out of band (
> https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae),
> so even if you managed to get enough of the network running the new rule to
> prevent propagation to miners, those users can just go out of band. Or,
> they can simply change the script that is used to embed an inscription in
> the transaction witness. For example, instead of 0 OP_IF?, maybe they do 0
> OP_DUP OP_DROP OP_IF. When the anti-inscription people detect this, they
> have to update the rule and wait for 90%
>  + of the network to upgrade. When the pro-inscription people see this,
> they only have to convince other inscription enthusiasts and businesses to
> update.
>
> The anti-inscription patch has to be run by many more participants (most
> of whom don?t care), while the pro-inscription update has to be run by a
> small number of people who care a lot. It?s a losing battle for the
> anti-inscription people.
>
> If you want to prevent inscriptions, the best answer we know of today is
> economic: the cost of the blockspace needs to be more expensive than
> inscribers are willing to pay, either because its too expensive or because
> there?s no market demand for inscriptions. The former relies on Bitcoin
> becoming more useful to more people, the latter is the natural course of
> collectibles.
>
> > Finally, I would like to quote satoshi himself who wrote about spam here
> is the link: https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
>
> Appeals to Satoshi are not compelling arguments.
>
> Cheers,
> Rijndael
>
> On Sun, Jul 30, 2023 at 2:04 PM, L?o Haf via bitcoin-dev <[
> bitcoin-dev@lists.linuxfoundation.org](mailto:On Sun, Jul 30, 2023 at
> 2:04 PM, L?o Haf via bitcoin-dev <<a href=)> wrote:
>
> > ?According to you, the rules of standardization are useless but in this
> case why were they introduced? The opreturn limit can be circumvented by
> miners, yet it is rare to see any, the same for maxancestorcount,
> minrelayfee or even the dust limit.
> >
> > This cat and mouse game can be won by bitcoin defenders. Why ? Because
> it is easier to detect these transactions and make them a standardization
> rule than to create new types of spam transactions.
> >
> > As for the default policy, it can be a weakness but also a strength
> because if the patch is integrated into Bitcoin Core by being activated by
> default, the patch will become more and more effective as the nodes update.
> >
> > Also, when it came to using a pre-segwit node, it is not a solution
> because this type of node cannot initiate new ones, which is obviously a
> big problem.
> >
> > Finally, I would like to quote satoshi himself who wrote about spam here
> is the link: https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
> >
> >> Le 27 juil. 2023 ? 07:10, vjudeu@gazeta.pl a ?crit :
> >
> >>
> >
> >> ?
> >
> >>> not taking action against these inscription could be interpreted by
> spammers as tacit acceptance of their practice.
> >
> >>
> >
> >> Note that some people, even on this mailing list, do not consider
> Ordinals as spam:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021464.html
> >
> >>
> >
> >> See? It was discussed when it started. Some people believe that
> blocking Ordinals is censorship, and could lead to blocking regular
> transactions in the future, just based on other criteria. That means, even
> if developers would create some official version with that option, then
> some people would not follow them, or even block Ordinals-filtering nodes,
> exactly as described in the linked thread:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021487.html
> >
> >>
> >
> >>> as spammers might perceive that the Bitcoin network tolerates this
> kind of behavior
> >
> >>
> >
> >> But it is true, you have the whole pages, where you can find images,
> files, or other data, that was pushed on-chain long before Ordinals. The
> whole whitepaper was uploaded just on 1-of-3 multisig outputs, see
> transaction
> 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713. You have
> the whole altcoins that are connected to Bitcoin by using part of the
> Bitcoin's UTXO set as their database.
> >
> >>
> >
> >> That means, as long as you won't solve IBD problem and UTXO set growing
> problem, you will go nowhere, because if you block Ordinals specifically,
> people won't learn "this is bad, don't do that", they could read it as "use
> the old way instead", as long as you won't block all possible ways. And
> doing that, requires for example creating new nodes, without synchronizing
> non-consensus data, like it could be done in "assume UTXO" model.
> >
> >>
> >
> >> Also note that as long as people use Taproot to upload a lot of data,
> you can still turn off the witness, and become a pre-Segwit node. But if
> you block those ways, then people will push data into legacy parts, and
> then you will need more code to strip it correctly. The block 774628 maybe
> contains almost 4 MB of data from the perspective of Segwit node, but the
> legacy part is actually very small, so by turning witness off, you can
> strip it to maybe just a few kilobytes.
> >
> >>
> >
> >>> I want to emphasize that my proposal does not involve implementing a
> soft fork in any way. On the contrary, what I am asking is simply to
> consider adding a standardization option. This option would allow the
> community to freely decide whether it should be activated or not.
> >
> >>
> >
> >> 1. Without a soft-fork, those data will be pushed by mining pools
> anyway, as it happened in the block 774628.
> >
> >> 2. Adding some settings won't help, as most people use the default
> configuration. For example, people can configure their nodes to allow free
> transactions, without recompiling anything. The same with disabling dust
> amounts. But good luck finding a node in the wild that does anything
> unusual.
> >
> >> 3. This patch produced by Luke Dashjr does not address all cases. You
> could use "OP_TRUE OP_NOTIF" instead of "OP_FALSE OP_IF" used by Ordinals,
> and easily bypass those restrictions. This will be just a cat and mouse
> game, where spammers will even use P2PK, if they will be forced to. The
> Pandora's box is already opened, that fix could be good for February or
> March, but not now.
> >
> >>
> >
> >>
> >
> >>
> >
> >>> On 2023-07-26 11:47:09 user leohaf@orangepill.ovh wrote:
> >
> >>> I understand your point of view. However, inscription represent by far
> the largest spam attack due to their ability to embed themselves in the
> witness with a fee reduction.
> >
> >>
> >
> >> Unlike other methods, such as using the op_return field which could
> also be used to spam the chain, the associated fees and the standardization
> rule limiting op_return to 80 bytes have so far prevented similar abuses.
> >
> >>
> >
> >> Although attempting to stop inscription could lead to more serious
> issues, not taking action against these inscription could be interpreted by
> spammers as tacit acceptance of their practice. This could encourage more
> similar spam attacks in the future, as spammers might perceive that the
> Bitcoin network tolerates this kind of behavior.
> >
> >>
> >
> >> I want to emphasize that my proposal does not involve implementing a
> soft fork in any way. On the contrary, what I am asking is simply to
> consider adding a standardization option. This option would allow the
> community to freely decide whether it should be activated or not.
> >
> >>
> >
> >>
> >
> >>>> Le 26 juil. 2023 ? 07:30, vjudeu@gazeta.pl a ?crit :
> >
> >>>> and I would like to understand why this problem has not been
> addressed more seriously
> >
> >>> Because if nobody has any good solution, then status quo is preserved.
> If tomorrow ECDSA would be broken, the default state of the network would
> be "just do nothing", and every solution would be backward-compatible with
> that approach. Burn old coins, and people will call it "Tether",
> redistribute them, and people will call it "BSV". Leave everything
> untouched, and the network will split into N parts, and then you pick the
> strongest chain to decide, what should be done.
> >
> >>>> However, when it comes to inscriptions, there are no available
> options except for a patch produced by Luke Dashjr.
> >
> >>> Because the real solution should address some different problem, that
> was always there, and nobody knows, how to deal with it: the problem of
> forever-growing initial blockchain download time, and forever-growing UTXO
> set. Some changes with "assume UTXO" are trying to address just that, but
> this code is not yet completed.
> >
> >>>> So, I wonder why there are no options to reject inscriptions in the
> mempool of a node.
> >
> >>> Because it will lead you to never ending chase. You will block one
> inscriptions, and different ones will be created. Now, they are present
> even on chains, where there is no Taproot, or even Segwit. That means, if
> you try to kill them, then they will be replaced by N regular
> indistinguishable transactions, and then you will go back to those more
> serious problems under the hood: IBD time, and UTXO size.
> >
> >>>> Inscriptions are primarily used to sell NFTs or Tokens, concepts that
> the Bitcoin community has consistently rejected.
> >
> >>> The community also rejected things like sidechains, and they are still
> present, just in a more centralized form. There are some unstoppable
> concepts, for example soft-forks. You cannot stop a soft-fork. What
> inscription creators did, is just non-enforced soft-fork. They believe
> their rules are followed to the letter, but this is not the case, as you
> can create a valid Bitcoin transaction, that will be some invalid Ordinals
> transaction (because their additional rules are not enforced by miners and
> nodes).
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230730/dfc353d3/attachment.html
> >
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> ------------------------------
>
> End of bitcoin-dev Digest, Vol 98, Issue 20
> *******************************************
>

[-- Attachment #2: Type: text/html, Size: 17180 bytes --]

Re: [bitcoin-dev] Concern about "Inscriptions". (ashneverdawn)

[Keagan McClelland]

[-- Attachment #1: Type: text/plain, Size: 15296 bytes --]

There is an open question as to whether or not we should figure out a way
to price space in the UTXO set. I think it is fair to say that given the
fact that the UTXO set space remains unpriced that we actually have no way
to determine whether some of these transactions are spam or not. The UTXO
set must be maintained by all nodes including pruned nodes, whereas main
block and witness data do not have the same type of indefinite footprint,
so in some sense it is an even more significant resource than chain space.
We may very well discover that if we price UTXOs in a way that reflect the
resource costs that usage of inscriptions would vanish. The trouble though
is that such a mechanism would imply having to pay "rent" for an "account"
with Bitcoin, a proposition that would likely be offensive to a significant
portion of the Bitcoin user base.

Cheers,
Keags

On Mon, Jul 31, 2023 at 4:55 AM Hugo L via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I don't think it's anyone's place to judge which types of transactions
> should be allowed or not on the network, in fact, when it comes to privacy
> and censorship resistance, it would be better if we were not even able to
> distinguish different types of transactions from one another in the first
> place.
>
> We have limited resources on the blockchain and so they should go to the
> highest bidder. This is already how the network functions and how it
> ensures it's security.
>
> Rather than thinking about this as "spam", I think it's useful to
> objectively think about it in terms of value to the marketplace (fees
> they're willing to pay) against cost to the network (storage consumed). It
> comes down to supply and demand.
>
> If the rate of growth of the blockchain is too high, Ordinals aren't the
> cause, it's rather that the theoretical limit of the amount of storage that
> can be added per block isn't sufficiently limited. (Whether they are used
> to produce Ordinals or something else)
>
>
>
> On Sun, Jul 30, 2023, 5:51 PM , <
> bitcoin-dev-request@lists.linuxfoundation.org> wrote:
>
>> Send bitcoin-dev mailing list submissions to
>>         bitcoin-dev@lists.linuxfoundation.org
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>>         https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> or, via email, send a message with subject or body 'help' to
>>         bitcoin-dev-request@lists.linuxfoundation.org
>>
>> You can reach the person managing the list at
>>         bitcoin-dev-owner@lists.linuxfoundation.org
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of bitcoin-dev digest..."
>>
>>
>> Today's Topics:
>>
>>    1. Re: Concern about "Inscriptions". (rot13maxi)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Sun, 30 Jul 2023 18:34:12 +0000
>> From: rot13maxi <rot13maxi@protonmail.com>
>> To: L?o Haf <leohaf@orangepill.ovh>, "vjudeu@gazeta.pl"
>>         <vjudeu@gazeta.pl>
>> Cc: Bitcoin Protocol Discussion
>>         <bitcoin-dev@lists.linuxfoundation.org>
>> Subject: Re: [bitcoin-dev] Concern about "Inscriptions".
>> Message-ID:
>>
>> <RIqguuebFmAhEDqCY_0T8KRqHBXEfcvPw6-MbDIyWsAWpLenFFeOVx88-068QFZr7xowg-6Zg988HsRCKdswtZC6QUKPXnrTyTAc_l5jphg=@
>> protonmail.com>
>>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Hello,
>>
>> > This cat and mouse game can be won by bitcoin defenders. Why ? Because
>> it is easier to detect these transactions and make them a standardization
>> rule than to create new types of spam transactions.
>>
>> One of the things discussed during the mempoolfullrbf discussion is that
>> a small (~10%) of nodes willing to relay a class of transaction is enough
>> for that class of transaction to consistently reach miners. That means you
>> would need to get nearly the entire network to run updated relay policy to
>> prevent inscriptions from trivially reaching miners and being included in
>> blocks. Inscription users have shown that they are willing and able to send
>> non-standard transactions to miners out of band (
>> https://mempool.space/tx/0301e0480b374b32851a9462db29dc19fe830a7f7d7a88b81612b9d42099c0ae),
>> so even if you managed to get enough of the network running the new rule to
>> prevent propagation to miners, those users can just go out of band. Or,
>> they can simply change the script that is used to embed an inscription in
>> the transaction witness. For example, instead of 0 OP_IF?, maybe they do 0
>> OP_DUP OP_DROP OP_IF. When the anti-inscription people detect this, they
>> have to update the rule and wait for 90%
>>  + of the network to upgrade. When the pro-inscription people see this,
>> they only have to convince other inscription enthusiasts and businesses to
>> update.
>>
>> The anti-inscription patch has to be run by many more participants (most
>> of whom don?t care), while the pro-inscription update has to be run by a
>> small number of people who care a lot. It?s a losing battle for the
>> anti-inscription people.
>>
>> If you want to prevent inscriptions, the best answer we know of today is
>> economic: the cost of the blockspace needs to be more expensive than
>> inscribers are willing to pay, either because its too expensive or because
>> there?s no market demand for inscriptions. The former relies on Bitcoin
>> becoming more useful to more people, the latter is the natural course of
>> collectibles.
>>
>> > Finally, I would like to quote satoshi himself who wrote about spam
>> here is the link:
>> https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
>>
>> Appeals to Satoshi are not compelling arguments.
>>
>> Cheers,
>> Rijndael
>>
>> On Sun, Jul 30, 2023 at 2:04 PM, L?o Haf via bitcoin-dev <[
>> bitcoin-dev@lists.linuxfoundation.org](mailto:On Sun, Jul 30, 2023 at
>> 2:04 PM, L?o Haf via bitcoin-dev <<a href=)> wrote:
>>
>> > ?According to you, the rules of standardization are useless but in this
>> case why were they introduced? The opreturn limit can be circumvented by
>> miners, yet it is rare to see any, the same for maxancestorcount,
>> minrelayfee or even the dust limit.
>> >
>> > This cat and mouse game can be won by bitcoin defenders. Why ? Because
>> it is easier to detect these transactions and make them a standardization
>> rule than to create new types of spam transactions.
>> >
>> > As for the default policy, it can be a weakness but also a strength
>> because if the patch is integrated into Bitcoin Core by being activated by
>> default, the patch will become more and more effective as the nodes update.
>> >
>> > Also, when it came to using a pre-segwit node, it is not a solution
>> because this type of node cannot initiate new ones, which is obviously a
>> big problem.
>> >
>> > Finally, I would like to quote satoshi himself who wrote about spam
>> here is the link:
>> https://bitcointalk.org/index.php?topic=195.msg1617#msg1617
>> >
>> >> Le 27 juil. 2023 ? 07:10, vjudeu@gazeta.pl a ?crit :
>> >
>> >>
>> >
>> >> ?
>> >
>> >>> not taking action against these inscription could be interpreted by
>> spammers as tacit acceptance of their practice.
>> >
>> >>
>> >
>> >> Note that some people, even on this mailing list, do not consider
>> Ordinals as spam:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021464.html
>> >
>> >>
>> >
>> >> See? It was discussed when it started. Some people believe that
>> blocking Ordinals is censorship, and could lead to blocking regular
>> transactions in the future, just based on other criteria. That means, even
>> if developers would create some official version with that option, then
>> some people would not follow them, or even block Ordinals-filtering nodes,
>> exactly as described in the linked thread:
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021487.html
>> >
>> >>
>> >
>> >>> as spammers might perceive that the Bitcoin network tolerates this
>> kind of behavior
>> >
>> >>
>> >
>> >> But it is true, you have the whole pages, where you can find images,
>> files, or other data, that was pushed on-chain long before Ordinals. The
>> whole whitepaper was uploaded just on 1-of-3 multisig outputs, see
>> transaction
>> 54e48e5f5c656b26c3bca14a8c95aa583d07ebe84dde3b7dd4a78f4e4186e713. You have
>> the whole altcoins that are connected to Bitcoin by using part of the
>> Bitcoin's UTXO set as their database.
>> >
>> >>
>> >
>> >> That means, as long as you won't solve IBD problem and UTXO set
>> growing problem, you will go nowhere, because if you block Ordinals
>> specifically, people won't learn "this is bad, don't do that", they could
>> read it as "use the old way instead", as long as you won't block all
>> possible ways. And doing that, requires for example creating new nodes,
>> without synchronizing non-consensus data, like it could be done in "assume
>> UTXO" model.
>> >
>> >>
>> >
>> >> Also note that as long as people use Taproot to upload a lot of data,
>> you can still turn off the witness, and become a pre-Segwit node. But if
>> you block those ways, then people will push data into legacy parts, and
>> then you will need more code to strip it correctly. The block 774628 maybe
>> contains almost 4 MB of data from the perspective of Segwit node, but the
>> legacy part is actually very small, so by turning witness off, you can
>> strip it to maybe just a few kilobytes.
>> >
>> >>
>> >
>> >>> I want to emphasize that my proposal does not involve implementing a
>> soft fork in any way. On the contrary, what I am asking is simply to
>> consider adding a standardization option. This option would allow the
>> community to freely decide whether it should be activated or not.
>> >
>> >>
>> >
>> >> 1. Without a soft-fork, those data will be pushed by mining pools
>> anyway, as it happened in the block 774628.
>> >
>> >> 2. Adding some settings won't help, as most people use the default
>> configuration. For example, people can configure their nodes to allow free
>> transactions, without recompiling anything. The same with disabling dust
>> amounts. But good luck finding a node in the wild that does anything
>> unusual.
>> >
>> >> 3. This patch produced by Luke Dashjr does not address all cases. You
>> could use "OP_TRUE OP_NOTIF" instead of "OP_FALSE OP_IF" used by Ordinals,
>> and easily bypass those restrictions. This will be just a cat and mouse
>> game, where spammers will even use P2PK, if they will be forced to. The
>> Pandora's box is already opened, that fix could be good for February or
>> March, but not now.
>> >
>> >>
>> >
>> >>
>> >
>> >>
>> >
>> >>> On 2023-07-26 11:47:09 user leohaf@orangepill.ovh wrote:
>> >
>> >>> I understand your point of view. However, inscription represent by
>> far the largest spam attack due to their ability to embed themselves in the
>> witness with a fee reduction.
>> >
>> >>
>> >
>> >> Unlike other methods, such as using the op_return field which could
>> also be used to spam the chain, the associated fees and the standardization
>> rule limiting op_return to 80 bytes have so far prevented similar abuses.
>> >
>> >>
>> >
>> >> Although attempting to stop inscription could lead to more serious
>> issues, not taking action against these inscription could be interpreted by
>> spammers as tacit acceptance of their practice. This could encourage more
>> similar spam attacks in the future, as spammers might perceive that the
>> Bitcoin network tolerates this kind of behavior.
>> >
>> >>
>> >
>> >> I want to emphasize that my proposal does not involve implementing a
>> soft fork in any way. On the contrary, what I am asking is simply to
>> consider adding a standardization option. This option would allow the
>> community to freely decide whether it should be activated or not.
>> >
>> >>
>> >
>> >>
>> >
>> >>>> Le 26 juil. 2023 ? 07:30, vjudeu@gazeta.pl a ?crit :
>> >
>> >>>> and I would like to understand why this problem has not been
>> addressed more seriously
>> >
>> >>> Because if nobody has any good solution, then status quo is
>> preserved. If tomorrow ECDSA would be broken, the default state of the
>> network would be "just do nothing", and every solution would be
>> backward-compatible with that approach. Burn old coins, and people will
>> call it "Tether", redistribute them, and people will call it "BSV". Leave
>> everything untouched, and the network will split into N parts, and then you
>> pick the strongest chain to decide, what should be done.
>> >
>> >>>> However, when it comes to inscriptions, there are no available
>> options except for a patch produced by Luke Dashjr.
>> >
>> >>> Because the real solution should address some different problem, that
>> was always there, and nobody knows, how to deal with it: the problem of
>> forever-growing initial blockchain download time, and forever-growing UTXO
>> set. Some changes with "assume UTXO" are trying to address just that, but
>> this code is not yet completed.
>> >
>> >>>> So, I wonder why there are no options to reject inscriptions in the
>> mempool of a node.
>> >
>> >>> Because it will lead you to never ending chase. You will block one
>> inscriptions, and different ones will be created. Now, they are present
>> even on chains, where there is no Taproot, or even Segwit. That means, if
>> you try to kill them, then they will be replaced by N regular
>> indistinguishable transactions, and then you will go back to those more
>> serious problems under the hood: IBD time, and UTXO size.
>> >
>> >>>> Inscriptions are primarily used to sell NFTs or Tokens, concepts
>> that the Bitcoin community has consistently rejected.
>> >
>> >>> The community also rejected things like sidechains, and they are
>> still present, just in a more centralized form. There are some unstoppable
>> concepts, for example soft-forks. You cannot stop a soft-fork. What
>> inscription creators did, is just non-enforced soft-fork. They believe
>> their rules are followed to the letter, but this is not the case, as you
>> can create a valid Bitcoin transaction, that will be some invalid Ordinals
>> transaction (because their additional rules are not enforced by miners and
>> nodes).
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL: <
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230730/dfc353d3/attachment.html
>> >
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> ------------------------------
>>
>> End of bitcoin-dev Digest, Vol 98, Issue 20
>> *******************************************
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 18920 bytes --]

[bitcoin-dev] Pull-req to enable Full-RBF by default

[Daniel Lipshitz]

[-- Attachment #1: Type: text/plain, Size: 1671 bytes --]

This would unnecessarily and extremely negatively impact merchants and
users who choose to accept 0-conf while using mitigation tools like GAP600.
This negative impact could be avoided by simply adding first seen safe rule
- ie a trx can be replaced but needs to include the original outputs.

At GAP600 we continue to see strong use of our service for BTC we have seen
circa 350k unique trx hash per month (over the last 3 months) requested to
our platform. Our clients include - Coinpayments, Coinspaid and Changelly.
Given the period of Mempool being full we have seen an increase in the fee
required in order to be approved by our platform for trx. This is not an
insignificant use case and one which can be easily maintained as is.

We have provided further statistics in the past and direct feedback from
Coinspaid CEO with in the mailing list see here -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021240.html

We have not seen any impact of full RBF on double spend rates for our trxs
which seems to put in large question the stated figure of 40% adoption by
miners at such a rate of adoption we would expect to see a large increase
in double spends. We expect once this setting becomes default this will
greatly change the adoption of this service.
GAP600 model targets not to get it wrong and as such we are very sensitive
to any double spend which we get wrong in predicting as we reimburse our
clients. GAP600 is not a payment processor; rather services payment
processors, merchants and non custodial liquidity providers which service
non-custodial wallets.

________________________________

Daniel Lipshitz
GAP600| www.gap600.com

[-- Attachment #2: Type: text/html, Size: 3819 bytes --]

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

On Mon, Jul 31, 2023 at 01:26:11PM +0300, Daniel Lipshitz via bitcoin-dev wrote:
> This would unnecessarily and extremely negatively impact merchants and
> users who choose to accept 0-conf while using mitigation tools like GAP600.
> This negative impact could be avoided by simply adding first seen safe rule
> - ie a trx can be replaced but needs to include the original outputs.
> 
> At GAP600 we continue to see strong use of our service for BTC we have seen
> circa 350k unique trx hash per month (over the last 3 months) requested to
> our platform. Our clients include - Coinpayments, Coinspaid and Changelly.

I checked, and Coinpayments and Coinspaid are both merchant processors. I could
not find any example of actual merchants using their platform accepting
unconfirmed payments. I also could not find any documentation on their websites
indicating unconfirmed transaction acceptance.

As for Changelly, their website says right on the front that "With an average
transaction speed of 5–40 minutes, we ensure you can swiftly take advantage of
market opportunities." Obivously, 5 minutes is not an unconfirmed payment.

Additionally, I verified myself by doing test transactions with BIP125 disabled
and an adequate fee: unconfirmed payments are not accepted by Changelly. As
their exchange flow clearly says "Once BTC is confirmed in the blockchain,
we’ll start exchanging it to <coin>."

You need to provide an genuine example of an actual merchant who accepts
unconfirmed transactions as payment, and actually relies on first-seen
behavior.

> We have not seen any impact of full RBF on double spend rates for our trxs

Based on the above findings, this appears to be because you don't actually have
any clients who rely on unconfirmed payments.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

[Daniel Lipshitz]

[-- Attachment #1: Type: text/plain, Size: 3926 bytes --]

Your research is not thorough and reaches an incorrect conclusion.

As stated many times - we service payment processors and some merchants
directly  - Coinspaid services multiple merchants and process a
significant amount of BTC they are a well known and active in the space -
as I provided back in December 2022 a email from Max the CEO of Coinspaid
confirming their use of 0-conf as well as providing there cluster addresses
to validate there deposit flows see here again -
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
- if this is not sufficient then please email support@coinspaid.com and ask
to be connected to Max or someone from the team who can confirm Conspaid is
clients of GAP600. Max also at the time was open to do a call, I can check
again now and see if this is still the case and connect you.

That on its own is enough of a sample to validate our statistics.

I have also spoken to Changelly earlier today and they offered to email pro
@ changelly.com and they will be able to confirm GAP600 as a service
provider. Also please send me the 1 trx hash you tested and I can see if it
was queried to our system and if so offer some info as to why it wasnt
approved. Also if you can elaborate how you integrated with Changelly - I
can check with them if that area is not integrated with GAP600.

As the architect of such a major change to the status of 0-conf
transactions I would think you would welcome the opportunity to speak to
business and users who actual activities will be impacted by full RBF
becoming dominant.

Are you able to provide the same i.e emails and contacts of people at
the mining pools who can confirm they have adopted FULL RBF ?

________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz


On Tue, Aug 1, 2023 at 6:04 PM Peter Todd <pete@petertodd.org> wrote:

> On Mon, Jul 31, 2023 at 01:26:11PM +0300, Daniel Lipshitz via bitcoin-dev
> wrote:
> > This would unnecessarily and extremely negatively impact merchants and
> > users who choose to accept 0-conf while using mitigation tools like
> GAP600.
> > This negative impact could be avoided by simply adding first seen safe
> rule
> > - ie a trx can be replaced but needs to include the original outputs.
> >
> > At GAP600 we continue to see strong use of our service for BTC we have
> seen
> > circa 350k unique trx hash per month (over the last 3 months) requested
> to
> > our platform. Our clients include - Coinpayments, Coinspaid and
> Changelly.
>
> I checked, and Coinpayments and Coinspaid are both merchant processors. I
> could
> not find any example of actual merchants using their platform accepting
> unconfirmed payments. I also could not find any documentation on their
> websites
> indicating unconfirmed transaction acceptance.
>
> As for Changelly, their website says right on the front that "With an
> average
> transaction speed of 5–40 minutes, we ensure you can swiftly take
> advantage of
> market opportunities." Obivously, 5 minutes is not an unconfirmed payment.
>
> Additionally, I verified myself by doing test transactions with BIP125
> disabled
> and an adequate fee: unconfirmed payments are not accepted by Changelly. As
> their exchange flow clearly says "Once BTC is confirmed in the blockchain,
> we’ll start exchanging it to <coin>."
>
> You need to provide an genuine example of an actual merchant who accepts
> unconfirmed transactions as payment, and actually relies on first-seen
> behavior.
>
> > We have not seen any impact of full RBF on double spend rates for our
> trxs
>
> Based on the above findings, this appears to be because you don't actually
> have
> any clients who rely on unconfirmed payments.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

[-- Attachment #2: Type: text/html, Size: 5995 bytes --]

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3670 bytes --]

On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:
> Your research is not thorough and reaches an incorrect conclusion.
> 
> As stated many times - we service payment processors and some merchants
> directly  - Coinspaid services multiple merchants and process a
> significant amount of BTC they are a well known and active in the space -
> as I provided back in December 2022 a email from Max the CEO of Coinspaid
> confirming their use of 0-conf as well as providing there cluster addresses
> to validate there deposit flows see here again -
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
> - if this is not sufficient then please email support@coinspaid.com and ask
> to be connected to Max or someone from the team who can confirm Conspaid is
> clients of GAP600. Max also at the time was open to do a call, I can check
> again now and see if this is still the case and connect you.
> 
> That on its own is enough of a sample to validate our statistics.

Why don't you just give me an example of some merchants using Coinspaid, and
another example using Coinpayments, who rely on unconfirmed transactions? If
those merchants actually exist it should be very easy to give me some names of
them.

Without actual concrete examples for everyone to see for themselves, why should
we believe you?

> I have also spoken to Changelly earlier today and they offered to email pro
> @ changelly.com and they will be able to confirm GAP600 as a service

Emailed; waiting on a reply.

> provider. Also please send me the 1 trx hash you tested and I can see if it
> was queried to our system and if so offer some info as to why it wasnt
> approved. Also if you can elaborate how you integrated with Changelly - I
> can check with them if that area is not integrated with GAP600.

Why don't you just tell me exactly what service Changelly offers that relies on
unconfirmed transactions, and what characteristics would meet GAP600's risk
criteria? I and others on this mailing list could easily do test transactions
if you told us what we can actually test. If your service actually works, then
you can safely provide that information.

I'm not going to give you any exact tx hashes of transactions I've already
done, as I don't want to cause any problems for the owners of the accounts I
borrowed for testing. Given your lack of honesty so far I have every reason to
believe they might be retalliated against in some way.

> As the architect of such a major change to the status of 0-conf
> transactions I would think you would welcome the opportunity to speak to
> business and users who actual activities will be impacted by full RBF
> becoming dominant.

Funny how you say this, without actually giving any concrete examples of
businesses that will be affected. Who exactly are these businesses? Payment
processors obviously don't count.
 
> Are you able to provide the same i.e emails and contacts of people at
> the mining pools who can confirm they have adopted FULL RBF ?

I've already had multiple mining pools complain to me that they and their
employees have been harassed over full-rbf, so obviously I'm not going to
provide you with any private contact information I have. There's no need to
expose them to further harassment.

If you actually offered an unconfirmed transaction guarantee service, with real
customers getting an actual benefit, you'd be doing test transactions
frequently and would already have a very good idea of what pools do full-rbf.
Why don't you already have this data?

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

[Daniel Lipshitz]

[-- Attachment #1: Type: text/plain, Size: 4851 bytes --]

Your assessment of my dishonesty is based on your assumption of how I
should be running GAP600, your assumptions are baseless and lack commercial
experience and likewise your conclusions are false.

I have provided already back in December clear access to clarify opposite
our clients corroborated with easily verifiable trxs activity of a major
client of ours. This is more than enough to corroborate our statistics.

As far as validating real RBF adoption I have offered a clear option here
https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1661960440
something like this or similar would offer a clear assessment of adoption.
Since you are not able to provide documents or public emails of hashing
pools confirming there adoption of Full RBF.
________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz


On Wed, Aug 2, 2023 at 4:28 AM Peter Todd <pete@petertodd.org> wrote:

> On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:
> > Your research is not thorough and reaches an incorrect conclusion.
> >
> > As stated many times - we service payment processors and some merchants
> > directly  - Coinspaid services multiple merchants and process a
> > significant amount of BTC they are a well known and active in the space -
> > as I provided back in December 2022 a email from Max the CEO of Coinspaid
> > confirming their use of 0-conf as well as providing there cluster
> addresses
> > to validate there deposit flows see here again -
> >
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
> > - if this is not sufficient then please email support@coinspaid.com and
> ask
> > to be connected to Max or someone from the team who can confirm Conspaid
> is
> > clients of GAP600. Max also at the time was open to do a call, I can
> check
> > again now and see if this is still the case and connect you.
> >
> > That on its own is enough of a sample to validate our statistics.
>
> Why don't you just give me an example of some merchants using Coinspaid,
> and
> another example using Coinpayments, who rely on unconfirmed transactions?
> If
> those merchants actually exist it should be very easy to give me some
> names of
> them.
>
> Without actual concrete examples for everyone to see for themselves, why
> should
> we believe you?
>
> > I have also spoken to Changelly earlier today and they offered to email
> pro
> > @ changelly.com and they will be able to confirm GAP600 as a service
>
> Emailed; waiting on a reply.
>
> > provider. Also please send me the 1 trx hash you tested and I can see if
> it
> > was queried to our system and if so offer some info as to why it wasnt
> > approved. Also if you can elaborate how you integrated with Changelly - I
> > can check with them if that area is not integrated with GAP600.
>
> Why don't you just tell me exactly what service Changelly offers that
> relies on
> unconfirmed transactions, and what characteristics would meet GAP600's risk
> criteria? I and others on this mailing list could easily do test
> transactions
> if you told us what we can actually test. If your service actually works,
> then
> you can safely provide that information.
>
> I'm not going to give you any exact tx hashes of transactions I've already
> done, as I don't want to cause any problems for the owners of the accounts
> I
> borrowed for testing. Given your lack of honesty so far I have every
> reason to
> believe they might be retalliated against in some way.
>
> > As the architect of such a major change to the status of 0-conf
> > transactions I would think you would welcome the opportunity to speak to
> > business and users who actual activities will be impacted by full RBF
> > becoming dominant.
>
> Funny how you say this, without actually giving any concrete examples of
> businesses that will be affected. Who exactly are these businesses? Payment
> processors obviously don't count.
>
> > Are you able to provide the same i.e emails and contacts of people at
> > the mining pools who can confirm they have adopted FULL RBF ?
>
> I've already had multiple mining pools complain to me that they and their
> employees have been harassed over full-rbf, so obviously I'm not going to
> provide you with any private contact information I have. There's no need to
> expose them to further harassment.
>
> If you actually offered an unconfirmed transaction guarantee service, with
> real
> customers getting an actual benefit, you'd be doing test transactions
> frequently and would already have a very good idea of what pools do
> full-rbf.
> Why don't you already have this data?
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

[-- Attachment #2: Type: text/html, Size: 6673 bytes --]

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

[Daniel Lipshitz]

[-- Attachment #1: Type: text/plain, Size: 6428 bytes --]

For clarity purposes.

   1. Our research is based on monitoring main net transactions and network
   activity - as too is our risk engine. We do not engage in specific hashing
   pool assessments or research.
   2. It is not easily possible or comfortable to engage with our clients
   to offer up their client names and applications - the competition is fierce
   and like other industries it is not an acceptable approach to ask.
   3. The information offered by Coinpaid and posted on this list, provides
   root addresses which using tools like Chainanlysis, or
   similar service providers can confirm these addresses are associated with
   Coinspaid. This can validate a significant amount of our traffic.
   4. Based on the information provided it will be very possible to reach
   out to Max at Coinpaid - and will be able to confirm GAP600 use with
   Coinspaid. This is in addition to me posting an email from Max back in Dec
   2022 to this list confirming all of this information.
   5.  It is more than likely that Changelly has not implemented our
   service across all irts offerings, a large section of their business is
   servicing partners.

________________________________

Daniel Lipshitz
GAP600| www.gap600.com
Phone: +44 113 4900 117
Skype: daniellipshitz123
Twitter: @daniellipshitz


On Wed, Aug 2, 2023 at 1:38 PM Daniel Lipshitz <daniel@gap600.com> wrote:

> Your assessment of my dishonesty is based on your assumption of how I
> should be running GAP600, your assumptions are baseless and lack commercial
> experience and likewise your conclusions are false.
>
> I have provided already back in December clear access to clarify opposite
> our clients corroborated with easily verifiable trxs activity of a major
> client of ours. This is more than enough to corroborate our statistics.
>
> As far as validating real RBF adoption I have offered a clear option here
> https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1661960440
> something like this or similar would offer a clear assessment of adoption.
> Since you are not able to provide documents or public emails of hashing
> pools confirming there adoption of Full RBF.
> ________________________________
>
> Daniel Lipshitz
> GAP600| www.gap600.com
> Phone: +44 113 4900 117
> Skype: daniellipshitz123
> Twitter: @daniellipshitz
>
>
> On Wed, Aug 2, 2023 at 4:28 AM Peter Todd <pete@petertodd.org> wrote:
>
>> On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:
>> > Your research is not thorough and reaches an incorrect conclusion.
>> >
>> > As stated many times - we service payment processors and some merchants
>> > directly  - Coinspaid services multiple merchants and process a
>> > significant amount of BTC they are a well known and active in the space
>> -
>> > as I provided back in December 2022 a email from Max the CEO of
>> Coinspaid
>> > confirming their use of 0-conf as well as providing there cluster
>> addresses
>> > to validate there deposit flows see here again -
>> >
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
>> > - if this is not sufficient then please email support@coinspaid.com
>> and ask
>> > to be connected to Max or someone from the team who can confirm
>> Conspaid is
>> > clients of GAP600. Max also at the time was open to do a call, I can
>> check
>> > again now and see if this is still the case and connect you.
>> >
>> > That on its own is enough of a sample to validate our statistics.
>>
>> Why don't you just give me an example of some merchants using Coinspaid,
>> and
>> another example using Coinpayments, who rely on unconfirmed transactions?
>> If
>> those merchants actually exist it should be very easy to give me some
>> names of
>> them.
>>
>> Without actual concrete examples for everyone to see for themselves, why
>> should
>> we believe you?
>>
>> > I have also spoken to Changelly earlier today and they offered to email
>> pro
>> > @ changelly.com and they will be able to confirm GAP600 as a service
>>
>> Emailed; waiting on a reply.
>>
>> > provider. Also please send me the 1 trx hash you tested and I can see
>> if it
>> > was queried to our system and if so offer some info as to why it wasnt
>> > approved. Also if you can elaborate how you integrated with Changelly -
>> I
>> > can check with them if that area is not integrated with GAP600.
>>
>> Why don't you just tell me exactly what service Changelly offers that
>> relies on
>> unconfirmed transactions, and what characteristics would meet GAP600's
>> risk
>> criteria? I and others on this mailing list could easily do test
>> transactions
>> if you told us what we can actually test. If your service actually works,
>> then
>> you can safely provide that information.
>>
>> I'm not going to give you any exact tx hashes of transactions I've already
>> done, as I don't want to cause any problems for the owners of the
>> accounts I
>> borrowed for testing. Given your lack of honesty so far I have every
>> reason to
>> believe they might be retalliated against in some way.
>>
>> > As the architect of such a major change to the status of 0-conf
>> > transactions I would think you would welcome the opportunity to speak to
>> > business and users who actual activities will be impacted by full RBF
>> > becoming dominant.
>>
>> Funny how you say this, without actually giving any concrete examples of
>> businesses that will be affected. Who exactly are these businesses?
>> Payment
>> processors obviously don't count.
>>
>> > Are you able to provide the same i.e emails and contacts of people at
>> > the mining pools who can confirm they have adopted FULL RBF ?
>>
>> I've already had multiple mining pools complain to me that they and their
>> employees have been harassed over full-rbf, so obviously I'm not going to
>> provide you with any private contact information I have. There's no need
>> to
>> expose them to further harassment.
>>
>> If you actually offered an unconfirmed transaction guarantee service,
>> with real
>> customers getting an actual benefit, you'd be doing test transactions
>> frequently and would already have a very good idea of what pools do
>> full-rbf.
>> Why don't you already have this data?
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>

[-- Attachment #2: Type: text/html, Size: 9074 bytes --]

Re: [bitcoin-dev] Pull-req to enable Full-RBF by default

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 5615 bytes --]

On Wed, Aug 02, 2023 at 01:38:21PM +0300, Daniel Lipshitz wrote:
> Your assessment of my dishonesty is based on your assumption of how I
> should be running GAP600, your assumptions are baseless and lack commercial
> experience and likewise your conclusions are false.
> 
> I have provided already back in December clear access to clarify opposite
> our clients corroborated with easily verifiable trxs activity of a major
> client of ours. This is more than enough to corroborate our statistics.

Claims of "trxs activity" are completely meaningless when you can't demonstrate
that a single client of yours actually relies on unconfirmed transaction
acceptance.

> As far as validating real RBF adoption I have offered a clear option here
> https://github.com/bitcoin/bitcoin/pull/28132#issuecomment-1661960440
> something like this or similar would offer a clear assessment of adoption.
> Since you are not able to provide documents or public emails of hashing
> pools confirming there adoption of Full RBF.

Repeating your github comment here for purposes of reply:

> A clear and open method to research the adoption of full RBF would look something like this and could easily be done -
>
> Create 20 trxs (larger numbers better) in between every block and after 30 seconds try replace them.
> Run this test for at least a few hours preferably more than 24 hours or even a few days.
> See results of how many were replaced.
> Ignore trx results if trx are included in blocks before replace trxs are published.
> Have other Bitcoin Core developers independently implement and review the test results

I am baffled at the fact that you claim GAP600 offers a "real-time risk
engine"(1) guaranteeing "instant deposits & payments"(1), yet you are not
already testing full-rbf adoption yourself in this manner. If your business was
in fact real, it'd be essential to keep track of double spend success rates.

> Based on a test like this or something similar it would be reliable to get to an assessment of the adoption of full RBF.

As you should know, my OpenTimestamps calendars,
https://alice.btc.calendar.opentimestamps.org/ and
https://bob.btc.calendar.opentimestamps.org/, have been creating full-rbf
double spends multiple times a day since last year. Those calendars have
created literally thousands of full-rbf replacements, providing ample test
data.

If your business was real - if you actually have a "real time risk engine" that
monitors mempools - you'd already know this. You'd also know about the
successful full-rbf replacements that Alice got mined today:

291e1abf146209839f8910cf9ede6979bb12e6efa6d73f52ca7ae0476eafa6a5 - AntPool
e7ea70c2e366ef035ed0428c704c55e5331211200c6e0298eb85a574812aa010 - Binance Pool
aa9e034283cc50a3cb042284833607bc49dea275854004a3757acf776e679a6b - Poolin
ae74600b66ccf9d8ee8d62e5881581b5baff11117e47ea51c3e4d1fee1612504 - AntPool

Those four transactions are each part of a chain of replacements, and every
chain started with a transaction paying well above the minimum relay fee in
present mempool conditions. Tell me, how do you think those full-rbf
replacements get mined?


On Wed, Aug 02, 2023 at 06:29:54PM +0300, Daniel Lipshitz wrote:
> For clarity purposes.
> 
>    1. Our research is based on monitoring main net transactions and network
>    activity - as too is our risk engine. We do not engage in specific hashing
>    pool assessments or research.

So if you are "monitoring main net transactions and network activity", why are
you not already aware of the many full-rbf replacements getting mined every
day?

>    2. It is not easily possible or comfortable to engage with our clients
>    to offer up their client names and applications - the competition is fierce
>    and like other industries it is not an acceptable approach to ask.
>    3. The information offered by Coinpaid and posted on this list, provides
>    root addresses which using tools like Chainanlysis, or
>    similar service providers can confirm these addresses are associated with
>    Coinspaid. This can validate a significant amount of our traffic.

This reminds me of how Craig Wright appears to have picked a bunch of bitcoin
addresses off of a "rich list" and fraudulently claimed those addresses to be
his.

Anyone can create a list of addresses from blockchain data. That is not proof
that any actual merchant relies on unconfirmed transactions. To prove that you
need to provide the names of those merchant(s), so others can actually verify
that they provides things of value in exchange for an unconfirmed transaction.

>    4. Based on the information provided it will be very possible to reach
>    out to Max at Coinpaid - and will be able to confirm GAP600 use with
>    Coinspaid. This is in addition to me posting an email from Max back in Dec
>    2022 to this list confirming all of this information.

Again, Coinspaid is a merchant processor. Unless you or they actually provide
details on real merchants making use of your claimed service, you have not
proven anything of value.

>    5.  It is more than likely that Changelly has not implemented our
>    service across all irts offerings, a large section of their business is
>    servicing partners.

FYI I emailed pro@changelly.com two days ago, asking for confirmation that they
use GAP600, and information on how exactly they rely on unconfirmed
transactions. So far I have not gotten a reply.


# References

1) https://www.gap600.com/

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

[bitcoin-dev] Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 7076 bytes --]

Since Andrew Chow criticized my use of OTS(1) to measure full-RBF adoption,
I've been doing high-fee full-RBF testing to re-confirm my findings.
Specifically, that means sending a high fee tx1 with a fee more than sufficient
to get mined in the next block. Then 30 seconds later, I send tx2, a double
spend with an even higher fee, removing one of tx1's outputs. Propagation was
verified for each full-RBF double-spend by checking debug.log on another very
well-connected node.

Results: >31% of hash power, over at least 4 different pools, is mining
full-RBF at the moment, assuming Binance Pool is mining full-RBF with half
their hashing power (see below for details). This finding confirms my OTS
calendar research, which found similar results.


Specifically, in my testing yesterday I successfully did the following full-RBF
double-spends:

Antpool: 2ebe68edca320dabdd8b39ebae5f18efaac829055058a2c0f4bc2b37c69cd88c
         dac9895795efa3956cc775b4f48a5d2b01fa0ea0d7a915fa350baa4779d2e0e9
         b7d43485bf8f0f9792ba6889ab2f53fb462aa4997f3995d9d027375993fa7907
         e2cd91093399dcad5ad3fd73627e497c5e808434ecc7aaec13d9d488973f099c
         5bb7e7d6c34dfd2ae65466a2968a0e500ef25d9b70f7f2b299203dffc1a1b10d
         ad7d2f74eab240726604dfd66231f52ac7778567028cf818387dc9395474f63b
         1ddb11bad477e8b5bcdb36dbaa26065ae8e3c37b39b37a2b34780b98274bd076
         f16bb35670b66ab3c8ccbbaf5f06da5f311e9b05a02b23a77a6fec5e8e5951a4
         b6123a7c126b7937a23bf93cce09358bc2c1047a3bd20fad47bf187e453aadc5
         66f3da902d43ab0a2561d0477c7050d057bb0f69ade79015494363ad08ed172d
         17a6995a757e027b2a51b9cc58635b29553ccc6c164555c0ed922074a23bcbfe
Poolin: 68ca9ee95748dc98ba24018ea64c18de31fca552e4753ef012acd0b615cd7384
        477089a1e997a0115b3d4cd1d4ce21eb9dc83c45c14a7f7441e4fc74c3649ba2
EMCDPool: dde0975ad42fd9e03677f64b6c4f7efbe2ec0b6f905206d47893a77ac6336fca
          a0131d4f8cc13d70443cd87f2ee7543e1142640666a88f80d1e0c885c7eb2c12
Binance Pool: fb62691537d92f61dcb8ace979e0947b47dcbc7e9f50e79f77059ba0a669cdb5
              637c58f3c0447ee99808b37e4f9559096c00ceb0d21130a9254558c4d2d7ae63

Anyone running a full-RBF node with debug=mempool can easily verify all these
double-spends by examining their debug.log files.

With Antpool, Poolin, and EMCDPool, it is most likely that they're mining
full-RBF with ~100% of their hash power. These pools mined every double-spend
available to them, with the exception of some Antpool blocks found very close
to when the double-spend was broadcast. Binance Pool did *not* mine a full-RBF
replacement on two occasions, which makes me suspect they're mining full-RBF
with less than 100% of their hash power. During this testing, Binance Pool,
AntPool, Poolin, and EMCDPool, also all mined multiple double-spends from my
OTS calendars, further confirming my findings.

My OTS research also found examples of KuCoinPool and ULTIMUSPOOL mining
full-RBF double spends. They didn't find any blocks during this testing, so I
have no data on them with this testing. Luxor _did_ mine some blocks without
mining the double-spends, so at the moment it's reasonable to assume they have
full-RBF fully or partially disabled, or have some kind of full-RBF propagation
issue.  They have confirmed similar issues to me in the past (eg employees
unintentionally disabling it on some nodes during an upgrade), so it's likely
that has happened again. MARA Pool also mined some blocks without mining
double-spends, so they too may have full-RBF fully or partially disabled, as I
mentioned in my OTS research.(1)

The tool I used is the following:

    https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py

Note that this script was written years ago, pre-segwit, and I hastily updated
it for recent Bitcoin Core/python-bitcoinlib versions. I haven't checked if all
the options like OP_Return outputs and multisig still work, and it doesn't even
take segwit into account when calculating fees. Don't use it on a wallet with
funds you can't afford to lose; it definitely has bugs in it.

For reference, here is the logs from a successful double-spend attempt:

	$ sleep 15 ; ./doublespend.py --fee1 0.00018 --fee2 0.000224 `/home/user/bitcoin/src/bitcoin-cli getnewaddress` 0.00001
	DEBUG:root:Delta fee: 0.00002296
	DEBUG:root:Adding new input caec040f4435e98de9ae44a385e301312c5a3cddfb33f1bd08e1cf63307f87ce:0 with value 0.00072549 BTC
	DEBUG:root:Delta fee: 0.00003035
	DEBUG:root:Payment tx 01000000000101ce877f3063cfe108bdf133fbdd3c5a2c3101e385a344aee98de935440f04ecca0000000000ffffffff028a0f0100000000001600149e12f3ef33ba4ccde4b85978e675c9fe59bb24a2e8030000000000001600149049e0f57ec5899c1eed2c5e9aab1c34ff5cec1f02473044022063834a187727c1eceb9b3e6ae9ccd0d369b51af3493fafba1d61ed3b273d48f7022049fbe71ecd600c7345fb6002e04275eb8445031df746eceaa6e6f5f413f67497012102c56d86e3031851822485d1a2f9f0e402f14b96b64e711d5a2567412d1ea49a8b00000000
	INFO:root:Payment tx size: 0.222 KB, fees: 0.00002035, 0.00009166 BTC/KB
	INFO:root:Sent payment tx: 1c28870a78efd1c4616726ea0ca3f9d67f5591aab415222e2c9ec6184fc0b4f2
	INFO:root:Sleeping for 30 seconds
	DEBUG:root:Delta fee: 0.00004279
	DEBUG:root:Double-spend tx 01000000000101ce877f3063cfe108bdf133fbdd3c5a2c3101e385a344aee98de935440f04ecca0000000000ffffffff01ae0a0100000000001600149e12f3ef33ba4ccde4b85978e675c9fe59bb24a20247304402201289c26da70e9ec4424fc2ff7194b57384c78c9c986c2efe6771ac6f5fda199702200cefa72560f21cd9abe846078ce13197029562102f7a44b8ec50772a851c1799012102c56d86e3031851822485d1a2f9f0e402f14b96b64e711d5a2567412d1ea49a8b00000000
	INFO:root:Double-spend tx size: 0.191 KB, fees: 0.00004279, 0.00022403 BTC/KB
	INFO:root:Sent double-spend tx: fb62691537d92f61dcb8ace979e0947b47dcbc7e9f50e79f77059ba0a669cdb5

Remember that if you want to replicate this, don't be surprised if it takes
quite a few attempts if you're sending tx1 with next-block fees. A minority of
hash power is mining full-RBF. There's also a chance that in the ~30s or
whatever you wait between tx1 and tx2, a block is found and tx1 gets mined.
This chance is actually even higher than the ~5% you'd expect, because miners
don't instantly update their block templates.

So if ~30% of hash power is actively mining full-RBF, you might actually have a
~20% chance per attempt at succeeding at a naive high-fee/higher-fee
double-spend. Thus there's a (1-20%)^10 = 11% chance that 10 attempts in a row
fail. Being that unlucky happens all the time; the Gods of Probability,
probably hate you. :)


Finally, research like this is expensive in terms of my time and transaction
fees; research via the OTS calendar approach is essentially free. Donations are
appreciated as no-one is paying me to do full-RBF work or covering these
expenses.

Cheapest/easiest way is via Lightning: https://stacker.news/petertodd

Or on-chain: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv


# References

1) https://github.com/bitcoin/bitcoin/pull/28132

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [bitcoin-dev] Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now

[Peter Todd]

On August 16, 2023 12:25:58 PM GMT+02:00, Peter Todd via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
>Since Andrew Chow criticized my use of OTS(1) to measure full-RBF adoption,

Correction: Anthony Towns

I am truly terrible with names...

[bitcoin-dev] Pull-req to enable Full-RBF by default

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3543 bytes --]

FYI I have submitted a pull-req to Bitcoin Core to enable full-rbf by default:

https://github.com/bitcoin/bitcoin/pull/28132

At the moment approximately 40% of the total Bitcoin hash power is mining
full-rbf replacements, spread over 8 different pools. Multiple block explorers,
including blockstream.info(1) and mempool.space(2), have enabled full-rbf on
all their nodes. Nodes installed via BTCPay Server(3) and MyNode(4), among
others, enable full-rbf by default. Measurements also indicate that a
significant percentage of nodes have manually enabled full-rbf(5), and there
exists a well-connected set of nodes running my full-rbf peering patch(6).

As https://mempool.space/rbf#fullrbf shows, successful full-rbf replacements
are fairly common. Though the fact that only a minority of nodes relay full-rbf
replacements is still a nuisance barrier to taking advantage of them, eg in
multi-party transactions(7). A typical non-listening node with only 8 outgoing
connections is certainly *not* guaranteed to have full-rbf peers. Thus, my
pull-req to enable full-rbf by default.

Meanwhile, the last time full-rbf was discussed on this mailing list the only
opposition to full-rbf from actual entities with an actual claimed use(8) of
unconfirmed transactions was Bitrefill. I've checked multiple times, most
recently today, and I can find no evidence that Bitrefill actually accepts
unconfirmed transactions as payment any more even though their payment page
claims otherwise. Every test transactions I've done - from a variety of emails
and accounts not linked to myself - has required a confirmation.

Finally, on-chain wallets have been moving towards removing the ability to set
non-BIP125-rbf transactions entirely. For example, Electrum removed the ability
to turn off BIP125 last year(9), and Phoenix, Green, Nunchuck, and Zeus, -
among others - also provide no way to turn BIP125 off. For these wallets, the
existence of "non-replaceable" transactions is merely a support headache(10).

The fact is the dream of "on-chain coffee payments" is well and truly dead.
There is clearly no value in having the BIP125 distinction when ~40% of hashing
power ignores it. There is also clear value in *not* having that distinction:
https://petertodd.org/2023/why-you-should-run-mempoolfullrbf


We should enable full-rbf by default in Bitcoin Core github master, to be
released in the upcoming v26.0. Following that, we can depreciate and
eventually remove all BIP125 code and associated complexity in future releases
after that.


# References

1) https://github.com/Blockstream/esplora/commit/289cc6539497c3f42ab5c591c2369b75d90046e6
2) https://github.com/mempool/mempool/pull/3867
3) https://docs.btcpayserver.org/FAQ/Wallet/#does-btcpay-server-use-mempoolfullrbf-1-
4) https://github.com/mynodebtc/mynode/commit/a6cd63583cab8c62510925492bb2cfda9d2add09
5) https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf
6) https://github.com/petertodd/bitcoin/tree/full-rbf-v25.0
7) https://petertodd.org/2023/fullrbf-multiparty-protocols
8) While GAP600 claimed to act as a payment processor for unconfirmed
   transactions, they refused to actually provide examples of real services
   making use of them. Given their ties to BSV, I'm inclined to believe that
   they are lying.
9) https://github.com/spesmilo/electrum/commit/e1dc7d1e6fb2fc5b88195b62cbe1613b252db388
10) https://github.com/spesmilo/electrum/issues/8490

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]