📅 Original date posted:2018-04-11 📝 Original message:Thanks for clarifying! On ...

Karl-Johan Alm [ARCHIVE] /

npub17cw…mtzy

2023-06-07 18:11:37

in reply to nevent1q…qc8r

📅 Original date posted:2018-04-11
📝 Original message:Thanks for clarifying!

On Wed, Apr 11, 2018 at 6:48 PM, ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Karl-Johan Alm,
>
> To clarify:
>
> Nothing prevents a miner from completely ignoring nSequence when putting transactions in blocks.
>
> Unconfirmed transactions are, by definition, not recorded in blocks. So if there is a transaction 0xFFFFFFF nSequence and fee 1000 satoshi, and another conflicting transaction 0xFFFFFFF nSequence and fee 100000000 satoshi, miners can include the latter one even if the first one came to their knowledge first, regardless nSequence.
>
> Thus, in the end "full replace-by-fee", where nSequence is IGNORED for purposes of replace-by-fee, is expected to become the norm, and we should really be designing our wallets and so on so that we only trust transactions that have confirmations.
>
> The "nSequence=0xFFFFFFFF means opt-OUT of RBF" convention is only followed by fullnodes running standard bitcoind. Nothing prevents miners from running patched bitcoind that ignores this rule, and connecting with similar peers who also ignore this rule.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>
> On April 11, 2018 5:37 PM, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Wed, Apr 11, 2018 at 05:10:43PM +0900, Karl-Johan Alm wrote:
>>
>> > On Wed, Apr 11, 2018 at 4:52 PM, Peter Todd pete at petertodd.org wrote:
>> >
>> > > Or via full replace-by-fee, which appears to be used by a significant minority
>> > >
>> > > of miners:
>> >
>> > I was of the impression that final transactions (sequence=0xffffffff)
>> >
>> > cannot be RBF'd.
>>
>> My full-replace-by-fee tree ignores that. It also does preferential peering to
>>
>> ensure it's well connected with likewise peers, and thus the whole network.
>>
>>
>> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>>
>> 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
>
>

Author Public Key

npub17cwk7hm623dm5npjzu8cvv994h43k2keanegs8w78xyvlez8hqqsqqmtzy

Show more details

Published at

2023-06-07 18:11:37

Kind type

1 Short Text Note

Event JSON

{ "id": "f7c312ebb65fc90dbc8f55efd390ee3f1e5b5324e60c51ef756c4883f3e5046c", "pubkey": "f61d6f5f7a545bba4c32170f8630a5adeb1b2ad9ecf2881dde3988cfe447b801", "created_at": 1686161497, "kind": 1, "tags": [ [ "e", "982a0c82bfb8d6491e92dfa42dfd12e7a2df5bc1554108026ba2680500a8b0bc", "", "root" ], [ "e", "b960656cd95f918cf2033294cf7fe452e0c5942f74142ae374dc67c97fc767aa", "", "reply" ], [ "p", "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861" ] ], "content": "📅 Original date posted:2018-04-11\n📝 Original message:Thanks for clarifying!\n\nOn Wed, Apr 11, 2018 at 6:48 PM, ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\u003e Good morning Karl-Johan Alm,\n\u003e\n\u003e To clarify:\n\u003e\n\u003e Nothing prevents a miner from completely ignoring nSequence when putting transactions in blocks.\n\u003e\n\u003e Unconfirmed transactions are, by definition, not recorded in blocks. So if there is a transaction 0xFFFFFFF nSequence and fee 1000 satoshi, and another conflicting transaction 0xFFFFFFF nSequence and fee 100000000 satoshi, miners can include the latter one even if the first one came to their knowledge first, regardless nSequence.\n\u003e\n\u003e Thus, in the end \"full replace-by-fee\", where nSequence is IGNORED for purposes of replace-by-fee, is expected to become the norm, and we should really be designing our wallets and so on so that we only trust transactions that have confirmations.\n\u003e\n\u003e The \"nSequence=0xFFFFFFFF means opt-OUT of RBF\" convention is only followed by fullnodes running standard bitcoind. Nothing prevents miners from running patched bitcoind that ignores this rule, and connecting with similar peers who also ignore this rule.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n\u003e\n\u003e Sent with ProtonMail Secure Email.\n\u003e\n\u003e ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\n\u003e\n\u003e On April 11, 2018 5:37 PM, Peter Todd via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e On Wed, Apr 11, 2018 at 05:10:43PM +0900, Karl-Johan Alm wrote:\n\u003e\u003e\n\u003e\u003e \u003e On Wed, Apr 11, 2018 at 4:52 PM, Peter Todd pete at petertodd.org wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e \u003e Or via full replace-by-fee, which appears to be used by a significant minority\n\u003e\u003e \u003e \u003e\n\u003e\u003e \u003e \u003e of miners:\n\u003e\u003e \u003e\n\u003e\u003e \u003e I was of the impression that final transactions (sequence=0xffffffff)\n\u003e\u003e \u003e\n\u003e\u003e \u003e cannot be RBF'd.\n\u003e\u003e\n\u003e\u003e My full-replace-by-fee tree ignores that. It also does preferential peering to\n\u003e\u003e\n\u003e\u003e ensure it's well connected with likewise peers, and thus the whole network.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ---------------------------------------------------------------------------------------------------------------------------------------------------------------\n\u003e\u003e\n\u003e\u003e https://petertodd.org 'peter'[:-1]@petertodd.org\n\u003e\u003e\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e", "sig": "ae58a932571190796c715c52ffa324da6b894b3a424487c07c2ee15bd1b9a8ab8e747e7d20f10709337ee81ff0ec69700ee362573ea1c22dc82578a319b4e5bf" }