[Bitcoin-development] Re-enabling simple tx replacement

2015-01-04 Thread Ross Nicoll
Dear all,

I've been looking at atomic cross-chain trading (
https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the
Bitcoin and Dogecoin blockchains, and have a mostly functional
prototype. However as it stands if the refund transaction is relayed
before the actual spend transaction, it blocks the legitimate spend
transaction from being accepted into the memory pool.

I'd like to enable TX replacement in the case where all conflicting
transactions are not final, and the replacement is final. While yes,
this still leaves scope for unpaid for bandwidth, hopefully being able
to do a single replacement isn't a major issue.

For those wanting background on this,
https://github.com/bitcoin/bitcoin/pull/2516 may be useful reading.

I've drafted a patch for this
https://github.com/rnicoll/bitcoin/commit/e668d36607f008990ccaac7275e463a6efdd9b5a
but have not yet raised a PR, as historically this has lead to a lot of
discussion in Github which is better suited to this mailing list.

I'm therefore looking for feedback while I continue testing that patch,
and any comments would be welcomed.

Ross

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Re-enabling simple tx replacement

2015-01-04 Thread Gregory Maxwell
On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll j...@jrn.me.uk wrote:
 Dear all,

 I've been looking at atomic cross-chain trading (
 https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the
 Bitcoin and Dogecoin blockchains, and have a mostly functional
 prototype. However as it stands if the refund transaction is relayed
 before the actual spend transaction, it blocks the legitimate spend
 transaction from being accepted into the memory pool.

Unless there is a serious bug that I am not aware of this is not the
case. The unlocked transaction is not relayable and will not be
mempooled (well, until right before it locks).

 I've drafted a patch for this
 https://github.com/rnicoll/bitcoin/commit/e668d36607f008990ccaac7275e463a6efdd9b5a
 but have not yet raised a PR, as historically this has lead to a lot of
 discussion in Github which is better suited to this mailing list.

 I'm therefore looking for feedback while I continue testing that patch,
 and any comments would be welcomed.

This appears to have absolutely no protection against denial of
service, it seems to me that a single user can rapidly update their
transaction and exhaust the relay bandwidth of the entire network.

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Re-enabling simple tx replacement

2015-01-04 Thread Ross Nicoll
On 04/01/15 17:04, Gregory Maxwell wrote:
 On Sun, Jan 4, 2015 at 2:43 PM, Ross Nicoll j...@jrn.me.uk wrote:
 Dear all,

 I've been looking at atomic cross-chain trading (
 https://en.bitcoin.it/wiki/Atomic_cross-chain_trading ) between the
 Bitcoin and Dogecoin blockchains, and have a mostly functional
 prototype. However as it stands if the refund transaction is relayed
 before the actual spend transaction, it blocks the legitimate spend
 transaction from being accepted into the memory pool.
 
 Unless there is a serious bug that I am not aware of this is not the
 case. The unlocked transaction is not relayable and will not be
 mempooled (well, until right before it locks).

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.

Compare with
https://chain.so/tx/BTCTEST/0b96eb0c9bf8a6ca08bb9d75e44970889db9c6d3122296c0169959f979cc
where the refund was not sent first, and the transaction has succeeded.

 I've drafted a patch for this
 https://github.com/rnicoll/bitcoin/commit/e668d36607f008990ccaac7275e463a6efdd9b5a
 but have not yet raised a PR, as historically this has lead to a lot of
 discussion in Github which is better suited to this mailing list.

 I'm therefore looking for feedback while I continue testing that patch,
 and any comments would be welcomed.
 
 This appears to have absolutely no protection against denial of
 service, it seems to me that a single user can rapidly update their
 transaction and exhaust the relay bandwidth of the entire network.
 

They can only replace a non-final transaction with a final transaction,
so the replacement can happen at most once (any later replacement would
be attempting to replace a final transaction, and therefore fails). So,
while they can expend twice the bandwidth compared to a non-replacement,
I don't think that's a major issue?


--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Re-enabling simple tx replacement

2015-01-04 Thread Gregory Maxwell
On Sun, Jan 4, 2015 at 5:22 PM, Ross Nicoll j...@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.

 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. :)

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Re-enabling simple tx replacement

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

0100019fbf1e1c6543278795a24a5138cd9eea17a24ff40f246dece6312f0c5fcd6826da00493046022100ee7d395355d2b5504289e4de88cd1694d4fbfb68c6083d2b1d97668f8aecad81022100cbb2def124eaac394d97a3619b1cf723101878105eefc179201ade5651e0ed1e01483045022100ae62d80c3c38a52d27ea649f274c17c0ed438350577b7e22d4d83a780f0c29a302200e9c371c52d9819d6c37b90466fcf3b7b074d92e075bd043d5a16a392fdaed3101522103abd60343437179d12abc40da47c26ad261e2d22f5c89d8af254d4e5dddae11a321020c076f4c121583b2f4ef93e8186d61cd35cecc18d15c5aa993a8759d678c1eb052010001583e0f001976a914098ff5dc58c2c8af6a343a6be9be4a15d0408e5288aca9daa954--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Re-enabling simple tx replacement

2015-01-04 Thread Gregory Maxwell
On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
 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).

Nevermind, I guess. I think I figured out your problem: The behaviour
on testnet is busted because the non-mempooling is enforced by
IsStandardTx which is bypassed in testnet. We should enforce that
elsewhere.

This isn't the case on the real network.

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Re-enabling simple tx replacement

2015-01-04 Thread Peter Todd
On Sun, Jan 04, 2015 at 05:44:59PM +, Gregory Maxwell wrote:
 On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
  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).
 
 Nevermind, I guess. I think I figured out your problem: The behaviour
 on testnet is busted because the non-mempooling is enforced by
 IsStandardTx which is bypassed in testnet. We should enforce that
 elsewhere.
 
 This isn't the case on the real network.

Yup.

I have a pull-req open to fix this:

https://github.com/bitcoin/bitcoin/pull/5521

-- 
'peter'[:-1]@petertodd.org
0237ec84e4b02efbdf3bcbf62308c873da802caedd12432f


signature.asc
Description: Digital signature
--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Re-enabling simple tx replacement

2015-01-04 Thread Ross Nicoll
On 04/01/15 17:44, Gregory Maxwell wrote:
 On Sun, Jan 4, 2015 at 5:35 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
 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).
 
 Nevermind, I guess. I think I figured out your problem: The behaviour
 on testnet is busted because the non-mempooling is enforced by
 IsStandardTx which is bypassed in testnet. We should enforce that
 elsewhere.
 
 This isn't the case on the real network.
 

Ah, thanks for that.

I'll try Peter's patch for testnet tomorrow, sounds like it should fix
this for my use case.


--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development