{"type":"rich","version":"1.0","author_name":"npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpg","author_url":"https://nostr.ae/npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpg","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2019-08-07\n📝 Original message:Hi,\n\nOne of the biggest problems with the vault scheme (besides all of the\nsetup data that has to be stored for a long time) is an attacker that\nsilently steals the hot wallet private key and waits for the vault's\nowner to make a delayed-spend transaction to initiate a withdrawal\nfrom the vault. If the user was unaware of the theft of the key, then\nthe attacker could steal the funds after the delay period.\n\nTo mitigate this, it is important to choose a stipend or withdrawal\namount per withdrawal period like x% of the funds. This limits the\ntotal stolen funds to x% because once the funds are stolen the user\nwould know their hot key is compromised, and the user would know to\ninstead use one of the other clawback paths during all of the future\nwithdrawal delay periods instead of letting the delay timeout all the\nway to the (stolen) default/hot key.\n\nThe reason why a loss limiter is the way to go is because there's\ncurrently no way (that I am aware of, without an upgrade) to force an\nattacker to reveal his key on the blockchain while also forcing the\nattacker to use a timelock before the key can spend the coins. I am\ncurious about what the smallest least invasive soft-fork would be for\nenabling this kind of timelock. There are so many covenant proposals\nat this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY,\n....). Or there's crazy things like a fork that enables a transaction\nmode where the (timelock...) script of the first output is\nautomatically prefixed to any of the other scripts on any of the other\noutputs when an input tries to spend in the future. A thief could add\nhis key to a new output on the transaction and try to spend (just like\na user would with a fresh/rotated key), but the OP_CSV would be\nautomatically added to his script to implement the public observation\ndelay window.\n\nAlso, there was other previous work that I was only informed about\ntoday after posting my proposal, so I should mention these as related\nwork:\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html\nhttps://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better\nhttps://www.youtube.com/watch?v=diNxp3ZTquo\nhttps://bitcointalk.org/index.php?topic=5111656\n\n- Bryan\nhttp://heybryan.org/"}