Alternative chain support for payment protocol
13 messages, 9 to 10 Aug 2015. Started by Ross Nicoll.
Jorge Timón (4), Ross Nicoll (3), Mike Hearn (2), Mark F, John L. Jegutanis, Odinn Cyberguerrilla, Luke Dashjr
BIP 70 currently lists two networks, main and test (inferred as testnet3) for payment protocol requests. This means that different testnets cannot be supported trivially, and the protocol cannot be used for alternative coins (or, lacks context to indicate which coin the request applies to, which is particularly dangerous in cases where coins share address prefixes).
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. For backwards compatibility, the "network" field would contain "main" for Bitcoin main net, "test" for Bitcoin testnet3, and "other" for other networks apart from those two.
I'd appreciate initial feedback on the idea, and if there's no major objections I'll raise this as a BIP.
Ross
Quoted text (4 lines)
> > I'd appreciate initial feedback on the idea, and if there's no major > objections I'll raise this as a BIP. >
The reason BIP 70 doesn't do this is the assumption that alt coins are ... well .... alt. They can vary in arbitrary ways from Bitcoin, and so things in BIP70 that work for Bitcoin may or may not work for other coins.
If your alt coin is close enough to BIP 70 that you can reuse it "as is" then IMO we should just define a new network string for your alt. network = "dogecoin-main" or whatever.
You could also use the genesis hash as the network name. That works too. But it's less clear and would involve lookups to figure out what the request is for, if you find such a request in the wild. I don't care much either way.
A sha256 hash is 32 bytes, but otherwise I agree with this proposal. Genesis block hash is the logical way to identify chains, moving forward. On Aug 9, 2015 7:12 AM, "Ross Nicoll via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (23 lines)
> BIP 70 currently lists two networks, main and test (inferred as testnet3) > for payment protocol requests. This means that different testnets cannot be > supported trivially, and the protocol cannot be used for alternative coins > (or, lacks context to indicate which coin the request applies to, which is > particularly dangerous in cases where coins share address prefixes). > > 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. For backwards compatibility, the "network" field would > contain "main" for Bitcoin main net, "test" for Bitcoin testnet3, and > "other" for other networks apart from those two. > > I'd appreciate initial feedback on the idea, and if there's no major > objections I'll raise this as a BIP. > > Ross > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
I'm cautious of using human-meaningful identifiers, especially any that might require a central repository, due to name collisions. Examples that could be complicated include BitcoinDark, Litedoge, and other names that base on existing coins. I think the ability to differentiate between test networks is also useful.
Could certainly just use the genesis hash as network ID, that would work. Bit long, but suspect 64 bytes isn't the end of the world! I'll see if any more responses come in then raise a BIP for using genesis hash as an alternative to short names.
Ross
On 09/08/2015 15:29, Mike Hearn wrote:
Quoted text (18 lines)
> > I'd appreciate initial feedback on the idea, and if there's no > major objections I'll raise this as a BIP. > > > The reason BIP 70 doesn't do this is the assumption that alt coins are > ... well .... alt. They can vary in arbitrary ways from Bitcoin, and > so things in BIP70 that work for Bitcoin may or may not work for other > coins. > > If your alt coin is close enough to BIP 70 that you can reuse it "as > is" then IMO we should just define a new network string for your alt. > network = "dogecoin-main" or whatever. > > You could also use the genesis hash as the network name. That works > too. But it's less clear and would involve lookups to figure out what > the request is for, if you find such a request in the wild. I don't > care much either way.
Another possibility to support side|alt-chains is the bip44 coin type registry.
A problem that hasn't been mentioned is that a coin can extend the protocol in an incompatible way (different protocol buffer format) so just changing the network field in the PaymentDetails message will not work. A better approach is to add an optional coin type field to the PaymentRequest and serialize the incompatible PaymentDetails to the serialized_payment_details field.
To support a future testnet4 in PaymentDetails we only need to add a new network string like "test4". On Aug 9, 2015 18:23, "Ross Nicoll via bitcoin-dev" < bitcoin-dev@lists•linuxfoundation•org> wrote:
I'm cautious of using human-meaningful identifiers, especially any that might require a central repository, due to name collisions. Examples that could be complicated include BitcoinDark, Litedoge, and other names that base on existing coins. I think the ability to differentiate between test networks is also useful.
Could certainly just use the genesis hash as network ID, that would work. Bit long, but suspect 64 bytes isn't the end of the world! I'll see if any more responses come in then raise a BIP for using genesis hash as an alternative to short names.
Ross
On 09/08/2015 15:29, Mike Hearn wrote:
I'd appreciate initial feedback on the idea, and if there's no major
Quoted text (2 lines)
> objections I'll raise this as a BIP. >
The reason BIP 70 doesn't do this is the assumption that alt coins are ... well .... alt. They can vary in arbitrary ways from Bitcoin, and so things in BIP70 that work for Bitcoin may or may not work for other coins.
If your alt coin is close enough to BIP 70 that you can reuse it "as is" then IMO we should just define a new network string for your alt. network = "dogecoin-main" or whatever.
You could also use the genesis hash as the network name. That works too. But it's less clear and would involve lookups to figure out what the request is for, if you find such a request in the wild. I don't care much either way.
Here's some related commits from #6382 :
https://github.com/jtimon/bitcoin/commit/1a4e8d8637ced45e8785ddb95b0fc20a5b8365d1 https://github.com/jtimon/bitcoin/commit/a6941e318a7028ce3d8919d50825762ca9c0c74c https://github.com/jtimon/bitcoin/commit/1754928d3ceeb26b2491ad1384095058e456fa9b https://github.com/jtimon/bitcoin/commit/d5fe6b62e3e983b35f9e8e61cfce16d7cd091699
And a related PR (closed for now, at least until #6235 is merged) : https://github.com/bitcoin/bitcoin/pull/6229
I definitely add the chainID field, and support regtest in bip70 too (code is more complex by not supporting it that it could be while supporting it). And if we want to maintain the chain petname, I would change "test" to "testnet3".
While "main" and "regtest" are always used for those chains, we currently have 3 different strings for testnet3:
"testnet3": for the default data directory. "testnet": for the GUI style, and strings showed to the user. "test": for bip70
I really want to simplify this and I think the simplest way to do so is by unifying everything to always use "testnet3", although that would require modifying bip70.
Quoted text (8 lines)
> On 09/08/2015 15:29, Mike Hearn wrote: > The reason BIP 70 doesn't do this is the assumption that alt coins are ... > well .... alt. They can vary in arbitrary ways from Bitcoin, and so things > in BIP70 that work for Bitcoin may or may not work for other coins. > > If your alt coin is close enough to BIP 70 that you can reuse it "as is" > then IMO we should just define a new network string for your alt. network = > "dogecoin-main" or whatever.
Altchains aren't just altcoins and sidechains: there's also testchains like testnet3, regtest and sizetestN ( #6382 ). Since there's so many possible instances for sizetest, testchains are already more numerous than altcoins (not that this last thing matters much for anything). Just forget about altcoins and sidechains: do it for the testchains (that's the reason why bitcoin has chainparams and multi-chain support in the first place).
We should make things easier to add new testchains, not harder. It is sad to see that some times things are "the wrong way" because doing them "the right way" could "simplify things to altcoins too much". Such a design criterion seems so ridiculous and sad to me...
Quoted text (3 lines)
> You could also use the genesis hash as the network name. That works too. But > it's less clear and would involve lookups to figure out what the request is > for, if you find such a request in the wild. I don't care much either way.
Those lookups can but just to a map in memory, like in https://github.com/jtimon/bitcoin/commit/1a4e8d8637ced45e8785ddb95b0fc20a5b8365d1#diff-64cbe1ad5465e13bc59ee8bb6f3de2e7R20
Alternatively we can maintain the chain petname field, but those are just "standard petnames", not unique and immutable ids like the genesis hash.
We're not modifying BIP 70, it's now immutable and can only be extended.
There's really not much point in having a dedicated chain ID for regtest mode. You shouldn't be finding BIP70 requests for regtest outside of your own developer machine, where the id doesn't matter.
On Mon, Aug 10, 2015 at 2:53 PM, Mike Hearn <hearn@vinumeris•com> wrote:
Quoted text (1 line)
> We're not modifying BIP 70, it's now immutable and can only be extended.
Well, yes, I guess it's modifying that in the extension BIP.
Quoted text (3 lines)
> There's really not much point in having a dedicated chain ID for regtest > mode. You shouldn't be finding BIP70 requests for regtest outside of your > own developer machine, where the id doesn't matter.
The point is not having exceptions and treating all supported chains in the same way in the code. Having a special case for regtest makes the code more complex, not simpler.
I thought this would be a helpful visualization in the discussion:
Of note are the differences between alts which were derived from BTC (Proof-of-work algorithm: SHA-256), vs. those which were developed in a different fashion such as BCN (Proof-of-work algorithm: CryptoNight) and its alts.
On 08/09/2015 11:42 AM, John L. Jegutanis via bitcoin-dev wrote:
Quoted text (63 lines)
> Another possibility to support side|alt-chains is the bip44 coin > type registry. > > A problem that hasn't been mentioned is that a coin can extend the > protocol in an incompatible way (different protocol buffer format) > so just changing the network field in the PaymentDetails message > will not work. A better approach is to add an optional coin type > field to the PaymentRequest and serialize the incompatible > PaymentDetails to the serialized_payment_details field. > > To support a future testnet4 in PaymentDetails we only need to add > a new network string like "test4". > > On Aug 9, 2015 18:23, "Ross Nicoll via bitcoin-dev" > <bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote: > > I'm cautious of using human-meaningful identifiers, especially any > that might require a central repository, due to name collisions. > Examples that could be complicated include BitcoinDark, Litedoge, > and other names that base on existing coins. I think the ability > to differentiate between test networks is also useful. > > Could certainly just use the genesis hash as network ID, that > would work. Bit long, but suspect 64 bytes isn't the end of the > world! I'll see if any more responses come in then raise a BIP for > using genesis hash as an alternative to short names. > > Ross > > > On 09/08/2015 15:29, Mike Hearn wrote: >> >> I'd appreciate initial feedback on the idea, and if there's no >> major objections I'll raise this as a BIP. >> >> >> The reason BIP 70 doesn't do this is the assumption that alt >> coins are ... well .... alt. They can vary in arbitrary ways >> from Bitcoin, and so things in BIP70 that work for Bitcoin may or >> may not work for other coins. >> >> If your alt coin is close enough to BIP 70 that you can reuse it >> "as is" then IMO we should just define a new network string for >> your alt. network = "dogecoin-main" or whatever. >> >> You could also use the genesis hash as the network name. That >> works too. But it's less clear and would involve lookups to >> figure out what the request is for, if you find such a request in >> the wild. I don't care much either way. > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists•linuxfoundation•org > <mailto:bitcoin-dev@lists.linuxfoundation.org> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ bitcoin-dev mailing > list bitcoin-dev@lists•linuxfoundation•org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >
- -- http://abis.io ~ "a protocol concept to enable decentralization and expansion of a giving economy, and a new social good" https://keybase.io/odinn
On Monday, August 10, 2015 6:32:10 PM Ross Nicoll wrote:
Quoted text (1 line)
> BTW, did you mean to take this off-list?
No, accidental. I'll re-CC it on this email.
Quoted text (24 lines)
> On 10/08/2015 00:46, Luke Dashjr wrote: > > On Sunday, August 09, 2015 2:12:24 PM Ross Nicoll via bitcoin-dev wrote: > >> BIP 70 currently lists two networks, main and test (inferred as > >> testnet3) for payment protocol requests. This means that different > >> testnets cannot be supported trivially, and the protocol cannot be used > >> for alternative coins (or, lacks context to indicate which coin the > >> request applies to, which is particularly dangerous in cases where coins > >> share address prefixes). > > > > I don't see how address prefixes are relevant - the payment protocol > > doesn't use addresses at all... > > Good point, trying to hard to preempt questions. > > >> 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...
Quoted text (3 lines)
> 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?
Quoted text (10 lines)
> > 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...
Luke
Trimmed some of the thread to clarity
On 10/08/2015 19:40, Luke Dashjr wrote:
Quoted text (9 lines)
>>>> 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.
Quoted text (4 lines)
>> 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.
Quoted text (19 lines)
>>> 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
On Mon, Aug 10, 2015 at 8:40 PM, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (2 lines)
>> > Genesis blocks are not necessarily unique. For example, Litecoin and >> > Feathercoin share the same one.
That's a fatal design in Feathercoin, not a mistake all altchains have done and certainly irrelevant to Bitcoin.
Quoted text (1 line)
> Regtest isn't really a network at all, just a testing mode of Bitcoin Core...
Regtest is a testchain just like testnet2 and testnet3. Testchains are the only reason why Bitcoin Core supports multiple chains using CChainParams.
Quoted text (10 lines)
> 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...
For the payment protocol testchains, sidechains and altcoins are all quite similar. But it is fine to just focus on testchains if sidechains and altcoins are out of scope.
On Mon, Aug 10, 2015 at 9:19 PM, Ross Nicoll via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (4 lines)
> 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.
No, the chain ID needs to be unique, that's the whole point.