From: Christian Decker <decker.christian@gmail•com>
To: Gavin Andresen <gavinandresen@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split?
Date: Wed, 24 Aug 2011 21:05:42 +0200 [thread overview]
Message-ID: <CALxbBHXAcRse9YE-evKNmDut684vjkUMHkbx+8E+aTNT5wMg5A@mail.gmail.com> (raw)
In-Reply-To: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3802 bytes --]
Sorry for keeping this short but I'm in holiday and reading/writing on my
phone is a pain.
On Aug 24, 2011 4:12 PM, "Gavin Andresen" <gavinandresen@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?
It's a great way for companies to secure their assets.
>
> ByteCoin pointed to a research paper that gives a scheme for splitting
> a private key between two people, neither of which every knows the
> full key, but, together, both can DSA-sign transactions. That's very
> cool, but it involves high-end cutting-edge crypto like zero-knowledge
> proofs that I know very little about (are implementations available?
> are they patented? have they been thoroughly vetted/tested? etc).
> So I'm assuming that is NOT the fastest way to solving the problem.
>
> If anybody has some open-source, patent-free, thoroughly-tested code
> that already does DSA-key-splitting, speak up please.
Since. we have the possibility o add other signature schemes to the protocol
we could add an rsa-like scheme which allows m-out-of-n signatures. It works
by distributing shares of the key which are points on a curve having the
actual key as 0-value. It does not require special length for the key so if
ecdsa allows something similar there need not be anything changed.
>
> 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
>
>
> 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?
Would be a first step.
>
> 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.
>
> 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.
>
>
Just wanted to point you in that alternative direction as it would possibly
keep backward compatibility and allow multisignature.
Regards,
Chris
>
> --
> --
> Gavin Andresen
>
>
------------------------------------------------------------------------------
> EMC VNX: the world's simplest storage, starting under $10K
> The only unified storage solution that offers unified management
> Up to 160% more powerful than alternatives and 25% more efficient.
> Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[-- Attachment #2: Type: text/html, Size: 4916 bytes --]
next prev parent reply other threads:[~2011-08-24 19:05 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-24 15:12 Gavin Andresen
2011-08-24 15:17 ` Rick Wesson
2011-08-24 15:45 ` Gregory Maxwell
2011-08-24 15:55 ` Rick Wesson
2011-08-24 16:05 ` Douglas Huff
2011-08-24 16:15 ` Luke-Jr
2011-08-24 16:46 ` Gregory Maxwell
2011-08-24 17:03 ` Luke-Jr
2011-08-24 17:07 ` Rick Wesson
2011-08-24 17:19 ` Gregory Maxwell
2011-08-24 17:40 ` Rick Wesson
2011-08-24 17:57 ` Gavin Andresen
2011-08-24 18:45 ` Jeff Garzik
2011-08-25 7:39 ` Michael Grønager
2011-08-25 17:18 ` Gavin Andresen
2011-08-26 10:50 ` Mike Hearn
2011-08-27 1:36 ` bgroff
2011-08-25 18:31 ` Gregory Maxwell
[not found] ` <20110825201026.GA21380@ulyssis.org>
2011-08-25 20:29 ` Gregory Maxwell
2011-08-25 21:06 ` Pieter Wuille
2011-08-24 17:03 ` theymos
2011-08-24 17:47 ` bgroff
2011-08-24 19:05 ` Christian Decker [this message]
2011-08-24 20:29 ` Gregory Maxwell
2011-08-24 22:27 ` Douglas Huff
2011-08-25 21:30 ` Christian Decker
2011-08-26 11:42 ` Mike Hearn
2011-08-26 19:44 ` Gavin Andresen
2011-08-27 1:15 ` bgroff
2011-08-24 16:18 Pieter Wuille
2011-08-24 16:26 ` Luke-Jr
2011-08-25 20:14 Pieter Wuille
2011-08-26 11:09 ` Mike Hearn
2011-08-26 21:30 ` Pieter Wuille
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=CALxbBHXAcRse9YE-evKNmDut684vjkUMHkbx+8E+aTNT5wMg5A@mail.gmail.com \
--to=decker.christian@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=gavinandresen@gmail$(echo .)com \
/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