1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
|
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 <mith@jrbobdobbs.org>) id 1QwFwz-0000bT-69
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Aug 2011 16:05:09 +0000
X-ACL-Warn:
Received: from mail-ww0-f53.google.com ([74.125.82.53])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1QwFwy-00086X-CI
for bitcoin-development@lists.sourceforge.net;
Wed, 24 Aug 2011 16:05:09 +0000
Received: by wwf25 with SMTP id 25so1300966wwf.10
for <bitcoin-development@lists.sourceforge.net>;
Wed, 24 Aug 2011 09:05:02 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.227.59.71 with SMTP id k7mr421824wbh.1.1314201902138; Wed, 24
Aug 2011 09:05:02 -0700 (PDT)
Sender: mith@jrbobdobbs.org
Received: by 10.227.58.207 with HTTP; Wed, 24 Aug 2011 09:05:02 -0700 (PDT)
Received: by 10.227.58.207 with HTTP; Wed, 24 Aug 2011 09:05:02 -0700 (PDT)
In-Reply-To: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
References: <CABsx9T1uw43JuvhEmJP0KCyojsDi1r7v6BaLBHz7wWazduE5iw@mail.gmail.com>
Date: Wed, 24 Aug 2011 11:05:02 -0500
X-Google-Sender-Auth: Pfp8kulXDYhyj8LNQ6gdjfcl7bA
Message-ID: <CAPiTikUi7vN-Z_7i0rYUAHbdiPnwAgpZZOLLCb1z3pjV733DTw@mail.gmail.com>
From: Douglas Huff <dhuff@jrbobdobbs.org>
To: Gavin Andresen <gavinandresen@gmail.com>
Content-Type: multipart/alternative; boundary=20cf30025e9a8a43df04ab427992
X-Spam-Score: 0.9 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1QwFwy-00086X-CI
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New standard transaction types: time to
schedule a blockchain split?
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, 24 Aug 2011 16:05:09 -0000
--20cf30025e9a8a43df04ab427992
Content-Type: text/plain; charset=ISO-8859-1
On Aug 24, 2011 10:12 AM, "Gavin Andresen" <gavinandresen@gmail.com> wrote:
>
> If anybody has some open-source, patent-free, thoroughly-tested code
> that already does DSA-key-splitting, speak up please.
>
If the caveat of a trusted third party is acceptable and, as greg mentioned,
if there was a way to export unsigned transactions and then import/broadcast
after signing this becomes fairly trivial.
Shamir's + 3rd party to combine and sign means no protocol level changes.
Process could work something like this:
Parties agree to endpoint destination address and provide it to third party.
Third party generates key and provides shares to each party in the txn and
the resulting address to both as well.
Third party destroys (preferably, never stores) private key.
Sender sends to address.
Both parties after confirmation of reciept of goods or what have you provide
shares back to third party who uses the privkey to xfer inputs to the
previously agreed upon destination subtracting their fee.
This resembles more traditional escrow setups and relies on the trust of a
third party, which is not ideal, but would be fairly simple to implement
until the other proposals could be better investigated and implemented.
--20cf30025e9a8a43df04ab427992
Content-Type: text/html; charset=ISO-8859-1
<p><br>
On Aug 24, 2011 10:12 AM, "Gavin Andresen" <<a href="mailto:gavinandresen@gmail.com">gavinandresen@gmail.com</a>> wrote:<br>
><br>
> If anybody has some open-source, patent-free, thoroughly-tested code<br>
> that already does DSA-key-splitting, speak up please.<br>
></p>
<p>If the caveat of a trusted third party is acceptable and, as greg mentioned, if there was a way to export unsigned transactions and then import/broadcast after signing this becomes fairly trivial.</p>
<p>Shamir's + 3rd party to combine and sign means no protocol level changes.</p>
<p>Process could work something like this:</p>
<p>Parties agree to endpoint destination address and provide it to third party.<br>
Third party generates key and provides shares to each party in the txn and the resulting address to both as well.<br>
Third party destroys (preferably, never stores) private key.<br>
Sender sends to address.<br>
Both parties after confirmation of reciept of goods or what have you provide shares back to third party who uses the privkey to xfer inputs to the previously agreed upon destination subtracting their fee.</p>
<p>This resembles more traditional escrow setups and relies on the trust of a third party, which is not ideal, but would be fairly simple to implement until the other proposals could be better investigated and implemented.</p>
--20cf30025e9a8a43df04ab427992--
|
