From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1QZPQG-00059X-Cv for bitcoin-development@lists.sourceforge.net; Wed, 22 Jun 2011 15:32:56 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.175 as permitted sender) client-ip=74.125.83.175; envelope-from=gavinandresen@gmail.com; helo=mail-pv0-f175.google.com; Received: from mail-pv0-f175.google.com ([74.125.83.175]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1QZPQF-0003no-G0 for bitcoin-development@lists.sourceforge.net; Wed, 22 Jun 2011 15:32:56 +0000 Received: by pvf24 with SMTP id 24so793678pvf.34 for ; Wed, 22 Jun 2011 08:32:49 -0700 (PDT) MIME-Version: 1.0 Received: by 10.142.49.15 with SMTP id w15mr173700wfw.328.1308756769411; Wed, 22 Jun 2011 08:32:49 -0700 (PDT) Received: by 10.142.153.7 with HTTP; Wed, 22 Jun 2011 08:32:49 -0700 (PDT) In-Reply-To: References: <18440.87.106.138.84.1308200020.squirrel@lavabit.com> Date: Wed, 22 Jun 2011 11:32:49 -0400 Message-ID: From: Gavin Andresen To: Mike Hearn Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.6 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is freemail (gavinandresen[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.0 RFC_ABUSE_POST Both abuse and postmaster missing on sender domain 0.0 AWL AWL: From: address is in the auto white-list X-Headers-End: 1QZPQF-0003no-G0 Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] [PULL] Add scriptPubKey enforced sendescrow and redeemescrow API calls X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:32:56 -0000 ... >> I think all of these could use a new type of bitcoin payment address; >> it might make sense for THAT to be generic, maybe containing: >> =A0version byte >> =A0m >> =A0n >> =A0hash of xor of all n public keys >> =A0checksum > > I don't understand what this is for. For triggering such a transaction > via the UI, I think establishing a higher level protocol would be > needed. It's a separate step. You're right, it doesn't make sense. The use case I would like to work is: I setup an escrow that requires m of n signatures to release funds, securely getting public keys from the other n-1 parties. Now we all need to fund the escrow. Or maybe other people can fund the escrow (it just takes m of n of us to decide when/how/where to spend the funds). It would be spiffy to publish a new type of bitcoin address that is an "m of n address", that anybody could pay into, but would require m of n signatures to spend. Publishing a really really long address with all n public keys would work. It would be great if the "higher level protocol" for pay-to-escrow was just get a bitcoin address via https (or other secure mechanism), like we do now for pay-to-single-party. Where the person you're paying has their own mechanisms for generating or fetching/authenticating the public keys, and knows which bitcoin addresses they've published. All of which makes me wonder if the straightforward "n PUBKEYS m CHECKMULTISIG" transaction type is the right thing to do. Following the pattern of our standard DUP HASH160 etc. transaction type, maybe 2 of 2 and 2 of three should be: 2DUP ADD HASH160 ...hash(pubkey1+2)... EQUALVERIFY 2 2 ROLL CHECKMULTISIGVE= RIFY 3DUP ADD ADD HASH160 ...hash(pubkey1+2+3)... EQUALVERIFY 2 3 ROLL CHECKMULTISIGVERIFY Spending those transactions would mean putting the m signatures and the n public keys in the TxIn, but sending funds you'd only need the hash of the sum of the public keys. --=20 -- Gavin Andresen http://clearcoin.com/