Good morning Sergio,
Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Thursday, August 8, 2019 10:09 AM, Sergio Demian Lerner via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > Seems to be comparable to the proposed "Tick Method" from 2013: > https://bitcointalk.org/index.php?topic=307211.msg3308565#msg3308565 > > However I remember that someone told me the tick method had a flaw.. Maybe the use of `SIGHASH_NONE` for both inputs of the TxOut transactions? Also txid malleability. The first can be fixed by not using `SIGHASH_NONE` for one of the inputs and requiring a hot privkey to sign with that. The second can be fixed by using SegWit outputs. Regards, ZmnSCPxj > > > On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > > Does revaulting vault up with the same keys, or new ones? > > > > Are they new derivation paths on the same key? > > > > Would love some expanded explanation on how you’re proposing this would > > work. > > > > Thanks, > > Dustin > > > > On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev > > <bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > Hi, > > > > > > One of the biggest problems with the vault scheme (besides all of the > > > setup data that has to be stored for a long time) is an attacker that > > > silently steals the hot wallet private key and waits for the vault's > > > owner to make a delayed-spend transaction to initiate a withdrawal > > > from the vault. If the user was unaware of the theft of the key, then > > > the attacker could steal the funds after the delay period. > > > > > > To mitigate this, it is important to choose a stipend or withdrawal > > > amount per withdrawal period like x% of the funds. This limits the > > > total stolen funds to x% because once the funds are stolen the user > > > would know their hot key is compromised, and the user would know to > > > instead use one of the other clawback paths during all of the future > > > withdrawal delay periods instead of letting the delay timeout all the > > > way to the (stolen) default/hot key. > > > > > > The reason why a loss limiter is the way to go is because there's > > > currently no way (that I am aware of, without an upgrade) to force an > > > attacker to reveal his key on the blockchain while also forcing the > > > attacker to use a timelock before the key can spend the coins. I am > > > curious about what the smallest least invasive soft-fork would be for > > > enabling this kind of timelock. There are so many covenant proposals > > > at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY, > > > ....). Or there's crazy things like a fork that enables a transaction > > > mode where the (timelock...) script of the first output is > > > automatically prefixed to any of the other scripts on any of the other > > > outputs when an input tries to spend in the future. A thief could add > > > his key to a new output on the transaction and try to spend (just like > > > a user would with a fresh/rotated key), but the OP_CSV would be > > > automatically added to his script to implement the public observation > > > delay window. > > > > > > Also, there was other previous work that I was only informed about > > > today after posting my proposal, so I should mention these as related > > > work: > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html > > > https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better > > > https://www.youtube.com/watch?v=diNxp3ZTquo > > > https://bitcointalk.org/index.php?topic=5111656 > > > > > > - Bryan > > > http://heybryan.org/ > > > _______________________________________________ > > > 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 _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
