bgroff at lavabit.com [ARCHIVE] on Nostr: 📅 Original date posted:2011-08-24 🗒️ Summary of this message: Gavin Andresen ...
📅 Original date posted:2011-08-24
🗒️ Summary of this message: Gavin Andresen proposes multi-signature transactions as the fastest path to secure Bitcoin wallets, with a draft proposal for standard transactions and new Bitcoin addresses.
📝 Original message:"Gavin Andresen" <gavinandresen at gmail.com> wrote:
> It seems to me the fastest path to very secure, very-hard-to-lose
> bitcoin wallets is multi-signature transactions.
>
> To organize this discussion: first, does everybody agree?
I agree. For example, a corporate wallet can require threshold signatures
to disburse. Or for personal use you can have a couple of additional
keys, one stored on a secure device for confirmation and one offline as
emergency backup if you lose your secure device.
...
> I've been trying to get consensus on low-level 'standard' transactions
> for transactions that must be signed by 2 or 3 keys; current draft
> proposal is here:
> https://gist.github.com/39158239e36f6af69d6f
> and discussion on the forums here:
> https://bitcointalk.org/index.php?topic=38928.0
> ... and there is a pull request that is relevant here:
> https://github.com/bitcoin/bitcoin/pull/319
For context - I am the author of the latter.
> I still think it is a good idea to enable a set of new 'standard'
> multisignature transactions, so they get relayed and included into
> blocks. I don't want to let "the perfect become the enemy of the
> good" -- does anybody disagree?
>
> The arguments against are that if the proposed standard transactions
> are accepted, then the next step is to define a new kind of bitcoin
> address that lets coins be deposited into a multisignature-protected
> wallet.
>
> And those new as-yet-undefined bitcoin addresses will have to be 2 or
> 3 times as big as current bitcoin addresses, and will be incompatible
> with old clients.
Incompatible at the UI level, but not at the block chain level. Changing
the block chain rules will be quite an undertaking. You will have to set
a block number for the rule change a few months in advance and will have
to get agreement from the pools. I think it is important to increase
trust in the bitcoin ecosystem sooner than that. The current flat
exchange rate and difficulty may be a signal that people are getting risk
averse.
> So, if we are going to have new releases that are incompatible with
> old clients why not do things right in the first place, implement or
> enable opcodes so the new bitcoin addresses can be small, and schedule
> a block chain split for N months from now.
>
> My biggest worry is we'll say "Sure, it'll only take a couple days to
> agree on how to do it right" and six months from now there is still no
> consensus on exactly which digest function should be used, or whether
> or not there should be a new opcode for arbitrary boolean expressions
> involving keypairs. And people's wallets continue to get lost or
> stolen.
That is my worry too. We already have working code for this (pull 319),
and the addresses are not so long as to be unusable. I hope we can move
forward on the existing code and in parallel move forward on block chain
rule proposals at an agreed upon block number.
--
Bobby Groff
🗒️ Summary of this message: Gavin Andresen proposes multi-signature transactions as the fastest path to secure Bitcoin wallets, with a draft proposal for standard transactions and new Bitcoin addresses.
📝 Original message:"Gavin Andresen" <gavinandresen at gmail.com> wrote:
> It seems to me the fastest path to very secure, very-hard-to-lose
> bitcoin wallets is multi-signature transactions.
>
> To organize this discussion: first, does everybody agree?
I agree. For example, a corporate wallet can require threshold signatures
to disburse. Or for personal use you can have a couple of additional
keys, one stored on a secure device for confirmation and one offline as
emergency backup if you lose your secure device.
...
> I've been trying to get consensus on low-level 'standard' transactions
> for transactions that must be signed by 2 or 3 keys; current draft
> proposal is here:
> https://gist.github.com/39158239e36f6af69d6f
> and discussion on the forums here:
> https://bitcointalk.org/index.php?topic=38928.0
> ... and there is a pull request that is relevant here:
> https://github.com/bitcoin/bitcoin/pull/319
For context - I am the author of the latter.
> I still think it is a good idea to enable a set of new 'standard'
> multisignature transactions, so they get relayed and included into
> blocks. I don't want to let "the perfect become the enemy of the
> good" -- does anybody disagree?
>
> The arguments against are that if the proposed standard transactions
> are accepted, then the next step is to define a new kind of bitcoin
> address that lets coins be deposited into a multisignature-protected
> wallet.
>
> And those new as-yet-undefined bitcoin addresses will have to be 2 or
> 3 times as big as current bitcoin addresses, and will be incompatible
> with old clients.
Incompatible at the UI level, but not at the block chain level. Changing
the block chain rules will be quite an undertaking. You will have to set
a block number for the rule change a few months in advance and will have
to get agreement from the pools. I think it is important to increase
trust in the bitcoin ecosystem sooner than that. The current flat
exchange rate and difficulty may be a signal that people are getting risk
averse.
> So, if we are going to have new releases that are incompatible with
> old clients why not do things right in the first place, implement or
> enable opcodes so the new bitcoin addresses can be small, and schedule
> a block chain split for N months from now.
>
> My biggest worry is we'll say "Sure, it'll only take a couple days to
> agree on how to do it right" and six months from now there is still no
> consensus on exactly which digest function should be used, or whether
> or not there should be a new opcode for arbitrary boolean expressions
> involving keypairs. And people's wallets continue to get lost or
> stolen.
That is my worry too. We already have working code for this (pull 319),
and the addresses are not so long as to be unusable. I hope we can move
forward on the existing code and in parallel move forward on block chain
rule proposals at an agreed upon block number.
--
Bobby Groff