📅 Original date posted:2019-08-07
📝 Original message: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..
On Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev <
bitcoin-dev at 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 at 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 at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190807/881ebc3d/attachment.html>;
Sergio Demian Lerner [ARCHIVE] /
npub1fv…3vq7f
2023-06-07 18:20:06
in reply to nevent1q…tkc9
Author Public Key
npub1fvuxqdqg7klqqgy3yy8gdxjv4phu92sll5y8zqm2qe5qdrhxymhqf3vq7fPublished at
2023-06-07 18:20:06Event JSON
{
"id": "12c204e1a93617050f0f5ec353291d5ab47eb11cf14cda8f63d111a3b24ca6be",
"pubkey": "4b38603408f5be002091210e869a4ca86fc2aa1ffd0871036a0668068ee626ee",
"created_at": 1686162006,
"kind": 1,
"tags": [
[
"e",
"b5bf86cbe856764608f643541819ee58498f1f856faf0b3188f430c12259a46d",
"",
"root"
],
[
"e",
"8471af7d5ddba48485e720baf45e994915af1db6c3e5ad12b4ccdaed1d4ef82b",
"",
"reply"
],
[
"p",
"352b35538b75bcd1384cb298feda615e454419aec1066329c8c3ff3ba18ee794"
]
],
"content": "📅 Original date posted:2019-08-07\n📝 Original message:Seems to be comparable to the proposed \"Tick Method\" from 2013:\nhttps://bitcointalk.org/index.php?topic=307211.msg3308565#msg3308565\n\nHowever I remember that someone told me the tick method had a flaw..\n\n\n\nOn Wed, Aug 7, 2019 at 6:28 PM Dustin Dettmer via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Does revaulting vault up with the same keys, or new ones?\n\u003e\n\u003e Are they new derivation paths on the same key?\n\u003e\n\u003e Would love some expanded explanation on how you’re proposing this would\n\u003e work.\n\u003e\n\u003e Thanks,\n\u003e Dustin\n\u003e\n\u003e On Wed, Aug 7, 2019 at 1:35 PM Bryan Bishop via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Hi,\n\u003e\u003e\n\u003e\u003e One of the biggest problems with the vault scheme (besides all of the\n\u003e\u003e setup data that has to be stored for a long time) is an attacker that\n\u003e\u003e silently steals the hot wallet private key and waits for the vault's\n\u003e\u003e owner to make a delayed-spend transaction to initiate a withdrawal\n\u003e\u003e from the vault. If the user was unaware of the theft of the key, then\n\u003e\u003e the attacker could steal the funds after the delay period.\n\u003e\u003e\n\u003e\u003e To mitigate this, it is important to choose a stipend or withdrawal\n\u003e\u003e amount per withdrawal period like x% of the funds. This limits the\n\u003e\u003e total stolen funds to x% because once the funds are stolen the user\n\u003e\u003e would know their hot key is compromised, and the user would know to\n\u003e\u003e instead use one of the other clawback paths during all of the future\n\u003e\u003e withdrawal delay periods instead of letting the delay timeout all the\n\u003e\u003e way to the (stolen) default/hot key.\n\u003e\u003e\n\u003e\u003e The reason why a loss limiter is the way to go is because there's\n\u003e\u003e currently no way (that I am aware of, without an upgrade) to force an\n\u003e\u003e attacker to reveal his key on the blockchain while also forcing the\n\u003e\u003e attacker to use a timelock before the key can spend the coins. I am\n\u003e\u003e curious about what the smallest least invasive soft-fork would be for\n\u003e\u003e enabling this kind of timelock. There are so many covenant proposals\n\u003e\u003e at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY,\n\u003e\u003e ....). Or there's crazy things like a fork that enables a transaction\n\u003e\u003e mode where the (timelock...) script of the first output is\n\u003e\u003e automatically prefixed to any of the other scripts on any of the other\n\u003e\u003e outputs when an input tries to spend in the future. A thief could add\n\u003e\u003e his key to a new output on the transaction and try to spend (just like\n\u003e\u003e a user would with a fresh/rotated key), but the OP_CSV would be\n\u003e\u003e automatically added to his script to implement the public observation\n\u003e\u003e delay window.\n\u003e\u003e\n\u003e\u003e Also, there was other previous work that I was only informed about\n\u003e\u003e today after posting my proposal, so I should mention these as related\n\u003e\u003e work:\n\u003e\u003e\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html\n\u003e\u003e\n\u003e\u003e https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better\n\u003e\u003e https://www.youtube.com/watch?v=diNxp3ZTquo\n\u003e\u003e https://bitcointalk.org/index.php?topic=5111656\n\u003e\u003e\n\u003e\u003e - Bryan\n\u003e\u003e http://heybryan.org/\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 _______________________________________________\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/20190807/881ebc3d/attachment.html\u003e",
"sig": "a4adcf935360b2ca07d90acf8959e647a28024a6a8db2f200e6d03f1d3d3226d80fc3c484c3b2093c2136d1ba7e0ef4860fb8d00f46b64660e3bf30e6eab49c6"
}