{"type":"rich","version":"1.0","author_name":"npub1lf5jdpupmcelz945y09tzawew6pqs5wkkp6dppeujgxxnqltgufsmzuul6","author_url":"https://nostr.ae/npub1lf5jdpupmcelz945y09tzawew6pqs5wkkp6dppeujgxxnqltgufsmzuul6","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2016-08-04\n📝 Original message:\"This is already possible. Just nLockTime your withdrawls for some future\nblock. Don't sign any transaction that isn't nLockTime'd at least N blocks\nbeyond the present tip.\"\n\nThis would have prevented the Bitfinex hack if BitGo did this, but it\nwouldn't have helped if the Bitfinex offline key had been compromised\ninstead of BitGo doing the 2nd sig.  In the BFX hack the TXNs were signed\nby Bitfinex's hot key and BitGo's key, they required 2 of 2.\n\nIf I'm understanding correctly, what Matthew is proposing is a new type of\nUTXO that is only valid to be spent as an nLockTime transaction and can be\nreversed by some sort of RBF-type transaction within that time period, I\nbelieve.\n\nBut I don't think this will work. What do you do if the keys are\ncompromised?  What's to stop the attacker from locking the coins up\nindefinitely by repeatedly broadcasting a refund transaction each time you\ntry to spend to an uncompromised address?\n\nYou'd need a third distinct key required for the refund TXN that's separate\nfrom the keys used to sign the initial nLockTime TXN.  And the refund TXN\nwould need to be able to go to a new address entirely.\n\nOn Aug 3, 2016 11:28 PM, \"Luke Dashjr via bitcoin-dev\" \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e On Wednesday, August 03, 2016 6:16:20 PM Matthew Roberts via bitcoin-dev\n\u003e wrote:\n\u003e \u003e In light of the recent hack: what does everyone think of the idea of\n\u003e \u003e creating a new address type that has a reversal key and settlement layer\n\u003e \u003e that can be used to revoke transactions?\n\u003e\n\u003e This isn't something that makes sense at the address, since it represents\n\u003e the\n\u003e recipient and not the sender. Transactions are not sent from addresses\n\u003e ever.\n\u003e\n\u003e \u003e You could specify so that transactions \"sent\" from these addresses must\n\u003e \u003e receive N confirmations before they can't be revoked, after which the\n\u003e \u003e transaction is \"settled\" and the coins become redeemable from their\n\u003e \u003e destination output. A settlement phase would also mean that a\n\u003e transaction's\n\u003e \u003e progress was publicly visible so transparent fraud prevention and\n\u003e auditing\n\u003e \u003e would become possible by anyone.\n\u003e\n\u003e This is already possible. Just nLockTime your withdrawls for some future\n\u003e block. Don't sign any transaction that isn't nLockTime'd at least N blocks\n\u003e beyond the present tip.\n\u003e\n\u003e Luke\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160803/c004566c/attachment.html\u003e"}