summaryrefslogtreecommitdiff
path: root/6e/70157b9ab988b39f0b34ceec00e1a9a9dcb003
blob: dfe7031cc8c9f383e6de3b89b322590396722544 (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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <etotheipi@gmail.com>) id 1RJuue-0007as-Qe
	for bitcoin-development@lists.sourceforge.net;
	Fri, 28 Oct 2011 22:28:32 +0000
Received-SPF: pass (sog-mx-3.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-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1RJuud-0000wi-W0
	for bitcoin-development@lists.sourceforge.net;
	Fri, 28 Oct 2011 22:28:32 +0000
Received: by vcbf1 with SMTP id f1so5715078vcb.34
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 28 Oct 2011 15:28:26 -0700 (PDT)
Received: by 10.220.18.200 with SMTP id x8mr730875vca.125.1319840906402;
	Fri, 28 Oct 2011 15:28:26 -0700 (PDT)
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 bu10sm4243715vdb.3.2011.10.28.15.28.24
	(version=SSLv3 cipher=OTHER); Fri, 28 Oct 2011 15:28:25 -0700 (PDT)
Message-ID: <4EAB2C8E.6040103@gmail.com>
Date: Fri, 28 Oct 2011 18:28:30 -0400
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 Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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: 1RJuud-0000wi-W0
Subject: [Bitcoin-development] Multi-sig tx execution ideas
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: Fri, 28 Oct 2011 22:28:32 -0000

I just posted BIP 0010 to gist : https://gist.github.com/1321518

The goal is to provide a standard method for proposing how to spend 
multi-sig TxOuts, and collect signatures without actually having to 
understand BTC under-the-hood.  I envision, even without any program 
installed, moderately-interested users could figure out this process 
without a third-party.  The addition of an installed program that 
automatically detects .txdp files and intelligently presents the 
information to the users, could bring this functionality to even more 
users.  Perhaps I'm too optimistic, though...

This is, of course, open for discussion/improvement.  I've talked 
briefly with Gavin about this, and he suggested Base64 instead of hex 
for the block-encoding.  I'd lean towards Base58 because developers 
already have it in their codebase.  Also, the separation of fields by 
underscore characters could be changed.  Spaces would make it easier for 
C++ to read them in using stream operators "<<" and ">>".

-Alan