* [bitcoin-dev] Simple lock/unlock mechanism
@ 2018-02-28 3:47 アルム カールヨハン
2018-02-28 4:34 ` アルム カールヨハン
0 siblings, 1 reply; 6+ messages in thread
From: アルム カールヨハン @ 2018-02-28 3:47 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Simple lock/unlock mechanism
2018-02-28 3:47 [bitcoin-dev] Simple lock/unlock mechanism アルム カールヨハン
@ 2018-02-28 4:34 ` アルム カールヨハン
2018-02-28 22:30 ` Anthony Towns
0 siblings, 1 reply; 6+ messages in thread
From: アルム カールヨハン @ 2018-02-28 4:34 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
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@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.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Simple lock/unlock mechanism
2018-02-28 4:34 ` アルム カールヨハン
@ 2018-02-28 22:30 ` Anthony Towns
2018-02-28 23:36 ` Adam Back
2018-03-01 5:11 ` アルム カールヨハン
0 siblings, 2 replies; 6+ messages in thread
From: Anthony Towns @ 2018-02-28 22:30 UTC (permalink / raw)
To: アルム カールヨハン,
Bitcoin Protocol Discussion
On Wed, Feb 28, 2018 at 04:34:18AM +0000, アルム カールヨハン via bitcoin-dev wrote:
> 1. Graftroot probably breaks this (someone could just sign the
> time-locked output with a script that has no time-lock).
Making the graftroot key be a 2-of-2 muSig with an independent third party
that commits to only signing CLTV scripts could avoid this. Making it
3-of-3 or 5-of-5 could be even better if you can find multiple independent
services that will do it.
Cheers,
aj
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Simple lock/unlock mechanism
2018-02-28 22:30 ` Anthony Towns
@ 2018-02-28 23:36 ` Adam Back
2018-03-01 5:11 ` アルム カールヨハン
1 sibling, 0 replies; 6+ messages in thread
From: Adam Back @ 2018-02-28 23:36 UTC (permalink / raw)
To: Anthony Towns, Bitcoin Protocol Discussion
Cc: アルム
カールヨハン
Coincidentally I had thought of something similar to what Kalle posted
about a kind of software only time-lock vault, and described the idea
to a few people off-list. Re. Root incompatibility, if the key is
deleted (as it must be) then a delegated signature can not be made
that bypasses the CSV timeout restriction, so Root should not be
incompatible with this. I think it would be disadvantageous to mark
keys as Rootable vs not in a sighash sense, because then that is
another privacy/fungibility loss eroding the uniformity advantage of
Root when the delegate is not used.
One drawback is deleting keys may itself be a bit difficult to assure
with HD wallet seeds setup-time backup model.
As Anthony described I think, a simpler though less robust model would
be to have a third party refuse to co-sign until a pre-arranged time,
and this would have the advantage of not requiring two on-chain
transactions.
With bulletproofs and CT rangeproofs / general ECDL ZKPS there is the
possibility to prove things about the private key, or hidden
attributes of a public key in zero-knowledge. Kind of what we want is
to place private key covenants, where we have to prove that they are
met without disclosing them. For example there is a hidden CSV and it
is met OR there is no hidden CSV so it is not applicable.
Adam
On 28 February 2018 at 23:30, Anthony Towns via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Wed, Feb 28, 2018 at 04:34:18AM +0000, アルム カールヨハン via bitcoin-dev wrote:
>> 1. Graftroot probably breaks this (someone could just sign the
>> time-locked output with a script that has no time-lock).
>
> Making the graftroot key be a 2-of-2 muSig with an independent third party
> that commits to only signing CLTV scripts could avoid this. Making it
> 3-of-3 or 5-of-5 could be even better if you can find multiple independent
> services that will do it.
>
> Cheers,
> aj
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Simple lock/unlock mechanism
2018-02-28 22:30 ` Anthony Towns
2018-02-28 23:36 ` Adam Back
@ 2018-03-01 5:11 ` アルム カールヨハン
2018-03-05 14:53 ` アルム カールヨハン
1 sibling, 1 reply; 6+ messages in thread
From: アルム カールヨハン @ 2018-03-01 5:11 UTC (permalink / raw)
To: Anthony Towns; +Cc: Bitcoin Protocol Discussion
On Wed, Feb 28, 2018 at 10:30 PM, Anthony Towns <aj@erisian•com.au> wrote:
> On Wed, Feb 28, 2018 at 04:34:18AM +0000, アルム カールヨハン via bitcoin-dev wrote:
>> 1. Graftroot probably breaks this (someone could just sign the
>> time-locked output with a script that has no time-lock).
>
> Making the graftroot key be a 2-of-2 muSig with an independent third party
> that commits to only signing CLTV scripts could avoid this. Making it
> 3-of-3 or 5-of-5 could be even better if you can find multiple independent
> services that will do it.
That kind of defeats the purpose. If you go through the trouble of
doing that, you can just do multisig and skip the freezing part
entirely. A robber would have to get you and the cosigner to sign in
both cases, and the CLTV could be overridden with graftroot.
On Wed, Feb 28, 2018 at 11:36 PM, Adam Back <adam.back@gmail•com> wrote:
> Coincidentally I had thought of something similar to what Kalle posted
> about a kind of software only time-lock vault, and described the idea
> to a few people off-list. Re. Root incompatibility, if the key is
> deleted (as it must be) then a delegated signature can not be made
> that bypasses the CSV timeout restriction, so Root should not be
> incompatible with this. I think it would be disadvantageous to mark
> keys as Rootable vs not in a sighash sense, because then that is
> another privacy/fungibility loss eroding the uniformity advantage of
> Root when the delegate is not used.
1. Create TX1=(tx, sig) from UTXO A to p2sh B which has a CSV
timelock. Discard privkey A.
2. After broadcasting TX1, you need privkey B to spend it.
3. Use graftroot and privkey B with a script without timelock to spend B.
The robber can simply force you to execute step 3, since you have the
privkey to B.
> One drawback is deleting keys may itself be a bit difficult to assure
> with HD wallet seeds setup-time backup model.
That's a good point. Even more of a reason to include as part of
'freezing' a send to a new ephemeral key as 'initialization'. Sucks to
pay triple fees though (freeze ephemeral + unfreeze + actual use).
> As Anthony described I think, a simpler though less robust model would
> be to have a third party refuse to co-sign until a pre-arranged time,
> and this would have the advantage of not requiring two on-chain
> transactions.
I was hoping there was a way for a person to simply lock-up the major
portion of their coins easily.
As a sidenote: a security firm (e.g. one that comes to your house when
the alarm goes off) could have a service where seeing an unfreeze
transaction which you have told them about without you giving a heads
up beforehand is equal to alarm going off.
-Kalle.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [bitcoin-dev] Simple lock/unlock mechanism
2018-03-01 5:11 ` アルム カールヨハン
@ 2018-03-05 14:53 ` アルム カールヨハン
0 siblings, 0 replies; 6+ messages in thread
From: アルム カールヨハン @ 2018-03-05 14:53 UTC (permalink / raw)
To: Anthony Towns; +Cc: Bitcoin Protocol Discussion
On Thu, Mar 1, 2018 at 5:11 AM, アルム カールヨハン <karl@dglab•com> wrote:
> That kind of defeats the purpose. If you go through the trouble of
> doing that, you can just do multisig and skip the freezing part
> entirely. A robber would have to get you and the cosigner to sign in
> both cases, and the CLTV could be overridden with graftroot.
I think I'm confused on this. To use graftroot it has to be a pubkey,
not a p2sh thing.
-Kalle.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-03-05 14:53 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-02-28 3:47 [bitcoin-dev] Simple lock/unlock mechanism アルム カールヨハン
2018-02-28 4:34 ` アルム カールヨハン
2018-02-28 22:30 ` Anthony Towns
2018-02-28 23:36 ` Adam Back
2018-03-01 5:11 ` アルム カールヨハン
2018-03-05 14:53 ` アルム カールヨハン
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox