Message-ID: <54A97C1D.1080604@jrn.me.uk>
Date: Sun, 04 Jan 2015 17:45:01 +0000
From: Ross Nicoll <jrn@jrn.me.uk>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
	rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Gregory Maxwell <gmaxwell@gmail.com>
References: <54A95179.2070200@jrn.me.uk>	<CAAS2fgSw=Goibe2LkXsEH5xjyftjQq4FxJh-dhaP_N5ea21ugQ@mail.gmail.com>	<54A976C3.1030805@jrn.me.uk>
	<CAAS2fgTxwD2GJ-n+d=ovEYWCxpwyPO_DMBguP_ioc+_cdEhW=w@mail.gmail.com>
In-Reply-To: <CAAS2fgTxwD2GJ-n+d=ovEYWCxpwyPO_DMBguP_ioc+_cdEhW=w@mail.gmail.com>
Content-Type: multipart/mixed; boundary="------------030605010203080806030807"
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Re-enabling simple tx replacement
Precedence: list

This is a multi-part message in MIME format.
--------------030605010203080806030807
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

On 04/01/15 17:35, Gregory Maxwell wrote:
> On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll <jrn@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.


--------------030605010203080806030807
Content-Type: text/x-hex;
	name="f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6ac1f8.hex"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
	filename*0="f903a31f2474df737d324c60abf2407e1cf7e052844da4ccffbfab81cf6a";
	filename*1="c1f8.hex"

MDEwMDAwMDAwMTlmYmYxZTFjNjU0MzI3ODc5NWEyNGE1MTM4Y2Q5ZWVhMTdhMjRmZjQwZjI0
NmRlY2U2MzEyZjBjNWZjZDY4MjYwMDAwMDAwMGRhMDA0OTMwNDYwMjIxMDBlZTdkMzk1MzU1
ZDJiNTUwNDI4OWU0ZGU4OGNkMTY5NGQ0ZmJmYjY4YzYwODNkMmIxZDk3NjY4ZjhhZWNhZDgx
MDIyMTAwY2JiMmRlZjEyNGVhYWMzOTRkOTdhMzYxOWIxY2Y3MjMxMDE4NzgxMDVlZWZjMTc5
MjAxYWRlNTY1MWUwZWQxZTAxNDgzMDQ1MDIyMTAwYWU2MmQ4MGMzYzM4YTUyZDI3ZWE2NDlm
Mjc0YzE3YzBlZDQzODM1MDU3N2I3ZTIyZDRkODNhNzgwZjBjMjlhMzAyMjAwZTljMzcxYzUy
ZDk4MTlkNmMzN2I5MDQ2NmZjZjNiN2IwNzRkOTJlMDc1YmQwNDNkNWExNmEzOTJmZGFlZDMx
MDE1MjIxMDNhYmQ2MDM0MzQzNzE3OWQxMmFiYzQwZGE0N2MyNmFkMjYxZTJkMjJmNWM4OWQ4
YWYyNTRkNGU1ZGRkYWUxMWEzMjEwMjBjMDc2ZjRjMTIxNTgzYjJmNGVmOTNlODE4NmQ2MWNk
MzVjZWNjMThkMTVjNWFhOTkzYTg3NTlkNjc4YzFlYjA1MjAxMDAwMDAwMDE1ODNlMGYwMDAw
MDAwMDAwMTk3NmE5MTQwOThmZjVkYzU4YzJjOGFmNmEzNDNhNmJlOWJlNGExNWQwNDA4ZTUy
ODhhY2E5ZGFhOTU0
--------------030605010203080806030807--