* [Bitcoin-development] DS Deprecation Window
@ 2014-10-27 19:58 Tom Harding
2014-10-27 20:17 ` Matt Corallo
0 siblings, 1 reply; 7+ messages in thread
From: Tom Harding @ 2014-10-27 19:58 UTC (permalink / raw)
To: Bitcoin Dev
Greetings Bitcoin Dev,
This is a proposal to improve the ability of bitcoin users to rely on
unconfirmed transactions. It can be adopted incrementally, with no hard
or soft fork required.
https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md
Your thoughtful feedback would be very much appreciated.
It is not yet implemented anywhere.
Cheers,
Tom Harding
CA, USA
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] DS Deprecation Window
2014-10-27 19:58 [Bitcoin-development] DS Deprecation Window Tom Harding
@ 2014-10-27 20:17 ` Matt Corallo
2014-10-28 2:26 ` Tom Harding
0 siblings, 1 reply; 7+ messages in thread
From: Matt Corallo @ 2014-10-27 20:17 UTC (permalink / raw)
To: bitcoin-development
It is a very bad idea to delay relaying/accepting blocks based on
information which is only local to your node (ie would create the
ability for people to split the network by sending out lots of
double-spends to different parts of the network at the same time). Thus,
miners are incentivized to go connect to everyone on the network and
look for double-spends, not including them in their blocks to avoid
being delayed (which is OK, except having to connect to everyone is bad).
There is a related concept of "discouraging" blocks which generally only
refers to mining on a previous block, but you have to be careful doing
that so you dont break consensus.
On 10/27/14 19:58, Tom Harding wrote:
> Greetings Bitcoin Dev,
>
> This is a proposal to improve the ability of bitcoin users to rely on
> unconfirmed transactions. It can be adopted incrementally, with no hard
> or soft fork required.
>
> https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md
>
> Your thoughtful feedback would be very much appreciated.
>
> It is not yet implemented anywhere.
>
> Cheers,
> Tom Harding
> CA, USA
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] DS Deprecation Window
2014-10-27 20:17 ` Matt Corallo
@ 2014-10-28 2:26 ` Tom Harding
2014-10-28 2:36 ` Gregory Maxwell
2014-10-28 6:24 ` Thomas Zander
0 siblings, 2 replies; 7+ messages in thread
From: Tom Harding @ 2014-10-28 2:26 UTC (permalink / raw)
To: bitcoin-development
Matt,
You're right, thanks. Without double-spend relay, miner won't know that
some txes conflict with anything. I'll add that first-double-spends are
relayed per #4570.
Miner has to be very careful including a double-spend in his block -- he
hopes:
- that based on his measured time offset from the first spend he
received, at most a tiny fraction of the network will delay his block
- that not too many nodes saw an earlier spend that he didn't see,
which could increase that fraction
- that most other nodes saw his tx. Any who didn't will only learn
about it by receiving his block, and they will assign it the time when
they receive the block. That's likely to be more than T (30 seconds)
after an earlier spend, so they would delay the block.
The best course of action is intended to be for miner to exclude fast (<
2 hours) double spends completely.
On 10/27/2014 1:17 PM, Matt Corallo wrote:
> miners are incentivized to go connect to everyone on the network and
> look for double-spends
>
> On 10/27/14 19:58, Tom Harding wrote:
>> https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] DS Deprecation Window
2014-10-28 2:26 ` Tom Harding
@ 2014-10-28 2:36 ` Gregory Maxwell
2014-10-28 17:38 ` Tom Harding
2014-10-28 6:24 ` Thomas Zander
1 sibling, 1 reply; 7+ messages in thread
From: Gregory Maxwell @ 2014-10-28 2:36 UTC (permalink / raw)
To: Tom Harding; +Cc: Bitcoin Development
On Tue, Oct 28, 2014 at 2:26 AM, Tom Harding <tomh@thinlink•com> wrote:
> Matt,
>
> You're right, thanks. Without double-spend relay, miner won't know that
> some txes conflict with anything.
Even with that, the miner cannot tell, his only safe option is to
include no transactions at all.
Consider a malicious miner can concurrently flood all other miners
with orthogonal double spends (which he doesn't mine himself). These
other miners will all be spending some amount of their time mining on
these transactions before realizing others consider them
double-spends.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] DS Deprecation Window
2014-10-28 2:26 ` Tom Harding
2014-10-28 2:36 ` Gregory Maxwell
@ 2014-10-28 6:24 ` Thomas Zander
1 sibling, 0 replies; 7+ messages in thread
From: Thomas Zander @ 2014-10-28 6:24 UTC (permalink / raw)
To: bitcoin-development
On Monday 27. October 2014 19.26.48 Tom Harding wrote:
> Miner has to be very careful including a double-spend in his block -- he
> hopes:
How does it help the zero-confirmation to not include a payment? Doesn't that
just mean that if I send a double spend that neither of the payments will be
made? So the thief just got an even bigger incentive to double-spent!
> - that based on his measured time offset from the first spend he
> received, at most a tiny fraction of the network will delay his block
>
> - that not too many nodes saw an earlier spend that he didn't see,
> which could increase that fraction
>
> - that most other nodes saw his tx. Any who didn't will only learn
> about it by receiving his block, and they will assign it the time when
> they receive the block. That's likely to be more than T (30 seconds)
> after an earlier spend, so they would delay the block.
This doesn't addresses the point that Matt brought up.
Your proposal essentially has some side effects that would be disastrous to
miners. As detailed by the other two replies on this thread.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] DS Deprecation Window
2014-10-28 2:36 ` Gregory Maxwell
@ 2014-10-28 17:38 ` Tom Harding
2014-11-06 23:50 ` Tom Harding
0 siblings, 1 reply; 7+ messages in thread
From: Tom Harding @ 2014-10-28 17:38 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: Bitcoin Development
On 10/27/2014 7:36 PM, Gregory Maxwell wrote:
> Consider a malicious miner can concurrently flood all other miners
> with orthogonal double spends (which he doesn't mine himself). These
> other miners will all be spending some amount of their time mining on
> these transactions before realizing others consider them
> double-spends.
If I understand correctly, the simplest example of this attack is three
transactions spending the same coin, distributed to two miners like this:
Miner A Miner B
Mempool tx1a tx1b
Relayed tx2 tx2
Since relay has to be limited, Miner B doesn't know about tx1a until it
is included in Miner A's block, so he delays that block (unless it
appears very quickly).
To create this situation, attacker has to transmit all three
transactions very quickly, or mempools will be too synchronized.
Attacker tries to make it so that everyone else has a tx1a conflict that
Miner A does not have. Ditto for each individual victim, with different
transactions (this seems very difficult).
Proposal shows that there is always a tiny risk to including tx1 when a
double-spend is known, and I agree that this attack can add something to
that risk. Miner A can neutralize his risk by excluding any tx1 known
to be double-spent, but as Thomas Zander wrote, that is an undesirable
outcome.
However, Miner A has additional information - he knows how soon he
received tx2 after receiving tx1a.
The attack has little chance of working if any of the malicious
transactions are sent even, say, 10 seconds apart from each other.
Dropping the labels for transmit-order numbering, if the 1->2 transmit
gap is large, mempools will agree on 1. If 1->2 gap is small, but the
gap to 3 is large, mempools will agree on the 1-2 pair, but possibly
have the order reversed. Either way, mempools won't disagree on the
existence of 1 unless the 1->3 gap is small.
So, I think it will be possible to quantify and target the risk of
including tx1a to an arbitrarily low level, based on the local
measurement of the time gap to tx2, and an effective threshold won't be
very high. It does highlight yet again, the shorter the time frame, the
greater the risk.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Bitcoin-development] DS Deprecation Window
2014-10-28 17:38 ` Tom Harding
@ 2014-11-06 23:50 ` Tom Harding
0 siblings, 0 replies; 7+ messages in thread
From: Tom Harding @ 2014-11-06 23:50 UTC (permalink / raw)
To: Bitcoin Development
Added a section "Confidence to include tx1" and subsection "Deliberate
delay attack"
https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md
I found that under concerted attack, if miner excludes any transaction
first seen less than 30 seconds ago, or double-spent less than 30
seconds after first seen, he should expect 5 of 10000 nodes to delay his
block.
Hal Finney remarked that this idea would need "careful analysis." More
help is very welcome.
https://bitcointalk.org/index.php?topic=3441.msg48789#msg48789
Cheers!
On 10/28/2014 10:38 AM, Tom Harding wrote:
> So, I think it will be possible to quantify and target the risk of
> including tx1...
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-11-06 23:51 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-27 19:58 [Bitcoin-development] DS Deprecation Window Tom Harding
2014-10-27 20:17 ` Matt Corallo
2014-10-28 2:26 ` Tom Harding
2014-10-28 2:36 ` Gregory Maxwell
2014-10-28 17:38 ` Tom Harding
2014-11-06 23:50 ` Tom Harding
2014-10-28 6:24 ` Thomas Zander
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox