* [Bitcoin-development] Lowering confirmation requirements and preventing double spends
@ 2011-12-08 10:47 Andy Parkins
2011-12-08 22:43 ` Stefan Thomas
0 siblings, 1 reply; 3+ messages in thread
From: Andy Parkins @ 2011-12-08 10:47 UTC (permalink / raw)
To: bitcoin-development
Hello,
Another of my crazy ideas:
When a transaction is first broadcast, it should include the hash of the block
it wants to appear after, let's call it's basis block. That block can be
anything the claimer wants; but it allows the miners to add this condition:
the transactions outputs a new transaction claims must be before the new
transaction's basis block.
Consider this block chain fork:
* -- * -- F -- * -- 1 -- 4 -- 5
\
* -- 2 -- 3
Let's say in block 2; I transfer coins from address A to Mt.Gox (or any other
pooled-account online wallet). In block 1 I transfer credit from address A to
address B. In block 3 I transfer credit from Mt.Gox's pool to address B.
The chain at 3 races out first, but eventually the chain at 5 becomes "the
one". If Mt.Gox are foolish enough to broadcast my withdrawl in 3; there is
nothing to stop that same withdrawl making it into 4 (since it comes from a
pooled fund address). Therefore Mt.Gox can't allow such a fast turnaround and
must wait for six confirmations of 2 before allowing use of the funds. That
is an inconvenience for all the honest users.
With my proposed change, the Mt.Gox transaction broadcast at 3 would include
"block 2" as its basis block. Therefore that transaction could never make it
into block 4, as no miner will include a transaction based on block 2 in the
block 4 chain.
Mt.Gox is probably not a good example, as they have problems with fiat to deal
with too. However, for other online wallet accounts it would allow faster
acceptance of received funds, since there is no danger of loss should an
attacker arrange a reorganisation.
This basis block would be optional (implied by the input transactions if it
isn't present); and would only need storing for the pending transactions, so
no incompatible change is needed to the block format.
Andy
--
Dr Andy Parkins
andyparkins@gmail•com
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] Lowering confirmation requirements and preventing double spends
2011-12-08 10:47 [Bitcoin-development] Lowering confirmation requirements and preventing double spends Andy Parkins
@ 2011-12-08 22:43 ` Stefan Thomas
2011-12-09 9:50 ` Andy Parkins
0 siblings, 1 reply; 3+ messages in thread
From: Stefan Thomas @ 2011-12-08 22:43 UTC (permalink / raw)
To: bitcoin-development
Hey Andy,
Bitcoin already does something which in practice has exactly this
effect: If a transaction is reversed, any transactions based on its
outputs are rejected.
Hosted wallets can make use of this - but as you correctly point out,
depending on the service, it can get tricky. What if I exchange the
money to USD and back before withdrawing? You could have an algorithm
where MtGox prefers to spend outputs from your own deposits as the
inputs for your withdrawals, it's not trivial though and never 100% secure.
I have trouble thinking of a good example where you need an explicit
block dependency as you describe. The only times you'd want to use this
dependency of transactions on specific previous transactions is when you
can clearly and easily associate the money. But if you can clearly and
easily associate the money, you might as well just relate the
transactions (use the outputs from the deposit transaction as the inputs
of the withdrawal transaction.)
This is btw something that would strongly agree with: Hosted wallets
should absolutely keep each account as separate public keys. With that
you lose free and instant internal transactions, but you gain instant
deposits and much better risk isolation.
This is just my view. Thanks and keep the thought-provoking stuff coming!
Cheers,
Stefan
On 12/8/2011 11:47 AM, Andy Parkins wrote:
> Hello,
>
> Another of my crazy ideas:
>
> When a transaction is first broadcast, it should include the hash of the block
> it wants to appear after, let's call it's basis block. That block can be
> anything the claimer wants; but it allows the miners to add this condition:
> the transactions outputs a new transaction claims must be before the new
> transaction's basis block.
>
> Consider this block chain fork:
>
> * -- * -- F -- * -- 1 -- 4 -- 5
> \
> * -- 2 -- 3
>
> Let's say in block 2; I transfer coins from address A to Mt.Gox (or any other
> pooled-account online wallet). In block 1 I transfer credit from address A to
> address B. In block 3 I transfer credit from Mt.Gox's pool to address B.
>
> The chain at 3 races out first, but eventually the chain at 5 becomes "the
> one". If Mt.Gox are foolish enough to broadcast my withdrawl in 3; there is
> nothing to stop that same withdrawl making it into 4 (since it comes from a
> pooled fund address). Therefore Mt.Gox can't allow such a fast turnaround and
> must wait for six confirmations of 2 before allowing use of the funds. That
> is an inconvenience for all the honest users.
>
> With my proposed change, the Mt.Gox transaction broadcast at 3 would include
> "block 2" as its basis block. Therefore that transaction could never make it
> into block 4, as no miner will include a transaction based on block 2 in the
> block 4 chain.
>
> Mt.Gox is probably not a good example, as they have problems with fiat to deal
> with too. However, for other online wallet accounts it would allow faster
> acceptance of received funds, since there is no danger of loss should an
> attacker arrange a reorganisation.
>
> This basis block would be optional (implied by the input transactions if it
> isn't present); and would only need storing for the pending transactions, so
> no incompatible change is needed to the block format.
>
>
>
> Andy
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [Bitcoin-development] Lowering confirmation requirements and preventing double spends
2011-12-08 22:43 ` Stefan Thomas
@ 2011-12-09 9:50 ` Andy Parkins
0 siblings, 0 replies; 3+ messages in thread
From: Andy Parkins @ 2011-12-09 9:50 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: Text/Plain, Size: 3329 bytes --]
On 2011 December 08 Thursday, Stefan Thomas wrote:
> Bitcoin already does something which in practice has exactly this
> effect: If a transaction is reversed, any transactions based on its
> outputs are rejected.
That part is fine; I was aware that Bitcoin did this. How could it not? The
transactions form multiple signature chains of their own. It impossible to
have a transaction depend on a non-existent input transaction.
> Hosted wallets can make use of this - but as you correctly point out,
> depending on the service, it can get tricky. What if I exchange the
> money to USD and back before withdrawing? You could have an algorithm
> where MtGox prefers to spend outputs from your own deposits as the
> inputs for your withdrawals, it's not trivial though and never 100% secure.
Quite so; this is essentially the problem my suggestion addresses. What do
you do when a transaction is dependent on another transaction financially but
not technically? That is to say that your accounting software would show a
credit and a debit to a particular entity, but the bitcoin block chain would
not. In the old world we might do this as "I'll write you a cheque and you
give me cash"; if that cheque bounces, you've lost your cash.
> I have trouble thinking of a good example where you need an explicit
> block dependency as you describe. The only times you'd want to use this
> dependency of transactions on specific previous transactions is when you
> can clearly and easily associate the money. But if you can clearly and
> easily associate the money, you might as well just relate the
> transactions (use the outputs from the deposit transaction as the inputs
> of the withdrawal transaction.)
The MyBitcoin debacle (if we are to believe their reports) would have been
avoided by my suggestion. They were accepting deposits in one chain, and
allowing withdrawls from another. That meant that while there was a financial
connection, there was not a bitcoin-connection. The withdrawls happened from
the pool address, most likely well funded, so were valid on either chain. If
MyBitcoin had been able to broadcast the withdrawl transactions as being based
on the same chain as the deposit (even though it was not using transactions in
that chain) then the attack would have failed.
> This is btw something that would strongly agree with: Hosted wallets
> should absolutely keep each account as separate public keys. With that
> you lose free and instant internal transactions, but you gain instant
> deposits and much better risk isolation.
I'm not sure I agree. There is certainly a case for both types: one-to-one
correspondence between address and account has the advantages you list but is
highly identifiable and trackable. However the disadvantage is that all funds
would have to be kept online. Places like Mt.Gox can (although there is
evidence to suggest that they don't, tut tu) move the majority of the funds to
five USB sticks, and keep them in five fire-proof safes or deposit boxes or
whatever only because deposited funds are pooled.
> This is just my view. Thanks and keep the thought-provoking stuff coming!
Thanks for the encouragement. It's appreciated.
Andy
--
Dr Andy Parkins
andyparkins@gmail•com
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-12-09 9:50 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-12-08 10:47 [Bitcoin-development] Lowering confirmation requirements and preventing double spends Andy Parkins
2011-12-08 22:43 ` Stefan Thomas
2011-12-09 9:50 ` Andy Parkins
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox