From: アルム カールヨハン <karl@dglab•com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Simple lock/unlock mechanism
Date: Wed, 28 Feb 2018 03:47:29 +0000 [thread overview]
Message-ID: <CALJw2w4hKCAJY5U7Li82FbHHnXZKjcZ0Cw67V+=WxvknkY=Zxg@mail.gmail.com> (raw)
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.
next reply other threads:[~2018-02-28 3:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-28 3:47 アルム カールヨハン [this message]
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 ` アルム カールヨハン
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CALJw2w4hKCAJY5U7Li82FbHHnXZKjcZ0Cw67V+=WxvknkY=Zxg@mail.gmail.com' \
--to=karl@dglab$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox