diff options
| author | Gavin Andresen <gavinandresen@gmail.com> | 2011-06-22 11:32:49 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2011-06-22 15:32:56 +0000 |
| commit | 09e19b76c354c6c7d36bb9c0e8927e853d900083 (patch) | |
| tree | 8ccc92e81e9c42f3fab99062874810ba7fdb0bf9 | |
| parent | 959965a828e3fd9512af8874ecc270d9fbc67b43 (diff) | |
| download | pi-bitcoindev-09e19b76c354c6c7d36bb9c0e8927e853d900083.tar.gz pi-bitcoindev-09e19b76c354c6c7d36bb9c0e8927e853d900083.zip | |
Re: [Bitcoin-development] [PULL] Add scriptPubKey enforced sendescrow and redeemescrow API calls
| -rw-r--r-- | 1a/26ceefe2fb31c38a3cb235b58f7e794923ebe3 | 117 |
1 files changed, 117 insertions, 0 deletions
diff --git a/1a/26ceefe2fb31c38a3cb235b58f7e794923ebe3 b/1a/26ceefe2fb31c38a3cb235b58f7e794923ebe3 new file mode 100644 index 000000000..5781faa3e --- /dev/null +++ b/1a/26ceefe2fb31c38a3cb235b58f7e794923ebe3 @@ -0,0 +1,117 @@ +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 <gavinandresen@gmail.com>) 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 <bitcoin-development@lists.sourceforge.net>; + 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: <BANLkTinUbJ6CKczHiyX2esMyRWgUrJ_9ASeOqZbRj+23GZgjcQ@mail.gmail.com> +References: <18440.87.106.138.84.1308200020.squirrel@lavabit.com> + <BANLkTi=FTLnU-riNVYssnR9FLdcEeZX7gOS6Zdv1f_XDcJoSSg@mail.gmail.com> + <BANLkTikkBoHBr8z6Uv7oGU_KuT0bvgx3HA@mail.gmail.com> + <BANLkTinUbJ6CKczHiyX2esMyRWgUrJ_9ASeOqZbRj+23GZgjcQ@mail.gmail.com> +Date: Wed, 22 Jun 2011 11:32:49 -0400 +Message-ID: <BANLkTikP-VheXQyXikH6jvaqnWfH_cNjnw@mail.gmail.com> +From: Gavin Andresen <gavinandresen@gmail.com> +To: Mike Hearn <mike@plan99.net> +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 <bitcoin-development@lists.sourceforge.net> +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: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=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/ + + |