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