γ’γ«γ γγ«γΌγ«γ¨γγ³ [ARCHIVE] on Nostr: π
Original date posted:2018-02-28 π Original message:A few p.s.'es: 1. ...
π
Original date posted:2018-02-28
π Original message:A few p.s.'es:
1. Graftroot probably breaks this (someone could just sign the
time-locked output with a script that has no time-lock).
2. Address reuse of discarded privkeys would be a problem. A way to
alleviate might be that freezing includes a send to a new address and
the privkeys for that new one are discarded instead. One extra
transaction, but reduces the risk of accidentally throwing away
`donations4mybook` vanity keys.
-Kalle.
On Wed, Feb 28, 2018 at 3:47 AM, γ’γ«γ γγ«γΌγ«γ¨γγ³ <karl at dglab.com> wrote:
> With the recent trend of physically robbing people for bitcoin (or
> other cryptocurrencies), I thought it would be beneficial to introduce
> a standard for locking up a portion of your bitcoin in a simple
> 'gotta-wait-awhile' system.
>
> The idea is to simply create a transaction spending a set of UTXOs to
> a P2SH address with an OP_CSV attached to it, and then throw away the
> private keys.
>
> To spend the bitcoin, you would have to broadcast the transaction and
> wait the given amount of time, then use the new txout.
>
> There are several ways to shoot yourself in the foot trying to do this
> manually, but e.g. Bitcoin Core could handle this in a fairly
> straightforward manner by introducing two new commands, which I call
> freeze and unfreeze:
>
> bitcoin-cli freeze [amount OR array of txid+vout objects] [days, default 1]
>
> E.g. bitcoin-cli freeze 10 5
> E.g. bitcoin-cli freeze ["abc123:1", "def346:0"] 3
>
> The unfreeze command would by default list all freezes:
>
> bitcoin-cli unfreeze
> txid days status
> bcd123 5 frozen
> dca999 3 frozen
>
> including the txid would broadcast the unfreeze and status would
> become 'thawing' until the amount becomes available:
>
> bitcoin-cli unfreeze bcd123
>
> bitcoin-cli unfreeze
> txid days status
> bcd123 5 thawing
> dca999 3 frozen
>
> The benefit of this is that it becomes physically impossible for you
> to spend the coins until you thaw them, and if this becomes standard
> enough, it should disincentivize potential robbers as it would be
> expected that you keep most of your assets locked up. They could of
> course hold you hostage until the period is over, which may be worse,
> but I think that kind of operation would be substantially more
> difficult than a simply rob-and-run.
>
> The drawback is that you have to broadcast a transaction in order to
> spend the content, and you cannot bump the fee so the transaction
> could get stuck in a high-fee situation.
>
> -Kalle.
Published at
2023-06-07 18:11:01Event JSON
{
"id": "35b3f27abfab3107b870d11378a2ffe3acd8334afaaf3ad90f6e21163c75c76c",
"pubkey": "aeabf351635f1cf3f2c27c21a6c1fd4e17c2373d7404abb9e495fb0d55d6fef7",
"created_at": 1686161461,
"kind": 1,
"tags": [
[
"e",
"a83f2302c7d1b89182a469c73536a0c9bb6649247e40e3d3a1ea2a18ec796afd",
"",
"root"
],
[
"e",
"0d97870eabe46b20d923279bc52f12f63654b85ecca80faa6c0a437a6fdbfcfd",
"",
"reply"
],
[
"p",
"aeabf351635f1cf3f2c27c21a6c1fd4e17c2373d7404abb9e495fb0d55d6fef7"
]
],
"content": "π
Original date posted:2018-02-28\nπ Original message:A few p.s.'es:\n\n1. Graftroot probably breaks this (someone could just sign the\ntime-locked output with a script that has no time-lock).\n\n2. Address reuse of discarded privkeys would be a problem. A way to\nalleviate might be that freezing includes a send to a new address and\nthe privkeys for that new one are discarded instead. One extra\ntransaction, but reduces the risk of accidentally throwing away\n`donations4mybook` vanity keys.\n\n-Kalle.\n\nOn Wed, Feb 28, 2018 at 3:47 AM, γ’γ«γ γγ«γΌγ«γ¨γγ³ \u003ckarl at dglab.com\u003e wrote:\n\u003e With the recent trend of physically robbing people for bitcoin (or\n\u003e other cryptocurrencies), I thought it would be beneficial to introduce\n\u003e a standard for locking up a portion of your bitcoin in a simple\n\u003e 'gotta-wait-awhile' system.\n\u003e\n\u003e The idea is to simply create a transaction spending a set of UTXOs to\n\u003e a P2SH address with an OP_CSV attached to it, and then throw away the\n\u003e private keys.\n\u003e\n\u003e To spend the bitcoin, you would have to broadcast the transaction and\n\u003e wait the given amount of time, then use the new txout.\n\u003e\n\u003e There are several ways to shoot yourself in the foot trying to do this\n\u003e manually, but e.g. Bitcoin Core could handle this in a fairly\n\u003e straightforward manner by introducing two new commands, which I call\n\u003e freeze and unfreeze:\n\u003e\n\u003e bitcoin-cli freeze [amount OR array of txid+vout objects] [days, default 1]\n\u003e\n\u003e E.g. bitcoin-cli freeze 10 5\n\u003e E.g. bitcoin-cli freeze [\"abc123:1\", \"def346:0\"] 3\n\u003e\n\u003e The unfreeze command would by default list all freezes:\n\u003e\n\u003e bitcoin-cli unfreeze\n\u003e txid days status\n\u003e bcd123 5 frozen\n\u003e dca999 3 frozen\n\u003e\n\u003e including the txid would broadcast the unfreeze and status would\n\u003e become 'thawing' until the amount becomes available:\n\u003e\n\u003e bitcoin-cli unfreeze bcd123\n\u003e\n\u003e bitcoin-cli unfreeze\n\u003e txid days status\n\u003e bcd123 5 thawing\n\u003e dca999 3 frozen\n\u003e\n\u003e The benefit of this is that it becomes physically impossible for you\n\u003e to spend the coins until you thaw them, and if this becomes standard\n\u003e enough, it should disincentivize potential robbers as it would be\n\u003e expected that you keep most of your assets locked up. They could of\n\u003e course hold you hostage until the period is over, which may be worse,\n\u003e but I think that kind of operation would be substantially more\n\u003e difficult than a simply rob-and-run.\n\u003e\n\u003e The drawback is that you have to broadcast a transaction in order to\n\u003e spend the content, and you cannot bump the fee so the transaction\n\u003e could get stuck in a high-fee situation.\n\u003e\n\u003e -Kalle.",
"sig": "800365319c518b8c6b36d0557729d6528b1feafa04d2a1f08bc6e3b6725d16c81250c6a0849e37baab81acb8d98f6a834504f9fd61be4106cc52f695ccc95704"
}