Bitcoin Forum
December 04, 2016, 10:32:50 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Ode to the protocol ...  (Read 948 times)
Martin P. Hellwig
Jr. Member
*
Offline Offline

Activity: 33


View Profile
July 04, 2011, 07:15:42 PM
 #1

While I am quietly in my limited spare time building a python implementation of the bitcoin protocol I am increasingly charmed about the ingenuity of the protocol itself.
Sure in the beginning I had of a lot of things* that I found strange but what is even stranger is that I am continuously discovering that the choices made might not be pretty, or particular easy but they share one common trait so far; the alternatives have far worse implications**.

So I would like to take my hat off and say three cheers to everybody that is working, designing and building the protocol, the software and community!

Thank you, it is truly appreciated!

* )
1 The constant byteswapping. Well once (:-)) you have it subclassed  you hardly notice it anymore.
2 Only ~21 million BTC available? Yeah but it is easy enough to increase the divisibility
3 What about lost coins, can we not have a system in place where forgotten coins are available for reminig? Neat, but this ultimately leads for regular users to a dependency on an external service provider, which opens a whole other can of worms.
4 The use of secp256k1, Well ones you look into it, it is kinda neat and there is not a clear and obvious advantage to other curves or public key algorithm, so this falls in the category why not.
5 The lack of a python implementation. Well, I am working on it, so that one is my fault for not moving my behind faster :-)

** )
My opinion, thus the validity of the made statements are not universal.
1480890770
Hero Member
*
Offline Offline

Posts: 1480890770

View Profile Personal Message (Offline)

Ignore
1480890770
Reply with quote  #2

1480890770
Report to moderator
1480890770
Hero Member
*
Offline Offline

Posts: 1480890770

View Profile Personal Message (Offline)

Ignore
1480890770
Reply with quote  #2

1480890770
Report to moderator
1480890770
Hero Member
*
Offline Offline

Posts: 1480890770

View Profile Personal Message (Offline)

Ignore
1480890770
Reply with quote  #2

1480890770
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480890770
Hero Member
*
Offline Offline

Posts: 1480890770

View Profile Personal Message (Offline)

Ignore
1480890770
Reply with quote  #2

1480890770
Report to moderator
davux
Sr. Member
****
Offline Offline

Activity: 289


Firstbits.com/1davux


View Profile WWW
July 04, 2011, 08:12:47 PM
 #2

While I am quietly in my limited spare time building a python implementation of the bitcoin protocol I am increasingly charmed about the ingenuity of the protocol itself.
Sure in the beginning I had of a lot of things* that I found strange but what is even stranger is that I am continuously discovering that the choices made might not be pretty, or particular easy but they share one common trait so far; the alternatives have far worse implications**.

Great!

