El_Hoy [ARCHIVE] on Nostr: 📅 Original date posted:2022-12-05 📝 Original message:You are doing quite big ...
📅 Original date posted:2022-12-05
📝 Original message:You are doing quite big claims without explaining those, let me add a few
questions inline:
On Mon, Dec 5, 2022 at 10:39 AM Greg Sanders <gsanders87 at gmail.com> wrote:
This will greatly centralize the network as well as not actually achieve
> the intended goal which is literally impossible.
>
Why would this centralize the network? Adding more nodes that propagate
valid blocks on the network should be good. Also, I cannot see why you say
it is "literally impossible", could you give any explanation for your words?
On Mon, Dec 5, 2022 at 11:53 AM Rijndael via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning,
>
> That sounds like a very dangerous mode of operation. You can already hand
> a transaction to a miner privately. I hand a transaction to a miner with
> some reasonable fee, and then I go and broadcast a different transaction
> with a minimal fee that spends the same inputs. The whole network
> (including the miner I handed the tx to) could all be running with a strict
> first-seen mempool policy, but we can still have a situation where the
> miner creates a block with a different transaction from what you see in
> your mempool. If anytime this happens, the nodes running your proposed rule
> drop the block, then anyone can fork those nodes off the network whenever
> they want.
>
I cannot see the danger you are talking about, sending a transaction
directly to a miner does not sound like anyone can do (except a miner) and
is not the main workflow, usually transactions propagate on the network and
it is quite difficult to have different miners with different opt-out-rbb
transactions that spends the same input. In that strange scenario that you
mention, the miner generated block might be lost if another miner creates
an alternative block.
> Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt
> to) promise consistency across mempools. Making a consensus rule that
> enforces mempool consistency is a recipe for (unintended?) chainsplits.
>
That is not entirely true for opt-out rbf transactions, as most 0conf
setups are based on such consistency. And breaking a consensus rule always
leads to a chainsplit. For example when a miner creates a block that
double-spends an input, the normal bitcoin flow is a chain-split. That is
not an unintended chainsplit, is a consensus rule enforcement.
> - rijndael
>
>
> On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote:
>
> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the network will add a risk to miners that enable full-rbf that
> would work as an incentive against that.
>
> Obviously that would require adding an option on bitcoin core (that is not
> technically but politically difficult to implement as Petter Todd already
> have commit access to the main repository).
>
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality. As far as I understand the percolation model, with 10 to 20
> nodes running such a rule would create a significant risk for full-rbf
> miners.
>
> Regards.
>
> --- Eloy
>
>
> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev
>> wrote:
>> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev
>> wrote:
>> > > FYI I've gotten a few hundred dollars worth of donations to this
>> effort, and
>> > > have raised the reward to about 0.02 BTC, or $400 USD at current
>> prices.
>> >
>> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>>
>> I'm turning it back on when (if) the mempool settles down. I've got more
>> than
>> enough donations to give another run at it (the majority was donated
>> privately
>> FWIW). There's a risk of the mempool filling up again of course; hard to
>> avoid
>> that.
>>
>> Right now of course it's really easy to double spend with the obvious
>> low-fee/high-fee method as the min relay fee keeps shifting.
>>
>> >
>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c
>> >
>> > The block it was claimed in seems to have been about an hour after the
>> > default mempool filled up:
>> >
>> > https://twitter.com/murchandamus/status/1592274621977477120
>> >
>> > That block actually seems to have included two
>> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
>> > (309sat/vb):
>> >
>> >
>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>>
>> The second is because I turned down the full-rbf reward to more normal fee
>> levels. There's also another full-rbf double-spend from the Bob calendar,
>> along
>> the same lines:
>> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2
>>
>> I double-spent the txin of the high fee tx that got mined. But I
>> mistakenly had
>> RBF enabled in that double-spend, so while it propagated initially, I
>> believe
>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb
>> tx.
>>
>> > Timeline (utc) to me looks like:
>> >
>> > - 13:12 - block 763148 is mined: last one that had a min fee <
>> 1.5sat/vb
>> > - 13:33 -
>> f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1
>> > is announced and propogates widely (1.2sat/vb)
>> > - 18:42 -
>> 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944
>> > is announced and propogates widely (1.2sat/vb)
>> > - 21:52 - ba967010 tx is announced and propogates widely, since
>> > conflicting tx 746daab9 has been removed from default
>> > mempools
>> > - 21:53 - murch tweets about default mempool filling up
>> > - 22:03 - 397dcbe4 tx is announced and propogates widely, since
>> > conflicting tx f503868 has already been removed from default
>> > mempools
>>
>> Is that 22:03 time for 397 from your node's logs? It was originally
>> announced
>> hours earlier. From one of my full-rbf nodes:
>>
>> 2022-11-14T14:08:37Z [mempool] replacing tx
>> 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with
>> 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for
>> 0.00468 additional fees, -1 delta bytes
>>
>> > - 22:35 - block 763189 is mined
>> > - 22:39 - block 763190 is mined
>> > - 23:11 - block 763191 is mined
>> > - 23:17 - block 763192 is mined including 397dcbe4
>> >
>> > miningpool.observer reports both 397dcbe4 and ba967010 as missing in the
>> > first three blocks, and gives similar mempool ages for those txs to what
>> > my logs report:
>> >
>> >
>> https://miningpool.observer/template-and-block/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>> >
>> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>> >
>> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
>> >
>> > That presumably means those pools (AntPool twice and "unknown") are
>> > running with large mempools that didn't kept the earlier 1.2sat/vb txs.
>>
>> To be clear, you think that AntPool and that other exchange is running
>> with a
>> larger than normal max mempool size limit? You mean those miners *did*
>> keep the
>> earlier 1.2sat/vb tx?
>>
>> > The txs were mined by Foundry:
>> >
>> >
>> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
>> >
>> > This seems to be pretty good evidence that we currently don't have any
>> > significant hashrate mining with fullrbf policies (<0.5% if there was a
>> > high fee replacement available prior to every block having been mined),
>> > despite the bounty having been collected.
>>
>> Oh, we can put much lower bounds on that. I've been running OTS calendars
>> with
>> full-rbf replacements for a few months without clear evidence of a
>> full-rbf
>> replacement. While there was good reason to think some miners were mining
>> full-rbf before a few years back, they probably didn't bother to reapply
>> their
>> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/3fd33525/attachment-0001.html>;
📝 Original message:You are doing quite big claims without explaining those, let me add a few
questions inline:
On Mon, Dec 5, 2022 at 10:39 AM Greg Sanders <gsanders87 at gmail.com> wrote:
This will greatly centralize the network as well as not actually achieve
> the intended goal which is literally impossible.
>
Why would this centralize the network? Adding more nodes that propagate
valid blocks on the network should be good. Also, I cannot see why you say
it is "literally impossible", could you give any explanation for your words?
On Mon, Dec 5, 2022 at 11:53 AM Rijndael via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Good morning,
>
> That sounds like a very dangerous mode of operation. You can already hand
> a transaction to a miner privately. I hand a transaction to a miner with
> some reasonable fee, and then I go and broadcast a different transaction
> with a minimal fee that spends the same inputs. The whole network
> (including the miner I handed the tx to) could all be running with a strict
> first-seen mempool policy, but we can still have a situation where the
> miner creates a block with a different transaction from what you see in
> your mempool. If anytime this happens, the nodes running your proposed rule
> drop the block, then anyone can fork those nodes off the network whenever
> they want.
>
I cannot see the danger you are talking about, sending a transaction
directly to a miner does not sound like anyone can do (except a miner) and
is not the main workflow, usually transactions propagate on the network and
it is quite difficult to have different miners with different opt-out-rbb
transactions that spends the same input. In that strange scenario that you
mention, the miner generated block might be lost if another miner creates
an alternative block.
> Even outside of adversarial settings, Bitcoin doesn't (and doesn't attempt
> to) promise consistency across mempools. Making a consensus rule that
> enforces mempool consistency is a recipe for (unintended?) chainsplits.
>
That is not entirely true for opt-out rbf transactions, as most 0conf
setups are based on such consistency. And breaking a consensus rule always
leads to a chainsplit. For example when a miner creates a block that
double-spends an input, the normal bitcoin flow is a chain-split. That is
not an unintended chainsplit, is a consensus rule enforcement.
> - rijndael
>
>
> On 12/5/22 7:20 AM, El_Hoy via bitcoin-dev wrote:
>
> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the network will add a risk to miners that enable full-rbf that
> would work as an incentive against that.
>
> Obviously that would require adding an option on bitcoin core (that is not
> technically but politically difficult to implement as Petter Todd already
> have commit access to the main repository).
>
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality. As far as I understand the percolation model, with 10 to 20
> nodes running such a rule would create a significant risk for full-rbf
> miners.
>
> Regards.
>
> --- Eloy
>
>
> On Tue, Nov 15, 2022 at 11:43 AM Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Tue, Nov 15, 2022 at 03:36:08PM +1000, Anthony Towns via bitcoin-dev
>> wrote:
>> > On Tue, Nov 08, 2022 at 01:16:13PM -0500, Peter Todd via bitcoin-dev
>> wrote:
>> > > FYI I've gotten a few hundred dollars worth of donations to this
>> effort, and
>> > > have raised the reward to about 0.02 BTC, or $400 USD at current
>> prices.
>> >
>> > Seems like this has been mostly claimed (0.014btc / $235, 9238sat/vb):
>>
>> I'm turning it back on when (if) the mempool settles down. I've got more
>> than
>> enough donations to give another run at it (the majority was donated
>> privately
>> FWIW). There's a risk of the mempool filling up again of course; hard to
>> avoid
>> that.
>>
>> Right now of course it's really easy to double spend with the obvious
>> low-fee/high-fee method as the min relay fee keeps shifting.
>>
>> >
>> https://mempool.space/tx/397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c
>> >
>> > The block it was claimed in seems to have been about an hour after the
>> > default mempool filled up:
>> >
>> > https://twitter.com/murchandamus/status/1592274621977477120
>> >
>> > That block actually seems to have included two
>> > alice.btc.calendar.opentimestamps.org txs, the other paying $7.88
>> > (309sat/vb):
>> >
>> >
>> https://mempool.space/tx/ba9670109a6551458d5e1e23600c7bf2dc094894abdf59fe7aa020ccfead07cf
>>
>> The second is because I turned down the full-rbf reward to more normal fee
>> levels. There's also another full-rbf double-spend from the Bob calendar,
>> along
>> the same lines:
>> 7e76b351009326a574f3120164dbbe6d85e07e04a7bbdc40f0277fcb008d2cd2
>>
>> I double-spent the txin of the high fee tx that got mined. But I
>> mistakenly had
>> RBF enabled in that double-spend, so while it propagated initially, I
>> believe
>> it was replaced when something (someone?) rebroadcast the high-fee 397dcb
>> tx.
>>
>> > Timeline (utc) to me looks like:
>> >
>> > - 13:12 - block 763148 is mined: last one that had a min fee <
>> 1.5sat/vb
>> > - 13:33 -
>> f503868c64d454c472859b793f3ee7cdc8f519c64f8b1748d8040cd8ce6dc6e1
>> > is announced and propogates widely (1.2sat/vb)
>> > - 18:42 -
>> 746daab9bcc331be313818658b4a502bb4f3370a691fd90015fabcd7759e0944
>> > is announced and propogates widely (1.2sat/vb)
>> > - 21:52 - ba967010 tx is announced and propogates widely, since
>> > conflicting tx 746daab9 has been removed from default
>> > mempools
>> > - 21:53 - murch tweets about default mempool filling up
>> > - 22:03 - 397dcbe4 tx is announced and propogates widely, since
>> > conflicting tx f503868 has already been removed from default
>> > mempools
>>
>> Is that 22:03 time for 397 from your node's logs? It was originally
>> announced
>> hours earlier. From one of my full-rbf nodes:
>>
>> 2022-11-14T14:08:37Z [mempool] replacing tx
>> 764867062b67fea61810c3858d587da83a28290545e882935a32285028084317 with
>> 397dcbe4e95ec40616e3dfc4ff8ffa158d2e72020b7d11fc2be29d934d69138c for
>> 0.00468 additional fees, -1 delta bytes
>>
>> > - 22:35 - block 763189 is mined
>> > - 22:39 - block 763190 is mined
>> > - 23:11 - block 763191 is mined
>> > - 23:17 - block 763192 is mined including 397dcbe4
>> >
>> > miningpool.observer reports both 397dcbe4 and ba967010 as missing in the
>> > first three blocks, and gives similar mempool ages for those txs to what
>> > my logs report:
>> >
>> >
>> https://miningpool.observer/template-and-block/0000000000000000000436aba59d8430061e0e50592215f7f263bfb1073ccac7
>> >
>> https://miningpool.observer/template-and-block/00000000000000000005600404792bacfd8a164d2fe9843766afb2bfbd937309
>> >
>> https://miningpool.observer/template-and-block/00000000000000000004a3073f58c9eae40f251ea7aeaeac870daeac4b238fd1
>> >
>> > That presumably means those pools (AntPool twice and "unknown") are
>> > running with large mempools that didn't kept the earlier 1.2sat/vb txs.
>>
>> To be clear, you think that AntPool and that other exchange is running
>> with a
>> larger than normal max mempool size limit? You mean those miners *did*
>> keep the
>> earlier 1.2sat/vb tx?
>>
>> > The txs were mined by Foundry:
>> >
>> >
>> https://miningpool.observer/template-and-block/00000000000000000001382a226aedac822de80309cca2bf1253b35d4f8144f5
>> >
>> > This seems to be pretty good evidence that we currently don't have any
>> > significant hashrate mining with fullrbf policies (<0.5% if there was a
>> > high fee replacement available prior to every block having been mined),
>> > despite the bounty having been collected.
>>
>> Oh, we can put much lower bounds on that. I've been running OTS calendars
>> with
>> full-rbf replacements for a few months without clear evidence of a
>> full-rbf
>> replacement. While there was good reason to think some miners were mining
>> full-rbf before a few years back, they probably didn't bother to reapply
>> their
>> patches each upgrade. `mempoolfullrbf=1` is much simpler to use.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221205/3fd33525/attachment-0001.html>;