public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] BIP clearing house addresses
@ 2016-08-03 18:16 Matthew Roberts
  2016-08-03 21:13 ` Troy Benjegerdes
                   ` (3 more replies)
  0 siblings, 4 replies; 16+ messages in thread
From: Matthew Roberts @ 2016-08-03 18:16 UTC (permalink / raw)
  To: bitcoin-dev

[-- Attachment #1: Type: text/plain, Size: 1745 bytes --]

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 -- 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: Type: text/html, Size: 2292 bytes --]

^ permalink raw reply	[flat|nested] 16+ messages in thread

• * Re: [bitcoin-dev] BIP clearing house addresses
    2016-08-03 18:16 [bitcoin-dev] BIP clearing house addresses Matthew Roberts
  @ 2016-08-03 21:13 ` Troy Benjegerdes
    2016-08-03 23:55 ` Tier Nolan
                     ` (2 subsequent siblings)
    3 siblings, 0 replies; 16+ messages in thread
  From: Troy Benjegerdes @ 2016-08-03 21:13 UTC (permalink / raw)
    To: Matthew Roberts, Bitcoin Protocol Discussion
  
  On Thu, Aug 04, 2016 at 04:16:20AM +1000, 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?
  
  I think many of us who think about human - computer interactions see the
  need for a well defined process to roll back unexpected behavior in a computer
  system. My 2014 era proposal is https://bitbucket.org/tmagik/catoshi/issues/24
  
  The fundamental assumption around cryptocoins is you have a secret (private
  key) known only by you. Currently in bitcoin if that assumption changes, the
  response is blame the user. 'Incompetence, etc, etc'
  
  This is bad business. For any cryptocurrency to really get mass market, we
  need to provide our users with key revocation, to be used when the assumption
  about being the only holder of a secret is broken.
  
  I think there's a hardfork-worthy choice here:
  
  1) implement reversal/revocation as an add-on feature
  2) implement reversal/revocation as a fundamental that every address gets.
  
  Ethereum made a quick hardfork choice to reverse a *single* instance of
  unexpected behavior, and looks a lot like a bank bailout. We have the chance
  to learn from this mistake, and, apparently, make a lot of money trading
  on both sides of the hardfork.
  
  > 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 -- 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.
  
  > _______________________________________________
  > bitcoin-dev mailing list
  > bitcoin-dev@lists•linuxfoundation.org
  > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
  
  
  
  ^ permalink raw reply	[flat|nested] 16+ messages in thread

• * Re: [bitcoin-dev] BIP clearing house addresses
    2016-08-03 18:16 [bitcoin-dev] BIP clearing house addresses Matthew Roberts
    2016-08-03 21:13 ` Troy Benjegerdes
  @ 2016-08-03 23:55 ` Tier Nolan
    2016-08-04  2:07   ` Matthew Roberts
    2016-08-04  3:27 ` Luke Dashjr
    2016-08-06 10:39 ` s7r
    3 siblings, 1 reply; 16+ messages in thread
  From: Tier Nolan @ 2016-08-03 23:55 UTC (permalink / raw)
    To: Bitcoin Protocol Discussion
  
  [-- Attachment #1: Type: text/plain, Size: 1351 bytes --]
  
  On Wed, Aug 3, 2016 at 7:16 PM, Matthew Roberts via bitcoin-dev <
  bitcoin-dev@lists•linuxfoundation.org> wrote:
  
  > The reason why I bring this up is existing OP codes and TX types don't
  > seem suitable for a secure clearing mechanism;
  >
  
  I think reversing transactions is not likely to be acceptable.  You could
  add an opcode that requires that an output be set to something.
  
  [target script] SPENDTO
  
  This would require that [target script] is the script for the corresponding
  output.  This is a purely local check.
  
  For example, if SPENDTO executes as part of the script for input 3, then it
  checks that output 3 uses the given script as its scriptPubKey.  The value
  of input 3 and output 3 would have to be the same too.
  
  This allows check sequence verify to be used to lock the spending script
  for a while.  This doesn't allow reversal, but would give a 24 hour window
  where the spenders can reverse the transaction.
  
  [IF <1 day> CSV DROP <live public key> CHECKSIG ELSE <offline protected
  key> CHECKSIG] SPENDTO <live public key2> CHECKSIG
  
  Someone with the live public key can create a transaction that spends the
  funds to the script in the square brackets.
  
  Once that transaction hits the blockchain, then someone with the <offline
  protected key> has 24 hours to spend the output before the person with the
  live keys can send the funds onward.
  
  [-- Attachment #2: Type: text/html, Size: 1865 bytes --]
  
  ^ permalink raw reply	[flat|nested] 16+ messages in thread

• • * Re: [bitcoin-dev] BIP clearing house addresses
      2016-08-03 23:55 ` Tier Nolan
    @ 2016-08-04  2:07   ` Matthew Roberts
      0 siblings, 0 replies; 16+ messages in thread
    From: Matthew Roberts @ 2016-08-04  2:07 UTC (permalink / raw)
      To: Tier Nolan, Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 2107 bytes --]
    
    This would honestly work. It forces the attacker to go through with the
    clearing phase which simultaneously makes it possible to "cancel" the TX
    through another logic branch before the timeout occurs. I'd say that would
    meet the needs of a clearing mechanism / fraud prevention system for an
    exchange perfectly while requiring minimal changes to the software.
    
    Very, very smart idea. A++, would read again.
    
    On Thu, Aug 4, 2016 at 9:55 AM, Tier Nolan via bitcoin-dev <
    bitcoin-dev@lists•linuxfoundation.org> wrote:
    
    > On Wed, Aug 3, 2016 at 7:16 PM, Matthew Roberts via bitcoin-dev <
    > bitcoin-dev@lists•linuxfoundation.org> wrote:
    >
    >> The reason why I bring this up is existing OP codes and TX types don't
    >> seem suitable for a secure clearing mechanism;
    >>
    >
    > I think reversing transactions is not likely to be acceptable.  You could
    > add an opcode that requires that an output be set to something.
    >
    > [target script] SPENDTO
    >
    > This would require that [target script] is the script for the
    > corresponding output.  This is a purely local check.
    >
    > For example, if SPENDTO executes as part of the script for input 3, then
    > it checks that output 3 uses the given script as its scriptPubKey.  The
    > value of input 3 and output 3 would have to be the same too.
    >
    > This allows check sequence verify to be used to lock the spending script
    > for a while.  This doesn't allow reversal, but would give a 24 hour window
    > where the spenders can reverse the transaction.
    >
    > [IF <1 day> CSV DROP <live public key> CHECKSIG ELSE <offline protected
    > key> CHECKSIG] SPENDTO <live public key2> CHECKSIG
    >
    > Someone with the live public key can create a transaction that spends the
    > funds to the script in the square brackets.
    >
    > Once that transaction hits the blockchain, then someone with the <offline
    > protected key> has 24 hours to spend the output before the person with the
    > live keys can send the funds onward.
    >
    > _______________________________________________
    > bitcoin-dev mailing list
    > bitcoin-dev@lists•linuxfoundation.org
    > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    >
    >
    
    [-- Attachment #2: Type: text/html, Size: 3120 bytes --]
    
    ^ permalink raw reply	[flat|nested] 16+ messages in thread

• * Re: [bitcoin-dev] BIP clearing house addresses
    2016-08-03 18:16 [bitcoin-dev] BIP clearing house addresses Matthew Roberts
    2016-08-03 21:13 ` Troy Benjegerdes
    2016-08-03 23:55 ` Tier Nolan
  @ 2016-08-04  3:27 ` Luke Dashjr
    2016-08-04  3:49   ` Andrew Johnson
    2016-08-06 10:39 ` s7r
    3 siblings, 1 reply; 16+ messages in thread
  From: Luke Dashjr @ 2016-08-04  3:27 UTC (permalink / raw)
    To: bitcoin-dev, Matthew Roberts
  
  On Wednesday, August 03, 2016 6:16:20 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?
  
  This isn't something that makes sense at the address, since it represents the 
  recipient and not the sender. Transactions are not sent from addresses ever.
  
  > 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.
  
  This is already possible. Just nLockTime your withdrawls for some future 
  block. Don't sign any transaction that isn't nLockTime'd at least N blocks 
  beyond the present tip.
  
  Luke
  
  
  ^ permalink raw reply	[flat|nested] 16+ messages in thread

• • * Re: [bitcoin-dev] BIP clearing house addresses
      2016-08-04  3:27 ` Luke Dashjr
    @ 2016-08-04  3:49   ` Andrew Johnson
      2016-08-04  4:53     ` Matthew Roberts
      0 siblings, 1 reply; 16+ messages in thread
    From: Andrew Johnson @ 2016-08-04  3:49 UTC (permalink / raw)
      To: Luke Dashjr, Bitcoin Dev
    
    [-- Attachment #1: Type: text/plain, Size: 2486 bytes --]
    
    "This is already possible. Just nLockTime your withdrawls for some future
    block. Don't sign any transaction that isn't nLockTime'd at least N blocks
    beyond the present tip."
    
    This would have prevented the Bitfinex hack if BitGo did this, but it
    wouldn't have helped if the Bitfinex offline key had been compromised
    instead of BitGo doing the 2nd sig.  In the BFX hack the TXNs were signed
    by Bitfinex's hot key and BitGo's key, they required 2 of 2.
    
    If I'm understanding correctly, what Matthew is proposing is a new type of
    UTXO that is only valid to be spent as an nLockTime transaction and can be
    reversed by some sort of RBF-type transaction within that time period, I
    believe.
    
    But I don't think this will work. What do you do if the keys are
    compromised?  What's to stop the attacker from locking the coins up
    indefinitely by repeatedly broadcasting a refund transaction each time you
    try to spend to an uncompromised address?
    
    You'd need a third distinct key required for the refund TXN that's separate
    from the keys used to sign the initial nLockTime TXN.  And the refund TXN
    would need to be able to go to a new address entirely.
    
    On Aug 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" <
    bitcoin-dev@lists•linuxfoundation.org> wrote:
    
    > On Wednesday, August 03, 2016 6:16:20 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?
    >
    > This isn't something that makes sense at the address, since it represents
    > the
    > recipient and not the sender. Transactions are not sent from addresses
    > ever.
    >
    > > 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.
    >
    > This is already possible. Just nLockTime your withdrawls for some future
    > block. Don't sign any transaction that isn't nLockTime'd at least N blocks
    > beyond the present tip.
    >
    > Luke
    > _______________________________________________
    > bitcoin-dev mailing list
    > bitcoin-dev@lists•linuxfoundation.org
    > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
    >
    
    [-- Attachment #2: Type: text/html, Size: 3225 bytes --]
    
    ^ permalink raw reply	[flat|nested] 16+ messages in thread

  • • * Re: [bitcoin-dev] BIP clearing house addresses
        2016-08-04  3:49   ` Andrew Johnson
      @ 2016-08-04  4:53     ` Matthew Roberts
        2016-08-04 12:43       ` Erik Aronesty
        0 siblings, 1 reply; 16+ messages in thread
      From: Matthew Roberts @ 2016-08-04  4:53 UTC (permalink / raw)
        To: Andrew Johnson; +Cc: Bitcoin Dev
      
      [-- Attachment #1: Type: text/plain, Size: 4064 bytes --]
      
      >This is already possible. Just nLockTime your withdrawls for some future
      block. Don't sign any transaction that isn't nLockTime'd at least N blocks
      beyond the present tip.
      
      The problem with nLockTimed transactions is a centralized exchange isn't
      going to know ahead of time where those locked transactions need to go or
      the amount that needs to be signed so you will end up having to keep the
      private key around. If there was a way to create these transactions offline
      with special SIG_HASH flags (and I don't think there is) there's nothing
      about nLockTime that forces that the transactions be broadcast straight
      away and plus: since the TXs aren't confirmed until the lock-time expires
      they can be overwritten anyway.
      
      I think given the requirements that a centralized exchange has: TierNolan's
      idea is the best so far. Essentially, you have a new type of output script
      that forces the redeemer to use a designated output script template in the
      redeeming transaction, meaning that you can actually force people to send
      coins into another transaction with "relative lock-timed" outputs. The new
      transaction can then only be redeemed at the destination after the relative
      lock-time expires OR it can be moved before-hand to a designated off-line
      recovery address. This is much better than creating a new transaction
      system, IMO.
      
      >And the refund TXN would need to be able to go to a new address entirely.
      
      Agreed.
      
      On Thu, Aug 4, 2016 at 1:49 PM, Andrew Johnson <andrew.johnson83@gmail•com>
      wrote:
      
      > "This is already possible. Just nLockTime your withdrawls for some future
      > block. Don't sign any transaction that isn't nLockTime'd at least N blocks
      > beyond the present tip."
      >
      > This would have prevented the Bitfinex hack if BitGo did this, but it
      > wouldn't have helped if the Bitfinex offline key had been compromised
      > instead of BitGo doing the 2nd sig.  In the BFX hack the TXNs were signed
      > by Bitfinex's hot key and BitGo's key, they required 2 of 2.
      >
      > If I'm understanding correctly, what Matthew is proposing is a new type of
      > UTXO that is only valid to be spent as an nLockTime transaction and can be
      > reversed by some sort of RBF-type transaction within that time period, I
      > believe.
      >
      > But I don't think this will work. What do you do if the keys are
      > compromised?  What's to stop the attacker from locking the coins up
      > indefinitely by repeatedly broadcasting a refund transaction each time you
      > try to spend to an uncompromised address?
      >
      > You'd need a third distinct key required for the refund TXN that's
      > separate from the keys used to sign the initial nLockTime TXN.  And the
      > refund TXN would need to be able to go to a new address entirely.
      >
      > On Aug 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" <
      > bitcoin-dev@lists•linuxfoundation.org> wrote:
      >
      >> On Wednesday, August 03, 2016 6:16:20 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?
      >>
      >> This isn't something that makes sense at the address, since it represents
      >> the
      >> recipient and not the sender. Transactions are not sent from addresses
      >> ever.
      >>
      >> > 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.
      >>
      >> This is already possible. Just nLockTime your withdrawls for some future
      >> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
      >> beyond the present tip.
      >>
      >> Luke
      >> _______________________________________________
      >> bitcoin-dev mailing list
      >> bitcoin-dev@lists•linuxfoundation.org
      >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      >>
      >
      
      [-- Attachment #2: Type: text/html, Size: 5276 bytes --]
      
      ^ permalink raw reply	[flat|nested] 16+ messages in thread

    • • * Re: [bitcoin-dev] BIP clearing house addresses
          2016-08-04  4:53     ` Matthew Roberts
        @ 2016-08-04 12:43       ` Erik Aronesty
          0 siblings, 0 replies; 16+ messages in thread
        From: Erik Aronesty @ 2016-08-04 12:43 UTC (permalink / raw)
          To: Matthew Roberts, Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 4587 bytes --]
        
        https://www.reddit.com/r/Bitcoin/comments/4w016b/use_of_payment_channels_to_mitigate_exchange_risk/
        
        On Thu, Aug 4, 2016 at 12:53 AM, Matthew Roberts via bitcoin-dev <
        bitcoin-dev@lists•linuxfoundation.org> wrote:
        
        > >This is already possible. Just nLockTime your withdrawls for some future
        > block. Don't sign any transaction that isn't nLockTime'd at least N blocks
        > beyond the present tip.
        >
        > The problem with nLockTimed transactions is a centralized exchange isn't
        > going to know ahead of time where those locked transactions need to go or
        > the amount that needs to be signed so you will end up having to keep the
        > private key around. If there was a way to create these transactions offline
        > with special SIG_HASH flags (and I don't think there is) there's nothing
        > about nLockTime that forces that the transactions be broadcast straight
        > away and plus: since the TXs aren't confirmed until the lock-time expires
        > they can be overwritten anyway.
        >
        > I think given the requirements that a centralized exchange has:
        > TierNolan's idea is the best so far. Essentially, you have a new type of
        > output script that forces the redeemer to use a designated output script
        > template in the redeeming transaction, meaning that you can actually force
        > people to send coins into another transaction with "relative lock-timed"
        > outputs. The new transaction can then only be redeemed at the destination
        > after the relative lock-time expires OR it can be moved before-hand to a
        > designated off-line recovery address. This is much better than creating a
        > new transaction system, IMO.
        >
        > >And the refund TXN would need to be able to go to a new address entirely.
        >
        > Agreed.
        >
        > On Thu, Aug 4, 2016 at 1:49 PM, Andrew Johnson <andrew.johnson83@gmail•com
        > > wrote:
        >
        >> "This is already possible. Just nLockTime your withdrawls for some future
        >> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
        >> beyond the present tip."
        >>
        >> This would have prevented the Bitfinex hack if BitGo did this, but it
        >> wouldn't have helped if the Bitfinex offline key had been compromised
        >> instead of BitGo doing the 2nd sig.  In the BFX hack the TXNs were signed
        >> by Bitfinex's hot key and BitGo's key, they required 2 of 2.
        >>
        >> If I'm understanding correctly, what Matthew is proposing is a new type
        >> of UTXO that is only valid to be spent as an nLockTime transaction and can
        >> be reversed by some sort of RBF-type transaction within that time period, I
        >> believe.
        >>
        >> But I don't think this will work. What do you do if the keys are
        >> compromised?  What's to stop the attacker from locking the coins up
        >> indefinitely by repeatedly broadcasting a refund transaction each time you
        >> try to spend to an uncompromised address?
        >>
        >> You'd need a third distinct key required for the refund TXN that's
        >> separate from the keys used to sign the initial nLockTime TXN.  And the
        >> refund TXN would need to be able to go to a new address entirely.
        >>
        >> On Aug 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" <
        >> bitcoin-dev@lists•linuxfoundation.org> wrote:
        >>
        >>> On Wednesday, August 03, 2016 6:16:20 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?
        >>>
        >>> This isn't something that makes sense at the address, since it
        >>> represents the
        >>> recipient and not the sender. Transactions are not sent from addresses
        >>> ever.
        >>>
        >>> > 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.
        >>>
        >>> This is already possible. Just nLockTime your withdrawls for some future
        >>> block. Don't sign any transaction that isn't nLockTime'd at least N
        >>> blocks
        >>> beyond the present tip.
        >>>
        >>> Luke
        >>> _______________________________________________
        >>> bitcoin-dev mailing list
        >>> bitcoin-dev@lists•linuxfoundation.org
        >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >>>
        >>
        >
        > _______________________________________________
        > bitcoin-dev mailing list
        > bitcoin-dev@lists•linuxfoundation.org
        > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >
        >
        
        [-- Attachment #2: Type: text/html, Size: 6388 bytes --]
        
        ^ permalink raw reply	[flat|nested] 16+ messages in thread

• * Re: [bitcoin-dev] BIP clearing house addresses
    2016-08-03 18:16 [bitcoin-dev] BIP clearing house addresses Matthew Roberts
                     ` (2 preceding siblings ...)
    2016-08-04  3:27 ` Luke Dashjr
  @ 2016-08-06 10:39 ` s7r
    2016-08-06 11:13   ` Tier Nolan
    3 siblings, 1 reply; 16+ messages in thread
  From: s7r @ 2016-08-06 10:39 UTC (permalink / raw)
    To: bitcoin-dev
  
  
  [-- 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 --]
  
  ^ permalink raw reply	[flat|nested] 16+ messages in thread

• • * Re: [bitcoin-dev] BIP clearing house addresses
      2016-08-06 10:39 ` s7r
    @ 2016-08-06 11:13   ` Tier Nolan
      2016-08-07  5:35     ` Matthew Roberts
      0 siblings, 1 reply; 16+ messages in thread
    From: Tier Nolan @ 2016-08-06 11:13 UTC (permalink / raw)
      To: Bitcoin Protocol Discussion
    
    [-- Attachment #1: Type: text/plain, Size: 2432 bytes --]
    
    On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <
    bitcoin-dev@lists•linuxfoundation.org> wrote:
    
    > * reversal of transactions is impossible
    >
    
    I think it would be more accurate to say that the requirement is that
    reversal doesn't happen unexpectedly.
    
    If it is clear in the script that reversal is possible, then obviously the
    recipient can take that into consideration.
    
    
    > * keep private keys private and safe. Lose them, it's like losing cash,
    > you can just forget about it.
    >
    
    Key management is a thing.  Managing risk by keeping some keys offline is
    an important part of that.
    
    
    > * 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.
    >
    
    BitGo has an "instant" system where they promise to only sign one
    transaction for a given output.  If you trust BitGo, then this is safe from
    double spending, since a double spender can't sign two transactions.
    
    If BitGo had actually implemented a daily withdrawal limit, then their
    system ends up similar to cold storage.  Only 10% of the funds at Bitfinex
    could have been withdrawn before manual intervention was required (with
    offline keys).
    
    Who will accept
    > such an input and treat it as a payment if it can be reversed during the
    > settlement layer?
    
    
    Obviously, if a payment is reversible, then you treat it as a reversible
    payment.  The protection here relates to moving coins from the equivalent
    of cold storage to hot storage.
    
    It is OK if it takes longer, since security is more important than
    convenience for coins in cold storage.
    
    
    > 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 relates to the reserves held by the exchange.  A portion of the funds
    are in hot storage with live keys.  These funds can be stolen by anyone who
    gets access to the servers.  The remaining funds are held in cold storage
    and they cannot be accessed unless you have the offline keys.  These funds
    are supposed to be hard to reach and require manual intervention.
    
    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.
    >
    
    Setting up offline keys to act as firebreaks is part of good security
    practices.
    
    [-- Attachment #2: Type: text/html, Size: 3678 bytes --]
    
    ^ permalink raw reply	[flat|nested] 16+ messages in thread

  • • * Re: [bitcoin-dev] BIP clearing house addresses
        2016-08-06 11:13   ` Tier Nolan
      @ 2016-08-07  5:35     ` Matthew Roberts
        2016-08-07 22:59       ` Erik Aronesty
        0 siblings, 1 reply; 16+ messages in thread
      From: Matthew Roberts @ 2016-08-07  5:35 UTC (permalink / raw)
        To: Tier Nolan, Bitcoin Protocol Discussion
      
      [-- Attachment #1: Type: text/plain, Size: 7222 bytes --]
      
      I'm wondering if we're fully on the same page here. What I was thinking was
      that this protection mechanism would be applied to the coins in the hot
      wallet (I wasn't talking about moving coins from the cold wallet to the hot
      wallet -- though such a mechanism is also needed.)
      
      With the hot wallet you would have an output script that only allowed coins
      to be sent to a new transaction whose output script was then only
      redeemable after N confirmations (the output is relative time-locked) but
      which can also be recovered to a fixed fail-safe address before the
      time-lock is reached (exactly like TierNolan already listed only the
      time-locked destination shouldn't be completely fixed.) So the private key
      for this hot wallet can still sign valid transactions to withdraw coins to
      any known destination and these transactions still reach the blockchain.
      
      The key difference from a regular transaction is that the destination only
      has access to the coins -after- the relative time-lock is reached (N blocks
      after first confirm) so everyone knows where withdrawals are suppose to be
      going and how many coins are being withdrawn at any given time. Deposits to
      the hot wallet would therefore need to be encumbered by the same protection
      so that from then on this time-lock to redeem coins can be applied to every
      new transaction trying to move coins (withdrawn by a user of the exchange
      or sent to the cold wallet.)
      
      Notice we don't care about the destination in the TX script for the hot
      wallet because to process user's withdrawals we can't know ahead of time
      where they need to be sent (so it isn't possible to use a fixed address
      here – though you might want to remove the clearing phase and set a fixed
      address for coins sent from the hot wallet to the cold wallet.) The benefit
      here comes from being able to see what withdrawals are being cleared,
      matching those up to our expectations, and being able to "cancel"
      withdrawals if they look suspicious, and you get the benefits for transfers
      made from the hot wallet to the cold wallet and visa-versa.
      
      
      This approach is good for a number of crucial services:
      
      1. Wallets could be built that grouped coins into different "accounts" with
      different time-frames required for clearing / unlocking coins. Your savings
      or investment account would say -- take up to a week to clear -- whereas
      your everyday account used for smaller purchases (with less money) would
      only take a few hours. This could all be linked up to services that
      notified you of your money being moved + made any phone calls needed to
      verify any larger transfers.
      
      The service could also be entrusted with the “cancellation” key which can
      only be used to move money to your offline fail-safe address. This would be
      quite an interesting way to mitigate fraud without the user having to be
      trusted to do anything (except I suppose – not storing their recovery keys
      online … but this could be partially solved with BIP 32-style “master”
      public keys + hardware wallets + multi-sig, N factor auth, etc ...)
      
      2. Gambling websites that process a lot of Bitcoins also have a hot wallet
      which could be better protected by this.
      
      3. Various other e-commerce websites also accept Bitcoins directly. (Deep
      web markets come to mind -- hey, people breaking the law need good security
      too.)
      
      4. Provable dead man's switches on the protocol level is another idea -- no
      need to keep special time-locked transactions around and rely on them to be
      broadcast = more reliable escrow services.
      
      5. And obviously exchange hot (and cold) wallets - enemy number 1.
      
      I hope that makes sense. I think I initially managed to confuse a lot of
      people by talking about revoking transactions / “settlement layers”, etc.
      But IMO: all of this needs to take place on the blockchain with a new set
      of OP_CODES and other than the fixed address issue with OP_SPENDTO, I think
      the general idea would still work.
      
      
      tl; dr, A pseudo-reversal mechanism for transactions would mean that stolen
      private keys were no longer such an issue. This is desperately needed for
      exchanges, wallets, and other services that are forced to manage private
      keys, and whose users (I argue) already expect for this to be possible (or
      at least will when they're hacked.)
      
      
      
      
      On Sat, Aug 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <
      bitcoin-dev@lists•linuxfoundation.org> wrote:
      
      > On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <bitcoin-dev@lists.
      > linuxfoundation.org> wrote:
      >
      >> * reversal of transactions is impossible
      >>
      >
      > I think it would be more accurate to say that the requirement is that
      > reversal doesn't happen unexpectedly.
      >
      > If it is clear in the script that reversal is possible, then obviously the
      > recipient can take that into consideration.
      >
      >
      >> * keep private keys private and safe. Lose them, it's like losing cash,
      >> you can just forget about it.
      >>
      >
      > Key management is a thing.  Managing risk by keeping some keys offline is
      > an important part of that.
      >
      >
      >> * 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.
      >>
      >
      > BitGo has an "instant" system where they promise to only sign one
      > transaction for a given output.  If you trust BitGo, then this is safe from
      > double spending, since a double spender can't sign two transactions.
      >
      > If BitGo had actually implemented a daily withdrawal limit, then their
      > system ends up similar to cold storage.  Only 10% of the funds at Bitfinex
      > could have been withdrawn before manual intervention was required (with
      > offline keys).
      >
      > Who will accept
      >> such an input and treat it as a payment if it can be reversed during the
      >> settlement layer?
      >
      >
      > Obviously, if a payment is reversible, then you treat it as a reversible
      > payment.  The protection here relates to moving coins from the equivalent
      > of cold storage to hot storage.
      >
      > It is OK if it takes longer, since security is more important than
      > convenience for coins in cold storage.
      >
      >
      >> 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 relates to the reserves held by the exchange.  A portion of the funds
      > are in hot storage with live keys.  These funds can be stolen by anyone who
      > gets access to the servers.  The remaining funds are held in cold storage
      > and they cannot be accessed unless you have the offline keys.  These funds
      > are supposed to be hard to reach and require manual intervention.
      >
      > 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.
      >>
      >
      > Setting up offline keys to act as firebreaks is part of good security
      > practices.
      >
      > _______________________________________________
      > bitcoin-dev mailing list
      > bitcoin-dev@lists•linuxfoundation.org
      > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
      >
      >
      
      [-- Attachment #2: Type: text/html, Size: 9540 bytes --]
      
      ^ permalink raw reply	[flat|nested] 16+ messages in thread

    • • * Re: [bitcoin-dev] BIP clearing house addresses
          2016-08-07  5:35     ` Matthew Roberts
        @ 2016-08-07 22:59       ` Erik Aronesty
          2016-08-08  0:48         ` Matthew Roberts
          0 siblings, 1 reply; 16+ messages in thread
        From: Erik Aronesty @ 2016-08-07 22:59 UTC (permalink / raw)
          To: Matthew Roberts, Bitcoin Protocol Discussion
        
        [-- Attachment #1: Type: text/plain, Size: 8788 bytes --]
        
        I still feel like you're better off getting rid of "hot wallets" and use
        lightning-esqe networks to route orders.  I don't think either speed or
        flexibility is an issue there.
        
        IMO, the point of Bitcoin is to avoid the centralization that seems to be
        happening on the network now.   By making "hot wallets" more "secure", we
        encourage things to keep heading downhill with massive centralized
        crappy-security exchanges.
        
        Because, ultimately, there's no security that will prevent an inside job.
        And all of these thefts have, in my opinion, been at least partly inside
        jobs.
        
        And centralization is the actually demon that needs slaying here.
        
        A client-side library with P2P order routing, tether.to + bitcoin ....  and
        you've got a decentralized exchange... with orders matched to users
        directly, and channel-trades executed instantly.   And "market makers"
        running nodes to facilitate routing, etc.
        
        No center... nothing to shut down or sue... and no one holds your funds.
        That's a real Bitcoin exchange.
        
        
        
        On Sun, Aug 7, 2016 at 1:35 AM, Matthew Roberts via bitcoin-dev <
        bitcoin-dev@lists•linuxfoundation.org> wrote:
        
        > I'm wondering if we're fully on the same page here. What I was thinking
        > was that this protection mechanism would be applied to the coins in the hot
        > wallet (I wasn't talking about moving coins from the cold wallet to the hot
        > wallet -- though such a mechanism is also needed.)
        >
        > With the hot wallet you would have an output script that only allowed
        > coins to be sent to a new transaction whose output script was then only
        > redeemable after N confirmations (the output is relative time-locked) but
        > which can also be recovered to a fixed fail-safe address before the
        > time-lock is reached (exactly like TierNolan already listed only the
        > time-locked destination shouldn't be completely fixed.) So the private key
        > for this hot wallet can still sign valid transactions to withdraw coins to
        > any known destination and these transactions still reach the blockchain.
        >
        > The key difference from a regular transaction is that the destination only
        > has access to the coins -after- the relative time-lock is reached (N blocks
        > after first confirm) so everyone knows where withdrawals are suppose to be
        > going and how many coins are being withdrawn at any given time. Deposits to
        > the hot wallet would therefore need to be encumbered by the same protection
        > so that from then on this time-lock to redeem coins can be applied to every
        > new transaction trying to move coins (withdrawn by a user of the exchange
        > or sent to the cold wallet.)
        >
        > Notice we don't care about the destination in the TX script for the hot
        > wallet because to process user's withdrawals we can't know ahead of time
        > where they need to be sent (so it isn't possible to use a fixed address
        > here – though you might want to remove the clearing phase and set a fixed
        > address for coins sent from the hot wallet to the cold wallet.) The benefit
        > here comes from being able to see what withdrawals are being cleared,
        > matching those up to our expectations, and being able to "cancel"
        > withdrawals if they look suspicious, and you get the benefits for transfers
        > made from the hot wallet to the cold wallet and visa-versa.
        >
        >
        > This approach is good for a number of crucial services:
        >
        > 1. Wallets could be built that grouped coins into different "accounts"
        > with different time-frames required for clearing / unlocking coins. Your
        > savings or investment account would say -- take up to a week to clear --
        > whereas your everyday account used for smaller purchases (with less money)
        > would only take a few hours. This could all be linked up to services that
        > notified you of your money being moved + made any phone calls needed to
        > verify any larger transfers.
        >
        > The service could also be entrusted with the “cancellation” key which can
        > only be used to move money to your offline fail-safe address. This would be
        > quite an interesting way to mitigate fraud without the user having to be
        > trusted to do anything (except I suppose – not storing their recovery keys
        > online … but this could be partially solved with BIP 32-style “master”
        > public keys + hardware wallets + multi-sig, N factor auth, etc ...)
        >
        > 2. Gambling websites that process a lot of Bitcoins also have a hot wallet
        > which could be better protected by this.
        >
        > 3. Various other e-commerce websites also accept Bitcoins directly. (Deep
        > web markets come to mind -- hey, people breaking the law need good security
        > too.)
        >
        > 4. Provable dead man's switches on the protocol level is another idea --
        > no need to keep special time-locked transactions around and rely on them to
        > be broadcast = more reliable escrow services.
        >
        > 5. And obviously exchange hot (and cold) wallets - enemy number 1.
        >
        > I hope that makes sense. I think I initially managed to confuse a lot of
        > people by talking about revoking transactions / “settlement layers”, etc.
        > But IMO: all of this needs to take place on the blockchain with a new set
        > of OP_CODES and other than the fixed address issue with OP_SPENDTO, I think
        > the general idea would still work.
        >
        >
        > tl; dr, A pseudo-reversal mechanism for transactions would mean that
        > stolen private keys were no longer such an issue. This is desperately
        > needed for exchanges, wallets, and other services that are forced to manage
        > private keys, and whose users (I argue) already expect for this to be
        > possible (or at least will when they're hacked.)
        >
        >
        >
        >
        > On Sat, Aug 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <
        > bitcoin-dev@lists•linuxfoundation.org> wrote:
        >
        >> On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <
        >> bitcoin-dev@lists•linuxfoundation.org> wrote:
        >>
        >>> * reversal of transactions is impossible
        >>>
        >>
        >> I think it would be more accurate to say that the requirement is that
        >> reversal doesn't happen unexpectedly.
        >>
        >> If it is clear in the script that reversal is possible, then obviously
        >> the recipient can take that into consideration.
        >>
        >>
        >>> * keep private keys private and safe. Lose them, it's like losing cash,
        >>> you can just forget about it.
        >>>
        >>
        >> Key management is a thing.  Managing risk by keeping some keys offline is
        >> an important part of that.
        >>
        >>
        >>> * 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.
        >>>
        >>
        >> BitGo has an "instant" system where they promise to only sign one
        >> transaction for a given output.  If you trust BitGo, then this is safe from
        >> double spending, since a double spender can't sign two transactions.
        >>
        >> If BitGo had actually implemented a daily withdrawal limit, then their
        >> system ends up similar to cold storage.  Only 10% of the funds at Bitfinex
        >> could have been withdrawn before manual intervention was required (with
        >> offline keys).
        >>
        >> Who will accept
        >>> such an input and treat it as a payment if it can be reversed during the
        >>> settlement layer?
        >>
        >>
        >> Obviously, if a payment is reversible, then you treat it as a reversible
        >> payment.  The protection here relates to moving coins from the equivalent
        >> of cold storage to hot storage.
        >>
        >> It is OK if it takes longer, since security is more important than
        >> convenience for coins in cold storage.
        >>
        >>
        >>> 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 relates to the reserves held by the exchange.  A portion of the
        >> funds are in hot storage with live keys.  These funds can be stolen by
        >> anyone who gets access to the servers.  The remaining funds are held in
        >> cold storage and they cannot be accessed unless you have the offline keys.
        >> These funds are supposed to be hard to reach and require manual
        >> intervention.
        >>
        >> 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.
        >>>
        >>
        >> Setting up offline keys to act as firebreaks is part of good security
        >> practices.
        >>
        >> _______________________________________________
        >> bitcoin-dev mailing list
        >> bitcoin-dev@lists•linuxfoundation.org
        >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >>
        >>
        >
        > _______________________________________________
        > bitcoin-dev mailing list
        > bitcoin-dev@lists•linuxfoundation.org
        > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
        >
        >
        
        [-- Attachment #2: Type: text/html, Size: 11634 bytes --]
        
        ^ permalink raw reply	[flat|nested] 16+ messages in thread

      • • * Re: [bitcoin-dev] BIP clearing house addresses
            2016-08-07 22:59       ` Erik Aronesty
          @ 2016-08-08  0:48         ` Matthew Roberts
            2016-08-08  9:56           ` Tier Nolan
            2016-08-08 10:09           ` Erik Aronesty
            0 siblings, 2 replies; 16+ messages in thread
          From: Matthew Roberts @ 2016-08-08  0:48 UTC (permalink / raw)
            To: Erik Aronesty; +Cc: Bitcoin Protocol Discussion
          
          [-- Attachment #1: Type: text/plain, Size: 10243 bytes --]
          
          Not everyone who uses centralized exchanges are there to obtain the
          currency though. A large portion are speculators who need to be able to
          enter and exit complex positions in milliseconds and don't care about
          decentralization, security, and often even the asset that they're buying.
          
          Try telling everyone who currently uses Btc-e to go do their margin trading
          over lightning channels, for example. They're not going to want to do that
          because these exchanges are already meeting their needs perfectly well, and
          like I argued before -- it would be very hard to do that as efficiently
          with any other design (there are major drawbacks for traders with a
          decentralized exchange.)
          
          Like it or not, these exchanges play an integral role in the current
          Bitcoin eco-system since they allow us to most efficiently discover price
          and help improve liquidity. A decentralized exchange isn't going to stop
          any more centralized exchanges from being hacked even if they are more
          secure simply because traders don't want to use them.
          
          (Sorry for the duplicate message Erik, I haven't used many mailing lists
          before. I think I have the hang of it now though :) )
          
          On Mon, Aug 8, 2016 at 8:59 AM, Erik Aronesty <erik@q32•com> wrote:
          
          > I still feel like you're better off getting rid of "hot wallets" and use
          > lightning-esqe networks to route orders.  I don't think either speed or
          > flexibility is an issue there.
          >
          > IMO, the point of Bitcoin is to avoid the centralization that seems to be
          > happening on the network now.   By making "hot wallets" more "secure", we
          > encourage things to keep heading downhill with massive centralized
          > crappy-security exchanges.
          >
          > Because, ultimately, there's no security that will prevent an inside
          > job.   And all of these thefts have, in my opinion, been at least partly
          > inside jobs.
          >
          > And centralization is the actually demon that needs slaying here.
          >
          > A client-side library with P2P order routing, tether.to + bitcoin ....
          > and you've got a decentralized exchange... with orders matched to users
          > directly, and channel-trades executed instantly.   And "market makers"
          > running nodes to facilitate routing, etc.
          >
          > No center... nothing to shut down or sue... and no one holds your funds.
          > That's a real Bitcoin exchange.
          >
          >
          >
          > On Sun, Aug 7, 2016 at 1:35 AM, Matthew Roberts via bitcoin-dev <
          > bitcoin-dev@lists•linuxfoundation.org> wrote:
          >
          >> I'm wondering if we're fully on the same page here. What I was thinking
          >> was that this protection mechanism would be applied to the coins in the hot
          >> wallet (I wasn't talking about moving coins from the cold wallet to the hot
          >> wallet -- though such a mechanism is also needed.)
          >>
          >> With the hot wallet you would have an output script that only allowed
          >> coins to be sent to a new transaction whose output script was then only
          >> redeemable after N confirmations (the output is relative time-locked) but
          >> which can also be recovered to a fixed fail-safe address before the
          >> time-lock is reached (exactly like TierNolan already listed only the
          >> time-locked destination shouldn't be completely fixed.) So the private key
          >> for this hot wallet can still sign valid transactions to withdraw coins to
          >> any known destination and these transactions still reach the blockchain.
          >>
          >> The key difference from a regular transaction is that the destination
          >> only has access to the coins -after- the relative time-lock is reached (N
          >> blocks after first confirm) so everyone knows where withdrawals are suppose
          >> to be going and how many coins are being withdrawn at any given time.
          >> Deposits to the hot wallet would therefore need to be encumbered by the
          >> same protection so that from then on this time-lock to redeem coins can be
          >> applied to every new transaction trying to move coins (withdrawn by a user
          >> of the exchange or sent to the cold wallet.)
          >>
          >> Notice we don't care about the destination in the TX script for the hot
          >> wallet because to process user's withdrawals we can't know ahead of time
          >> where they need to be sent (so it isn't possible to use a fixed address
          >> here – though you might want to remove the clearing phase and set a fixed
          >> address for coins sent from the hot wallet to the cold wallet.) The benefit
          >> here comes from being able to see what withdrawals are being cleared,
          >> matching those up to our expectations, and being able to "cancel"
          >> withdrawals if they look suspicious, and you get the benefits for transfers
          >> made from the hot wallet to the cold wallet and visa-versa.
          >>
          >>
          >> This approach is good for a number of crucial services:
          >>
          >> 1. Wallets could be built that grouped coins into different "accounts"
          >> with different time-frames required for clearing / unlocking coins. Your
          >> savings or investment account would say -- take up to a week to clear --
          >> whereas your everyday account used for smaller purchases (with less money)
          >> would only take a few hours. This could all be linked up to services that
          >> notified you of your money being moved + made any phone calls needed to
          >> verify any larger transfers.
          >>
          >> The service could also be entrusted with the “cancellation” key which can
          >> only be used to move money to your offline fail-safe address. This would be
          >> quite an interesting way to mitigate fraud without the user having to be
          >> trusted to do anything (except I suppose – not storing their recovery keys
          >> online … but this could be partially solved with BIP 32-style “master”
          >> public keys + hardware wallets + multi-sig, N factor auth, etc ...)
          >>
          >> 2. Gambling websites that process a lot of Bitcoins also have a hot
          >> wallet which could be better protected by this.
          >>
          >> 3. Various other e-commerce websites also accept Bitcoins directly. (Deep
          >> web markets come to mind -- hey, people breaking the law need good security
          >> too.)
          >>
          >> 4. Provable dead man's switches on the protocol level is another idea --
          >> no need to keep special time-locked transactions around and rely on them to
          >> be broadcast = more reliable escrow services.
          >>
          >> 5. And obviously exchange hot (and cold) wallets - enemy number 1.
          >>
          >> I hope that makes sense. I think I initially managed to confuse a lot of
          >> people by talking about revoking transactions / “settlement layers”, etc.
          >> But IMO: all of this needs to take place on the blockchain with a new set
          >> of OP_CODES and other than the fixed address issue with OP_SPENDTO, I think
          >> the general idea would still work.
          >>
          >>
          >> tl; dr, A pseudo-reversal mechanism for transactions would mean that
          >> stolen private keys were no longer such an issue. This is desperately
          >> needed for exchanges, wallets, and other services that are forced to manage
          >> private keys, and whose users (I argue) already expect for this to be
          >> possible (or at least will when they're hacked.)
          >>
          >>
          >>
          >>
          >> On Sat, Aug 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <
          >> bitcoin-dev@lists•linuxfoundation.org> wrote:
          >>
          >>> On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <
          >>> bitcoin-dev@lists•linuxfoundation.org> wrote:
          >>>
          >>>> * reversal of transactions is impossible
          >>>>
          >>>
          >>> I think it would be more accurate to say that the requirement is that
          >>> reversal doesn't happen unexpectedly.
          >>>
          >>> If it is clear in the script that reversal is possible, then obviously
          >>> the recipient can take that into consideration.
          >>>
          >>>
          >>>> * keep private keys private and safe. Lose them, it's like losing cash,
          >>>> you can just forget about it.
          >>>>
          >>>
          >>> Key management is a thing.  Managing risk by keeping some keys offline
          >>> is an important part of that.
          >>>
          >>>
          >>>> * 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.
          >>>>
          >>>
          >>> BitGo has an "instant" system where they promise to only sign one
          >>> transaction for a given output.  If you trust BitGo, then this is safe from
          >>> double spending, since a double spender can't sign two transactions.
          >>>
          >>> If BitGo had actually implemented a daily withdrawal limit, then their
          >>> system ends up similar to cold storage.  Only 10% of the funds at Bitfinex
          >>> could have been withdrawn before manual intervention was required (with
          >>> offline keys).
          >>>
          >>> Who will accept
          >>>> such an input and treat it as a payment if it can be reversed during the
          >>>> settlement layer?
          >>>
          >>>
          >>> Obviously, if a payment is reversible, then you treat it as a reversible
          >>> payment.  The protection here relates to moving coins from the equivalent
          >>> of cold storage to hot storage.
          >>>
          >>> It is OK if it takes longer, since security is more important than
          >>> convenience for coins in cold storage.
          >>>
          >>>
          >>>> 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 relates to the reserves held by the exchange.  A portion of the
          >>> funds are in hot storage with live keys.  These funds can be stolen by
          >>> anyone who gets access to the servers.  The remaining funds are held in
          >>> cold storage and they cannot be accessed unless you have the offline keys.
          >>> These funds are supposed to be hard to reach and require manual
          >>> intervention.
          >>>
          >>> 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.
          >>>>
          >>>
          >>> Setting up offline keys to act as firebreaks is part of good security
          >>> practices.
          >>>
          >>> _______________________________________________
          >>> bitcoin-dev mailing list
          >>> bitcoin-dev@lists•linuxfoundation.org
          >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          >>>
          >>>
          >>
          >> _______________________________________________
          >> bitcoin-dev mailing list
          >> bitcoin-dev@lists•linuxfoundation.org
          >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
          >>
          >>
          >
          
          [-- Attachment #2: Type: text/html, Size: 13371 bytes --]
          
          ^ permalink raw reply	[flat|nested] 16+ messages in thread

        • • * Re: [bitcoin-dev] BIP clearing house addresses
              2016-08-08  0:48         ` Matthew Roberts
            @ 2016-08-08  9:56           ` Tier Nolan
              2016-08-08 10:09           ` Erik Aronesty
              1 sibling, 0 replies; 16+ messages in thread
            From: Tier Nolan @ 2016-08-08  9:56 UTC (permalink / raw)
              Cc: Bitcoin Protocol Discussion
            
            [-- Attachment #1: Type: text/plain, Size: 1357 bytes --]
            
            On Mon, Aug 8, 2016 at 1:48 AM, Matthew Roberts <matthew@roberts•pm> wrote:
            
            > Not everyone who uses centralized exchanges are there to obtain the
            > currency though. A large portion are speculators who need to be able to
            > enter and exit complex positions in milliseconds and don't care about
            > decentralization, security, and often even the asset that they're buying.
            >
            
            Centralized exchanges also allow for things like limit orders.  You don't
            even have to be logged in and they can execute trades.  This couldn't be
            done with channels.
            
            > Try telling everyone who currently uses Btc-e to go do their margin
            > trading over lightning channels, for example.
            >
            
            Using channels and a centralized exchange gets many of the benefits of a
            distributed exchange.
            
            The channel allows instant funding while allowing the customer to have full
            control over the funds.  The customer could fund the channel and then move
            money to the exchange when needed.
            
            Even margin account holders might like the fact that it is clear which
            funds are under their direct control and which funds are held by the
            exchange.
            
            If they are using bitcoin funds as collateral for a margin trade, then
            inherently the exchange has to have control over those funds.  A 2 of 3
            system where the customer, exchange and a 3rd party arbitration agency
            holds keys might be acceptable to the exchange.
            
            [-- Attachment #2: Type: text/html, Size: 2046 bytes --]
            
            ^ permalink raw reply	[flat|nested] 16+ messages in thread

          • * Re: [bitcoin-dev] BIP clearing house addresses
              2016-08-08  0:48         ` Matthew Roberts
              2016-08-08  9:56           ` Tier Nolan
            @ 2016-08-08 10:09           ` Erik Aronesty
              2016-08-08 11:01             ` Tier Nolan
              1 sibling, 1 reply; 16+ messages in thread
            From: Erik Aronesty @ 2016-08-08 10:09 UTC (permalink / raw)
              To: Matthew Roberts; +Cc: Bitcoin Protocol Discussion
            
            [-- Attachment #1: Type: text/plain, Size: 210 bytes --]
            
            I'm not convinced you need to hold people's funds to provide those
            features. Maybe the millisecond thing.   But 99 out of 100 traders would
            accept a 100 millisecond latency in exchange for 0 counterparty risk.
            
            [-- Attachment #2: Type: text/html, Size: 238 bytes --]
            
            ^ permalink raw reply	[flat|nested] 16+ messages in thread

          • • * Re: [bitcoin-dev] BIP clearing house addresses
                2016-08-08 10:09           ` Erik Aronesty
              @ 2016-08-08 11:01             ` Tier Nolan
                0 siblings, 0 replies; 16+ messages in thread
              From: Tier Nolan @ 2016-08-08 11:01 UTC (permalink / raw)
                Cc: Bitcoin Protocol Discussion
              
              [-- Attachment #1: Type: text/plain, Size: 864 bytes --]
              
              With channels and the exchange acting as hub, you can do instant trades
              between altcoins.
              
              This doesn't work with fiat accounts.  A "100% reserve" company could issue
              fiat tokens.  The exchange could then trade those tokens.
              
              This eliminates the counter-party risk for the exchange.  If the exchange
              dies, you still have your (alt)coins and also fiat tokens.
              
              There is still risk that the token company could go bankrupt though.  This
              could be mitigated by that company requiring only "cashing out" tokens to
              accounts which have been verified.
              
              The company could set up a blockchain where it signed the blocks rather
              than mining and could get money from transaction fees and also minting fees
              (say it charges 1% for minting new tokens)
              
              I wonder what how the law would work for that.  It isn't actually doing
              trading, it is just issuing tokens and redeeming them.
              
              [-- Attachment #2: Type: text/html, Size: 1030 bytes --]
              
              ^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2016-08-08 11:02 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-08-03 18:16 [bitcoin-dev] BIP clearing house addresses Matthew Roberts
2016-08-03 21:13 ` Troy Benjegerdes
2016-08-03 23:55 ` Tier Nolan
2016-08-04  2:07   ` Matthew Roberts
2016-08-04  3:27 ` Luke Dashjr
2016-08-04  3:49   ` Andrew Johnson
2016-08-04  4:53     ` Matthew Roberts
2016-08-04 12:43       ` Erik Aronesty
2016-08-06 10:39 ` s7r
2016-08-06 11:13   ` Tier Nolan
2016-08-07  5:35     ` Matthew Roberts
2016-08-07 22:59       ` Erik Aronesty
2016-08-08  0:48         ` Matthew Roberts
2016-08-08  9:56           ` Tier Nolan
2016-08-08 10:09           ` Erik Aronesty
2016-08-08 11:01             ` Tier Nolan

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox