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
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@ceptacle.com>) id 1Rr5fv-00012V-Nt
for bitcoin-development@lists.sourceforge.net;
Sat, 28 Jan 2012 10:38:27 +0000
X-ACL-Warn:
Received: from 2508ds5-oebr.0.fullrate.dk ([95.166.54.49]
helo=mail.ceptacle.com)
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Rr5fu-00007N-6u for bitcoin-development@lists.sourceforge.net;
Sat, 28 Jan 2012 10:38:27 +0000
Received: from localhost (localhost [127.0.0.1])
by mail.ceptacle.com (Postfix) with ESMTP id 0410F15F216B
for <bitcoin-development@lists.sourceforge.net>;
Sat, 28 Jan 2012 11:21:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at ceptacle.com
Received: from mail.ceptacle.com ([127.0.0.1])
by localhost (server.ceptacle.private [127.0.0.1]) (amavisd-new,
port 10024) with ESMTP id AUiKi+TnCHm3
for <bitcoin-development@lists.sourceforge.net>;
Sat, 28 Jan 2012 11:21:20 +0100 (CET)
Received: from [10.0.1.28] (2508ds5-oebr.0.fullrate.dk [95.166.54.49])
by mail.ceptacle.com (Postfix) with ESMTPSA id 388F415F2156
for <bitcoin-development@lists.sourceforge.net>;
Sat, 28 Jan 2012 11:21:20 +0100 (CET)
From: Michael Gronager <gronager@ceptacle.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Sat, 28 Jan 2012 11:21:19 +0100
Message-Id: <B2F57365-3B00-4A0A-B0FC-92B823796F2B@ceptacle.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Mime-Version: 1.0 (Apple Message framework v1251.1)
X-Mailer: Apple Mail (2.1251.1)
X-Spam-Score: 1.6 (+)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
1.6 SUBJ_ALL_CAPS Subject is all capitals
X-Headers-End: 1Rr5fu-00007N-6u
Subject: [Bitcoin-development] BIP-12, 16, 17
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: Sat, 28 Jan 2012 10:38:27 -0000
Dear Bitcoiners,
I have been following some of the debate on the various BIP suggestions =
for enabling e.g. multisignature transactions. ( First a little rant - =
it seems like the discussion takes place in at least 5 different forums =
plus the IRC, this is so annoying. Please keep the discussion at one =
place and refer to this for people asking questions other places - =
including me, now... ).
I have some issues with BIP-16, it is mainly the lines 265-269 in the =
reference implementation =
(https://github.com/gavinandresen/bitcoin-git/blob/pay_to_script_hash/src/=
base58.h):=20
PUBKEY_ADDRESS =3D 0,
SCRIPT_ADDRESS =3D 5,
PUBKEY_ADDRESS_TEST =3D 111,
SCRIPT_ADDRESS_TEST =3D 196,
The purpose of the networkID is broken by this, as it ties additional =
information into an address as a hack. In the BIP-12 implementation I =
argued that this notification on address level is not needed, and should =
not be introduced, I am still of the same opinion. The bitcoin code has =
enough of globals and cross references inside the code s it is today, =
lets not add another one...
If we want more information in a bitcoin address we could just as well =
cannibalize it from the checksum - today it is 4 bytes (1 to 4mia) it =
could be 2 or 3 bytes (1 to 65k or 16M) and that would not break the =
current meaning of the network ID. This would have the same effect - =
that you could not mistake two different addresses and create a =
non-redeemable transaction.
The BIP-17 seems a step forward, but I also agree with Gavins note on =
one on the forums, that it behaves differently in input and output =
scripts. So it obviously need some further work too.
Cheers,
Michael=
|
