Martin Sustrik [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2013-10-21 to 2013-10-24
💬 Posted a total of 8 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:07:48

- reply

📅 Original date posted:2013-10-24
📝 Original message:On 23/10/13 23:07, Pieter Wuille wrote:
> In short,
> consistency is more important than correctness.
That's a nice and concise way to put it and any potential protocol
documentation should start with a statement like that.
> However, I do not think that making it hard to find information about
> the details of the system is the way to go. Alternate implementations
> are likely inevitable, and in the long run probably a win for the
> ecosystem. If effort is put into accurately describing the rules, it
> should indeed carry a strong notice about it being descriptive rather
> than normative.
One interesting question is whather alternative implementations are more
likely to get it wrong because the protocol description is wrong or
because the authors misunderstood the reference implementation source code.
Extensive documentation of the source code, a la Knuth's literate
programming, may be some kind of a middle ground.
> If someone is willing to work on that, I am (and likely many people in
> #bitcoin-dev are) available for any questions about the protocol and
> its semantics.
Ok. Several people expressed an interest in the topic, so I'll give it a
try and see how it fares.
Martin

2023-06-07 15:07:47

- reply

📅 Original date posted:2013-10-23
📝 Original message:On 23/10/13 21:40, Peter Todd wrote:
> The reference implementation is the specification - the "specification"
> on the wiki is best thought of as a set of Coles Notes on the real
> specification. If you don't already understand that and the nuance of
> that statement you should assume the protocol is fixed in stone and
> doesn't evolve at all; that statement is not quite true, but it's very
> close to the truth.
Does that imply that the notes are deliberately obscured to force
everyone to check the source code?
Martin

2023-06-07 15:07:46

- reply

📅 Original date posted:2013-10-23
📝 Original message:On 22/10/13 16:08, Jeff Garzik wrote:
> All that is good practice, but we should avoid adding burdensome
> process that might discourage BIP writing.
>
> Consider a distributed approach: if you feel a draft needs more
> sections or better language, submit a pull request yourself and help
> community-edit the document.
I would love to do so.
However, from what Peter Todd said above, my feeling was that spec is
deliberately vague to force compatibility with the reference
implementation rather than with a document.
While that kind of compatibility-via-obscurity won't probably work in a
long run, in short run it can prevent proliferation of implementations
and thus give protocol more space and flexibility to evolve (I've done
the same trick with ZeroMQ myself once).
Anyway, if my impression was wrong I am happy to give it a try.
Martin

2023-06-07 15:07:45

- reply

📅 Original date posted:2013-10-22
📝 Original message:On 22/10/13 09:56, Gregory Maxwell wrote:
> On Tue, Oct 22, 2013 at 12:34 AM, Martin Sustrik <sustrik at 250bpm.com> wrote:
>> There's also Security Considerations part in
>> every RFC that is pretty relevant for Bitcoin.
>
> Which would say something interesting like "If the bitcoin network
> implements inconsistent behavior in the consensus critical parts of
> the protocol the world ends. As such, conformance or _non_-conformance
> with this specification (in particular, sections 4. 5. and 6.) may be
> required for security."
In fact, yes.
In the end it boils down to saying something like: "Bitcoin is a unique
global distributed application and thus all implementations MUST support
the version of the protocol currently in use, irrespective of whether it
have been documented and/or published. This RFC is meant only for
informational purposes and is a snapshot of the protocol as to Oct 22nd
2013."
That being said, I understand the idea of not publishing the spec so
that everyone is forced to work with live data.
> A Bitcoin protocol RFC would be a great place to exercise RFC 6919
> keywords. ( http://tools.ietf.org/html/rfc6919 )
Heh. Haven't seen that one.
Martin

2023-06-07 15:07:44

- reply

📅 Original date posted:2013-10-22
📝 Original message:On 22/10/13 09:03, Gregory Maxwell wrote:
> On Mon, Oct 21, 2013 at 11:59 PM, Jean-Paul Kogelman
> <jeanpaulkogelman at me.com> wrote:
>> Have you seen: https://en.bitcoin.it/wiki/Protocol_specification ?
>
> Take care, the information in the wiki is woefully incomplete.
Imagine myself, with no prior knowledge of Bitcoin looking at the
document. It starts with "Hashes". What hashes? No idea what's going on.
Etc.
Now compare that to a well written RFC. It starts with introduction,
description of the problem, explains the conceptual model of the
solution, then dives into the details. There's also Security
Considerations part in every RFC that is pretty relevant for Bitcoin.
As I said, I am willing to help with writing such document, it would be
a nice way of learning the stuff, however, help from core devs, such as
answering question that may arise in the process, or reviewing the
document would be needed.
Martin

2023-06-07 15:07:44

- reply

📅 Original date posted:2013-10-22
📝 Original message:On 21/10/13 21:47, Luke-Jr wrote:
> On Monday, October 21, 2013 7:38:37 PM Jean-Paul Kogelman wrote:
>> 1) Should the protocol specification page also be codified into BIP(s)?
>
> Probably wouldn't hurt, but it'd likely need a rewrite in a more modular and
> formal form.
I wanted to have a look at how the whole Bitcoin thing works recently.
Being a distributed application, I've searched for the protocol spec.
What I found were two wiki pages (Protocol & ProtocolRules) that looked
more like notes someone wrote down while implementing the application.
Have I missed something? Is there any effort underway trying to produce
a decent spec? If not so, I am willing to help with that.
Martin

2023-06-07 15:07:44

- reply

2023-06-07 15:07:44

- reply

2023-06-07 15:07:40

- reply

📅 Original date posted:2013-10-21
📝 Original message:On 21/10/13 09:07, Jean-Paul Kogelman wrote:
> The list comes from BIP 1.
Sorry, I haven't meant you personally. It was just a generic question
about using existing process instead of inventing a new one on the go.
>> Have it been considered to do this via IETF? The process there is hardened by 40 years of experience and 7000+ RFCs. Probably better than anything you can devise yourself.
>>
>> Martin
>

2023-06-07 15:07:38

- reply

📅 Original date posted:2013-10-21
📝 Original message:On 21/10/13 08:52, Jean-Paul Kogelman wrote:
> How about putting them into sub directories that map onto the status of the BIP?
>
> Reading BIP 1, that would make:
>
> Accepted
> Active
> Draft
> Deferred
> Final
> Rejected
> Replaced
> Withdrawn
Have it been considered to do this via IETF? The process there is
hardened by 40 years of experience and 7000+ RFCs. Probably better than
anything you can devise yourself.
Martin

2023-06-07 15:07:38

- reply