* Re: [bitcoin-dev] Concern about "Inscriptions". (ashneverdawn) [not found] <mailman.126799.1690753843.956.bitcoin-dev@lists.linuxfoundation.org> @ 2023-07-31 4:12 ` Hugo L 2023-08-02 5:58 ` Keagan McClelland 2023-07-31 10:26 ` [bitcoin-dev] Pull-req to enable Full-RBF by default Daniel Lipshitz 1 sibling, 1 reply; 11+ messages in thread From: Hugo L @ 2023-07-31 4:12 UTC (permalink / raw) To: bitcoin-dev [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Concern about "Inscriptions". (ashneverdawn) 2023-07-31 4:12 ` [bitcoin-dev] Concern about "Inscriptions". (ashneverdawn) Hugo L @ 2023-08-02 5:58 ` Keagan McClelland 0 siblings, 0 replies; 11+ messages in thread From: Keagan McClelland @ 2023-08-02 5:58 UTC (permalink / raw) To: Hugo L, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* [bitcoin-dev] Pull-req to enable Full-RBF by default [not found] <mailman.126799.1690753843.956.bitcoin-dev@lists.linuxfoundation.org> 2023-07-31 4:12 ` [bitcoin-dev] Concern about "Inscriptions". (ashneverdawn) Hugo L @ 2023-07-31 10:26 ` Daniel Lipshitz 2023-08-01 15:04 ` Peter Todd 1 sibling, 1 reply; 11+ messages in thread From: Daniel Lipshitz @ 2023-07-31 10:26 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Pull-req to enable Full-RBF by default 2023-07-31 10:26 ` [bitcoin-dev] Pull-req to enable Full-RBF by default Daniel Lipshitz @ 2023-08-01 15:04 ` Peter Todd 2023-08-01 22:27 ` Daniel Lipshitz 0 siblings, 1 reply; 11+ messages in thread From: Peter Todd @ 2023-08-01 15:04 UTC (permalink / raw) To: Daniel Lipshitz, Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Pull-req to enable Full-RBF by default 2023-08-01 15:04 ` Peter Todd @ 2023-08-01 22:27 ` Daniel Lipshitz 2023-08-02 1:28 ` Peter Todd 0 siblings, 1 reply; 11+ messages in thread From: Daniel Lipshitz @ 2023-08-01 22:27 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Pull-req to enable Full-RBF by default 2023-08-01 22:27 ` Daniel Lipshitz @ 2023-08-02 1:28 ` Peter Todd 2023-08-02 10:38 ` Daniel Lipshitz 0 siblings, 1 reply; 11+ messages in thread From: Peter Todd @ 2023-08-02 1:28 UTC (permalink / raw) To: Daniel Lipshitz; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Pull-req to enable Full-RBF by default 2023-08-02 1:28 ` Peter Todd @ 2023-08-02 10:38 ` Daniel Lipshitz 2023-08-02 15:29 ` Daniel Lipshitz 2023-08-03 12:46 ` Peter Todd 0 siblings, 2 replies; 11+ messages in thread From: Daniel Lipshitz @ 2023-08-02 10:38 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Pull-req to enable Full-RBF by default 2023-08-02 10:38 ` Daniel Lipshitz @ 2023-08-02 15:29 ` Daniel Lipshitz 2023-08-03 12:46 ` Peter Todd 1 sibling, 0 replies; 11+ messages in thread From: Daniel Lipshitz @ 2023-08-02 15:29 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Pull-req to enable Full-RBF by default 2023-08-02 10:38 ` Daniel Lipshitz 2023-08-02 15:29 ` Daniel Lipshitz @ 2023-08-03 12:46 ` Peter Todd 2023-08-16 10:25 ` [bitcoin-dev] Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now Peter Todd 1 sibling, 1 reply; 11+ messages in thread From: Peter Todd @ 2023-08-03 12:46 UTC (permalink / raw) To: Daniel Lipshitz; +Cc: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* [bitcoin-dev] Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now 2023-08-03 12:46 ` Peter Todd @ 2023-08-16 10:25 ` Peter Todd 2023-08-16 14:02 ` Peter Todd 0 siblings, 1 reply; 11+ messages in thread From: Peter Todd @ 2023-08-16 10:25 UTC (permalink / raw) To: Bitcoin Protocol Discussion [-- 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 --] ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [bitcoin-dev] Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now 2023-08-16 10:25 ` [bitcoin-dev] Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now Peter Todd @ 2023-08-16 14:02 ` Peter Todd 0 siblings, 0 replies; 11+ messages in thread From: Peter Todd @ 2023-08-16 14:02 UTC (permalink / raw) To: Bitcoin Protocol Discussion 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... ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2023-08-16 14:02 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <mailman.126799.1690753843.956.bitcoin-dev@lists.linuxfoundation.org>
2023-07-31 4:12 ` [bitcoin-dev] Concern about "Inscriptions". (ashneverdawn) Hugo L
2023-08-02 5:58 ` Keagan McClelland
2023-07-31 10:26 ` [bitcoin-dev] Pull-req to enable Full-RBF by default Daniel Lipshitz
2023-08-01 15:04 ` Peter Todd
2023-08-01 22:27 ` Daniel Lipshitz
2023-08-02 1:28 ` Peter Todd
2023-08-02 10:38 ` Daniel Lipshitz
2023-08-02 15:29 ` Daniel Lipshitz
2023-08-03 12:46 ` Peter Todd
2023-08-16 10:25 ` [bitcoin-dev] Full-RBF testing: at least 31% of hash power, over at least 4 pools, is mining full-RBF right now Peter Todd
2023-08-16 14:02 ` Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox