public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Andy Parkins <andyparkins@gmail.com>
To: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Lowering confirmation requirements and preventing double spends
Date: Fri, 9 Dec 2011 09:50:03 +0000	[thread overview]
Message-ID: <201112090950.10974.andyparkins@gmail.com> (raw)
In-Reply-To: <4EE13D8C.2020308@justmoon.de>

[-- 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 --]

      reply	other threads:[~2011-12-09  9:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201112090950.10974.andyparkins@gmail.com \
    --to=andyparkins@gmail.com \
    --cc=bitcoin-development@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox