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
|
Return-Path: <jrn@jrn.me.uk>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 619C33EE
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 19:19:39 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from homiemail-a10.g.dreamhost.com (homie.mail.dreamhost.com
[208.97.132.208])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id D656F12A
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 10 Aug 2015 19:19:38 +0000 (UTC)
Received: from homiemail-a10.g.dreamhost.com (localhost [127.0.0.1])
by homiemail-a10.g.dreamhost.com (Postfix) with ESMTP id 78C71280073;
Mon, 10 Aug 2015 12:19:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jrn.me.uk; h=subject:to
:references:cc:from:message-id:date:mime-version:in-reply-to
:content-type:content-transfer-encoding; s=jrn.me.uk; bh=+fP2ZmV
pjxyYV81hQT3qBCjqgLY=; b=Q9JV8LH1fqOYLLhWU0g5yE8LguLpQuc0S95ebVT
i/CBGvwFhBecAErMfnuhnNQFkqNcRkFsjygO6vqnYbooklwincSctuXuOQiTthzQ
8OwaOig7S/Dsnfftnqj3/ZIC4COqbzKmyLMxWIr7hCG0lG6AftDL80bxqgGj49SP
E2Y0=
Received: from [10.9.1.131] (unknown [89.238.129.18])
(using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits))
(No client certificate requested)
(Authenticated sender: jrn@jrn.me.uk)
by homiemail-a10.g.dreamhost.com (Postfix) with ESMTPSA id 89DAE280076;
Mon, 10 Aug 2015 12:19:37 -0700 (PDT)
To: Luke Dashjr <luke@dashjr.org>
References: <55C75FC8.6070807@jrn.me.uk> <201508092346.20301.luke@dashjr.org>
<55C8EE2A.3030309@jrn.me.uk> <201508101841.00173.luke@dashjr.org>
From: Ross Nicoll <jrn@jrn.me.uk>
Message-ID: <55C8F948.3070705@jrn.me.uk>
Date: Mon, 10 Aug 2015 20:19:36 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101
Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <201508101841.00173.luke@dashjr.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Alternative chain support for payment protocol
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Aug 2015 19:19:39 -0000
Trimmed some of the thread to clarity
On 10/08/2015 19:40, Luke Dashjr wrote:
>>>> I propose adding a new optional "genesis" field as a 16 byte sequence
>>>> containing the SHA-256 hash of the genesis block of the network the
>>>> request belongs to, uniquely identifying chains without any requirement
>>>> for a central registry.
>>> Genesis blocks are not necessarily unique. For example, Litecoin and
>>> Feathercoin share the same one.
>> Had missed that, and there's no easy alternatives. BIP 44 chain IDs
>> don't identify different testnets, and do not cover regtest at all.
> Regtest isn't really a network at all, just a testing mode of Bitcoin Core...
True, but as Jorge points out, it's generally better not to have special
cases.
>> Most recent block hash could be used and also provides fork
>> detection, but in doing so advertises if a merchant is on the wrong
>> fork. Will think about it.
> Is that a bad thing?
It was something I was thinking about with the BIP 66 fork, that it
could be used as a safety measure, but could also be used to find
merchants & exchanges who are accepting coins on the wrong branch of a
fork (and therefore are susceptible to double-spend attacks). For fork
detection it's probably safer for the client to provide a recent block
hash with the payment response.
I think genesis hash collisions are probably acceptable; or, the
duplicate coins are so far rarely long-lived and it's therefore not a
major concern at least. The server should reject any attempt to pay on
the wrong chain, in hindsight, as it will try to relay on the network it
expects and the transaction will be rejected.
>>> I'd appreciate initial feedback on the idea, and if there's no major
>>> objections I'll raise this as a BIP.
>> I don't see how this is related to improving Bitcoin...
>>
>> Well, mostly I'm trying not to avoid the situation where any accidental
>> mixing of files is dangerous (funds can easily be sent on the wrong
>> blockchain), nor with multiple standards (which is where we are at the
>> moment). It improves things in avoiding future problems, rather than in
>> the immediate term.
> Sorry, I meant to stress that BIPs are for *Bitcoin* improvements
> specifically. Things which only improve altcoins, while a perfectly fine thing
> to standardise, are outside the scope of what belongs in a BIP.
>
> Perhaps, however, this could be made to kill 2 birds with one stone, by
> ensuring it addresses the need for payments made of bitcoins on a sidechain?
> For this, a merchant who wants a sidechain payment would presumably be able to
> provide a script from the main chain already, but an extension allowing
> payment directly on the sidechain (at the customer's choice) avoids the need
> to round-trip it...
That could definitely be done, for example by making the genesis field
"repeated", so it specifies all potential networks. The response would
need to indicate which hash it used, but that could be chain tip (with
height in a further field), and provide fork detection.
Ross
|
