summaryrefslogtreecommitdiff
path: root/d1/21308f3fdb3bba31ad90b2b2829d7af70d4ecd
blob: 3e32ad70f55244110914e092b16efd6a65e2156d (plain)
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1RO9NS-0005MW-HS
	for bitcoin-development@lists.sourceforge.net;
	Wed, 09 Nov 2011 14:43:46 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.220.175 as permitted sender)
	client-ip=209.85.220.175; envelope-from=etotheipi@gmail.com;
	helo=mail-vx0-f175.google.com; 
Received: from mail-vx0-f175.google.com ([209.85.220.175])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-MD5:128)
	(Exim 4.76) id 1RO9NO-0007NU-LP
	for bitcoin-development@lists.sourceforge.net;
	Wed, 09 Nov 2011 14:43:46 +0000
Received: by vcbfl17 with SMTP id fl17so1920935vcb.34
	for <bitcoin-development@lists.sourceforge.net>;
	Wed, 09 Nov 2011 06:43:37 -0800 (PST)
Received: by 10.52.34.211 with SMTP id b19mr4844251vdj.112.1320849817242;
	Wed, 09 Nov 2011 06:43:37 -0800 (PST)
Received: from [192.168.1.85] (c-76-111-108-35.hsd1.md.comcast.net.
	[76.111.108.35])
	by mx.google.com with ESMTPS id hn2sm7538481vdb.14.2011.11.09.06.43.34
	(version=SSLv3 cipher=OTHER); Wed, 09 Nov 2011 06:43:36 -0800 (PST)
Message-ID: <4EBA9199.7050201@gmail.com>
Date: Wed, 09 Nov 2011 09:43:37 -0500
From: Alan Reiner <etotheipi@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: bitcoin-development@lists.sourceforge.net
References: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com>
In-Reply-To: <BD206D96-C458-4DD7-92F6-32AE476C259A@ceptacle.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
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 commonly abused enduser mail provider
	(etotheipi[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
X-Headers-End: 1RO9NO-0007NU-LP
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 14:43:46 -0000

That's what my proposal was for, in BIP 0010:

https://github.com/genjix/bips/blob/master/bip-0010.md

However, I just found a minor problem with it that should be addressed 
if we want to enable super-lightweight clients that only sign tx's 
without needing the blockchain.  Simply that the TxIns don't contain the 
value of the TxOuts they are spending, which means the dumb tx-signers 
with no blockchain can't tell how much input there is.  They can only 
see the output values and recipients, which means they can't figure out 
the tx fee, or how much money is in each of the TxIns they are signing.

And most users/clients will have access to the blockchain, so it's not a 
dealbreaker.  But it's something to consider.  Otherwise, I think this 
is a big step towards bringing this complicatedprotocol a little closer 
to Earth...






On 11/09/2011 05:22 AM, Michael Grønager wrote:
> Hi All,
>
> Along with the multisig/op_eval BIPs (11/12) I am considering how the actual client functionality could be.
>
> Some of you might already have the solution for this - if not I would like to propose the following...
>
> Lets consider the 2 of 3 multisig - and lets say I now have some coins hence only redeemable using 2 key signatures. So when I want to spend them I would do:
>
> 1. from client1 I issue a transaction containing one of the signatures, with a locktime e.g. 10 minutes from now and a sequence of 0. This transaction is now posted to the p2p network.
>
> 2. client2 discovers the transaction and that it will affect its wallet. It hence modifies the transaction to includes also the second signature, changes the sequence to 0xFFFFFFFF=final and the lock_time to 0 and retransmits the transaction.
>
> 3. The transaction is now valid and final and will be approved by the miners.
>
> However, for this setup to be possible, we need to reenable the replacement of transaction in the client....
>
> Anyone working on this now ?
>
> Alternatively, the transactions would need to be sent between clients using another protocol...
>
> Cheers,
>
> Michael
>
>
>
> ------------------------------------------------------------------------------
> RSA(R) Conference 2012
> Save $700 by Nov 18
> Register now
> http://p.sf.net/sfu/rsa-sfdev2dev1
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development