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