-
Notifications
You must be signed in to change notification settings - Fork 26
Is consensus encoding necessary to serialise contracts? #84
Comments
I think this question is more related to the specification than the actual implementation, following the spec. So I will move it to the spec repo – we have a "Networking" part there (unwritten), where it will be nice to address this issue and provide some explanations. |
Citing my explanation elsewhere, we had this discussion some time ago in RGB Telegram channel.
|
Protocol buffers isn't well designed for hashed data; consensus encoding is.
I'm not too familiar with exactly what LN is using protocol buffers for. But it's likely not applicable to this usecase.
…On June 26, 2019 11:47:54 PM GMT+01:00, Christophe Diederichs ***@***.***> wrote:
As RGB contracts are not parsed by Bitcoin nodes directly, is it
necessary to serialise using consensus encoding? Consensus encoding
seems underspecified, and structs are only defined implicitly in the
custom encoder.
Protocol buffers, as used in LN, provide freedom to update contract
headers in the future as more contract types are introduced. They are
also well defined structures, making it easier to integrate across
platforms.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#84
|
@petertodd Last time I checked, LND used protobufs for building its gRPC interface. It has nothing to do with P2P communications, just one of endpoints (additionally to usual JSON-RPC). Originally, LND was playing with protobufs for P2P in early releases, but lately, they've taken the decision to replace it with Bitcoin consensus encoding. Why? I didn't find their arguments, but I found arguments from Satoshi himself on protobufs:
I do agree with Satoshi on cons:
Because financial systems are about security first, there is no reason for using protobufs or any other layered third-party solutions for building quite simple network communications. Cons «weight» is much higher than of pros |
@petertodd do you know if there is any work on formalising the specification of consensus encoding? Right now we are going with whatever the rust crate does, but it is not clearly defined anywhere what valid encodings look like (eg tuples) |
I'm afraid there is no specification — I've made my search and found none. The bitcoin encoding is defined as a way bitcoin core nodes encode their data in the bitcoin wire protocol — and thus Bitcoin Core C code is the only specification available. The encoding format is not designed to be universal encoding format supporting some different data types. We are free to extend it and call "RGB encoding" wherever we need; bitcoin encoding code from the rust library is just a very good starting point supporting nearly all data structures we need to support. You can read more here rust-bitcoin/rust-bitcoin#262 (also follow the links in the discussion) |
As RGB contracts are not parsed by Bitcoin nodes directly, is it necessary to serialise using consensus encoding? Consensus encoding seems underspecified, and structs are only defined implicitly in the custom encoder.
Protocol buffers, as used in LN, provide freedom to update contract headers in the future as more contract types are introduced. They are also well defined structures, making it easier to integrate across platforms.
The text was updated successfully, but these errors were encountered: