Ross Nicoll [ARCHIVE] on Nostr: 📅 Original date posted:2015-01-04 📝 Original message:On 04/01/15 17:35, Gregory ...
📅 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>;
📝 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>;