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