It would be nice if you could write notes about what you discover. AFAIK, the protocol is only partially documented and mostly resides in "oral tradition" (if I may say so – it's obviously not oral). You could e.g. contribute to the Protocol specification page on the wiki, that still has strong tying between the network protocol and the internal structure of the original implementation (see "variable length strings", data types all over the document, etc.).

This is not a criticism. It's normal at this stage of history (the same happened with jabber/jabberd at the beginning), but an implementation-agnostic, RFC-like document is necessary if we want Bitcoin to succeed as an internet protocol, not just a program.

(Also, it's "once", not "ones".)

1DavuxH9tLqU4c7zvG387aTG4mA7BcRpp2
México (Oaxaca) – France - Leeds
ampkZjWDQcqT
Member
**
Offline Offline

Activity: 70


GNU is not UNIX


View Profile
July 04, 2011, 08:19:44 PM
 #3

It would be nice if you could write notes about what you discover. AFAIK, the protocol is only partially documented and mostly resides in "oral tradition" (if I may say so – it's obviously not oral). You could e.g. contribute to the Protocol specification page on the wiki, that still has strong tying between the network protocol and the internal structure of the original implementation (see "variable length strings", data types all over the document, etc.).

Especially, I think the format of wallet.dat needs to be documented. A good practice it to ship the documentation of the internals together with the source code, something missing in the current reference implementation.

If you found my comment useful please express your gratitude by doing an action of similar magnitude towards a better society. Thanks you!.
davux
Sr. Member
****
Offline Offline

Activity: 289


Firstbits.com/1davux


View Profile WWW
July 04, 2011, 08:46:43 PM
 #4

Especially, I think the format of wallet.dat needs to be documented.

I don't know the subject a lot, but shouldn't the format of wallet.dat only be part of the original implementation internals?

I mean, what matters is interoperability between nodes of the network. How a given node stores its private keys (an sqlite file, MySQL database, an XML file, separate foo.key files...) is an implementation choice. If an alternative implementation wants to be able to read the original wallet.dat, very well, but this is not necessary at all.

But I do agree that a way to export/import the private keys of your published addresses would be useful though, in case they keep receiving coins.

1DavuxH9tLqU4c7zvG387aTG4mA7BcRpp2
México (Oaxaca) – France - Leeds
ampkZjWDQcqT
Member
**
Offline Offline

Activity: 70


GNU is not UNIX


View Profile
July 04, 2011, 08:52:33 PM
 #5

Especially, I think the format of wallet.dat needs to be documented.

I don't know the subject a lot, but shouldn't the format of wallet.dat only be part of the original implementation internals?

Regardless, internals should be documented.

The reference implementation uses Berkeley DB by the way. (Paragraph added after original post)

If you found my comment useful please express your gratitude by doing an action of similar magnitude towards a better society. Thanks you!.
Gavin Andresen
Legendary
*
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
July 04, 2011, 08:59:16 PM
 #6

Especially, I think the format of wallet.dat needs to be documented. A good practice it to ship the documentation of the internals together with the source code, something missing in the current reference implementation.

So go ahead and document it, volunteer to keep it up to date (that's the hard part), and submit a patch. After the latest source-file re-org, there is a top-level doc/ directory where a "wallet_format.txt" file would go.

How often do you get the chance to work on a potentially world-changing project?
Martin P. Hellwig
Jr. Member
*
Offline Offline

Activity: 33


View Profile
July 04, 2011, 09:26:09 PM
 #7

It would be nice if you could write notes about what you discover. AFAIK, the protocol is only partially documented and mostly resides in "oral tradition" (if I may say so – it's obviously not oral). You could e.g. contribute to the Protocol specification page on the wiki, that still has strong tying between the network protocol and the internal structure of the original implementation (see "variable length strings", data types all over the document, etc.).

I have a couple of goals set:
- Split out the protocol in a pure daemon part (which does the communication and storing of the blocks/transactions) possibly with an optional SQL back-end.
- Have everything PEP-8 and Python 3 compliant.
- Have unit tests  with a 100% coverage.
- Be able to have a local "blockexplorer" that does not depend on the c++ client but instead uses the code of the above daemon.
- Create a 'thin' CLI client that interacts with the daemon (in essence this will just hold the private keys and have some UI code).
- The same as above but a GUI client.

For me when coding, the most important part is readability and maintainability, this is also the reason why I am at try number 3  because the other tries, although successfully parsing the tcpdump of an interaction, was not readable enough. So ultimately I want my implementation to be working 'pseudo code'. As I have particular strong feelings on how the Protocol Specification should be written, I think that I am not the appropriate person to contribute to that page.

As the approach I am taking is painstakingly slow, I wouldn't hold my breath, though I do intend to release the source under the new revised BSD license.
And I am sure that when I at least have reached my 4th goal, I can be persuaded to (help) create a RFC with the intention to submit an Internet Draft to the IETF.
kjj
Legendary
*
Offline Offline

Activity: 1302



View Profile
July 04, 2011, 10:49:21 PM
 #8

1 The constant byteswapping. Well once (:-)) you have it subclassed  you hardly notice it anymore.

This is rampant in networking code.  At least in portable networking code.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
I routinely ignore posters with paid advertising in their sigs.  You should too.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!