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
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@ceptacle.com>) id 1ROEoO-0002Gq-4k
for bitcoin-development@lists.sourceforge.net;
Wed, 09 Nov 2011 20:31:56 +0000
X-ACL-Warn:
Received: from backup-server.nordu.net ([193.10.252.66])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1ROEoL-0002AQ-No
for bitcoin-development@lists.sourceforge.net;
Wed, 09 Nov 2011 20:31:56 +0000
Received: from [192.168.0.15] (2508ds5-oebr.0.fullrate.dk [95.166.54.87])
(authenticated bits=0)
by backup-server.nordu.net (8.14.3/8.14.3) with ESMTP id pA9KVirf013443
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO);
Wed, 9 Nov 2011 21:31:46 +0100 (CET)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Michael_Gr=F8nager?= <gronager@ceptacle.com>
In-Reply-To: <CABsx9T3ESoZ21h_V0a8PZAN4MS+KRZ8eVjKc47p9wgJmH0jt-g@mail.gmail.com>
Date: Wed, 9 Nov 2011 21:31:44 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <E390E6EB-BE00-4F96-A4FB-05C39E2036BB@ceptacle.com>
References: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com>
<CABsx9T3T7UZ-G9wsb_NDMBYpnnp9XBnjULmVVDgVXzEaUKn=5w@mail.gmail.com>
<CABsx9T3ESoZ21h_V0a8PZAN4MS+KRZ8eVjKc47p9wgJmH0jt-g@mail.gmail.com>
To: Gavin Andresen <gavinandresen@gmail.com>
X-Mailer: Apple Mail (2.1251.1)
X-Spam-Score: 0.0 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
X-Headers-End: 1ROEoL-0002AQ-No
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] multisig,
op_eval and lock_time/sequence...
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, 09 Nov 2011 20:31:56 -0000
Crossing posts ;)
I like your idea! - It adds a pricetag to distributing a signature - and =
- as you mention it will be part of the standard. It is only up to the =
clients if they want to support it or not, but it does give you 0-conf =
world wide instantaneous anonymously distribution of half-baked =
transactions...
However, the parties will anyway need to know at least about each others =
public keys up front and hence the 0-conf might not be that important... =
Left is, as you said, some anonymity (not much extra though)...
/M
On 09/11/2011, at 21:02, Gavin Andresen wrote:
>> I don't think partially-signed transactions belong on the main =
Bitcoin
>> P2P network, mostly because I don't see any way of preventing =
somebody
>> from endlessly spamming bogus, will-never-be-completed partial
>> transactions just to be annoying.
>=20
> ... of course I write that and then start thinking about ways you
> COULD use the P2P network to distribute signatures, maybe by
> broadcasting (and paying fees for) complete transactions that contain
> extra signatures for the transaction that you want to sign.
>=20
> Here's a half-baked idea that might be brilliant or stupid:
>=20
> + Start with an escrow transaction, with 3 public keys. I own one of =
the keys.
> + I broadcast a 'fee-only' transaction that pays 0 bitcoins to the key
> I own. But I add extra data to the scriptSig; something like:
>=20
> scriptSig: <escrow_signature> <serialized_escrow_transaction> <sig> =
<pubkey>
> scriptPubKey: ...standard DUP HASH160 <pubkeyhash> ...etc
> nValue: 0
>=20
> The other parties to the escrow transaction could monitor the
> block-chain for transactions to my <pubkeyhash>, and get the signature
> and proposed "spend the funds in escrow" transaction from the
> scriptSig.
>=20
> .......
>=20
> "But won't that gunk up the block chain with more data?"
>=20
> Yup. But the parties to the transaction will have to pay for the
> extra data they're including.
>=20
> And everything in the scriptSigs can, theoretically, be forgotten (or
> never sent) to most nodes on the network once the transaction is spent
> and is buried deep enough in the block chain. (a nValue=3D0 =
transaction
> can be considered 'immediately spent').
>=20
> "Can you really put arbitrary stuff in the scriptSig?"
>=20
> Yup. The IsStandard() check today allows up to 200 bytes, which
> wouldn't be enough for an extra signature and <serialized
> transaction>.
>=20
> The standard <sig> <pubkey> is about 150 bytes; part of the
> multi-signature proposal will be increasing that to 500 bytes to
> accomodate 3-signatures transactions. A simple 1-input-1-output
> <serialized transaction> would be around 50 bytes or so.
>=20
> "Wouldn't it be cheaper/better to NOT use the block chain to
> distribute signatures?"
>=20
> Yup. The only advantage I see is it might be more anonymous to use the
> blockchain instead of directly connecting to, and finding out the IP
> address of, the parties involved in the transaction.
>=20
>=20
> --=20
> --
> Gavin Andresen
Michael Gronager, PhD
Owner Ceptacle / NDGF Director, NORDUnet A/S
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 62 14 01
E-mail: gronager@ceptacle.com
|
