Re: [bitcoin-dev] BIP clearing house addresses

[s7r <s7r@sky-ip.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4152 bytes --]

Hi,

I can clearly see some advantages for such a feature, but it's kind of
in conflict with Bitcoin's fundamental design. This design might be
problematic when it comes to hacks/thefts, but it's what gives Bitcoin
strength and make it differentiate from other currencies:

* reversal of transactions is impossible
* keep private keys private and safe. Lose them, it's like losing cash,
you can just forget about it.
* while we try hard to make 0-conf as safe as possible (if there's no
RBF flag on the transaction), we make it almost impossible or very very
expensive to reverse a confirmed transaction.

Also, we don't have a clear way to properly decide a good settlement
period length. It doesn't fix the problem any more than nLockTime fixes
it -- you can't know ahead of time when a withdraw needs to be made.
Fair enough, but even if the withdraw is made with a settlement layer,
will the user be able to spend it further immediately? Who will accept
such an input and treat it as a payment if it can be reversed during the
settlement layer? So, if you can't know ahead of time when a withdraw
needs to be made (nLockTime) how can you know ahead of time+settlement
period when a transaction needs to be declared irrevocable?

The linked page describes that merchants will never accept payments from
'vaults', and it will take 24 hours for coins to be irreversible moved
outside the 'vault'. This covers the part "is the user able to spend a
transaction with settlement layer" but it has security properties equal
to nLockTime = 24 hours - you can't benefit and use the coins
immediately and in 24 hours price might go up or down in an undesirable
way for a certain user. It however raises a lot of other questions: what
if the attacker manages to steal both the private key and vault key (we
have strong reasons to assume this can happen: if you can't keep a
private key safe, why would you be able to keep the vault key any
safer?) and starts a race with the actual user to unlock and lock back
the vault?

I think this is a wrong approach. hacks and big losses are sad, but all
the time users / exchanges are to blame for wrong implementations or
terrible security practices.

Thanks!

On 8/3/2016 9:16 PM, Matthew Roberts via bitcoin-dev wrote:
> In light of the recent hack: what does everyone think of the idea of
> creating a new address type that has a reversal key and settlement layer
> that can be used to revoke transactions?
> 
> You could specify so that transactions "sent" from these addresses must
> receive N confirmations before they can't be revoked, after which the
> transaction is "settled" and the coins become redeemable from their
> destination output. A settlement phase would also mean that a
> transaction's progress was publicly visible so transparent fraud
> prevention and auditing would become possible by anyone.
> 
> The reason why I bring this up is existing OP codes and TX types don't
> seem suitable for a secure clearing mechanism; Nlocktimed TXs won't work
> for this since you can't know ahead of time when and where a withdrawal
> needs to be made, plus there's still the potential for key
> mismanagement; Similar problems with OP_CHECKLOCKTIMEVERIFY apply too –
> unless you keep a private key around on the server which would defeat
> the purpose. The main use case here, would be specifically to improve
> centralized exchange security by making it impossible for a hot wallet
> to be raided all at once.
> 
> Thoughts?
> 
> Some existing background:
> 
> http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-been-avoided/
> -- Proposed the basic idea for a time-based clearing house but using
> blockchains directly, this is a much better idea than my own.
> 
> roberts.pm/timechain <http://roberts.pm/timechain> -- My original paper
> written in 2015 which proposed a similar idea for secure wallet design
> but implemented using time-locked ECDSA keys. Obviously a blockchain
> would work better for this.
> 
> Other -- if the idea has already been brought up by other people, I
> apologize.
> 


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]