📅 Original date posted:2015-01-04
📝 Original message:On 04/01/15 17:35, Gregory Maxwell wrote:
> On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll <jrn at jrn.me.uk> wrote:
>> Grabbing a simple test case:
>> https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8
>> - that won't lock until 0028 UTC on the 5th.
>>
>> I've tried closing the wallet, moving the wallet.dat file out of the
>> way, and then attempting the spend transaction (which can be locked
>> immediately), and it either rejects it on acceptance to mempool, or it
>> is never included in a block.
>
> Can you send me the actual raw transaction (that site doesn't appear
> have a way to get it, only some cooked json output; which doesn't
> include the sequence number).
>
> As I said, it's a severe bug if unlocked transactions are being
> relayed or mempooled far in advance.
Attached. Sequence number for the input is set to 1, please do tell me
if I've misunderstood how it's used.
>> They can only replace a non-final transaction with a final transaction,
>
> Ah I missed that the replacement had to be final. Thats indeed a much
> more sane thing to do than I was thinking (sorry for some reason I saw
> the +1 and thought it was just checking the sequence number was
> higher.)
>
>> I don't think that's a major issue?
>
> If they can relay the first one to begin with its an an issue, the
> replacement just makes it twice an issue. :)
>
I'll set up a few nodes tomorrow and double check it's in fact relaying
in the latest version. If it's simply an issue of incorrect relaying,
that's significantly simpler at least, and the problem can be tackled
through that instead.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8.hex
Type: text/x-hex
Size: 606 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150104/4c954510/attachment.bin>;
Ross Nicoll [ARCHIVE] /
npub10p…pfaef
2023-06-07 17:28:22
in reply to nevent1q…3k9k
Author Public Key
npub10plv6jx6pktpp5ezldnus6kj8ffg045g2kdjl78w23njrlveqy5s3pfaefPublished at
2023-06-07 17:28:22Event JSON
{
"id": "a9de1e34288712cbc96de581ac3c6ef3b8aa56276b97ef49b59181e930490b2b",
"pubkey": "787ecd48da0d9610d322fb67c86ad23a5287d688559b2ff8ee546721fd990129",
"created_at": 1686151702,
"kind": 1,
"tags": [
[
"e",
"c34c675aa013cba152c99a343668732650d019acd0488a1f1a5be9bc5fc8e1f8",
"",
"root"
],
[
"e",
"0846a7a6c7cacd8803c240b1a736dbcdb4d675363c51856bc509280ec9db243b",
"",
"reply"
],
[
"p",
"498a711971f8a0194289aee037a4c481a99e731b5151724064973cc0e0b27c84"
]
],
"content": "📅 Original date posted:2015-01-04\n📝 Original message:On 04/01/15 17:35, Gregory Maxwell wrote:\n\u003e On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll \u003cjrn at jrn.me.uk\u003e wrote:\n\u003e\u003e Grabbing a simple test case:\n\u003e\u003e https://chain.so/tx/BTCTEST/f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8\n\u003e\u003e - that won't lock until 0028 UTC on the 5th.\n\u003e\u003e\n\u003e\u003e I've tried closing the wallet, moving the wallet.dat file out of the\n\u003e\u003e way, and then attempting the spend transaction (which can be locked\n\u003e\u003e immediately), and it either rejects it on acceptance to mempool, or it\n\u003e\u003e is never included in a block.\n\u003e \n\u003e Can you send me the actual raw transaction (that site doesn't appear\n\u003e have a way to get it, only some cooked json output; which doesn't\n\u003e include the sequence number).\n\u003e \n\u003e As I said, it's a severe bug if unlocked transactions are being\n\u003e relayed or mempooled far in advance.\n\nAttached. Sequence number for the input is set to 1, please do tell me\nif I've misunderstood how it's used.\n\n\u003e\u003e They can only replace a non-final transaction with a final transaction,\n\u003e \n\u003e Ah I missed that the replacement had to be final. Thats indeed a much\n\u003e more sane thing to do than I was thinking (sorry for some reason I saw\n\u003e the +1 and thought it was just checking the sequence number was\n\u003e higher.)\n\u003e \n\u003e\u003e I don't think that's a major issue?\n\u003e \n\u003e If they can relay the first one to begin with its an an issue, the\n\u003e replacement just makes it twice an issue. :)\n\u003e \n\nI'll set up a few nodes tomorrow and double check it's in fact relaying\nin the latest version. If it's simply an issue of incorrect relaying,\nthat's significantly simpler at least, and the problem can be tackled\nthrough that instead.\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8.hex\nType: text/x-hex\nSize: 606 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150104/4c954510/attachment.bin\u003e",
"sig": "7ece485526065791dc283397ad363801beb59a7f3899b22aa7c94ecaa0739301c0099ba05c00ada2355e49062ca6f584ecf63eb99c4fbc89c2eb56427d29e156"
}