Well the trick is to make the base protocol incredibly solid and easy. Just make it hard to get wrong. Then give people the ability to build their protocol extensions on top of that, all the while requiring that the initial minimal set of functionality must be maintained compatible, and then you'll have a good protocol that challenges people to improve it, but not to break it. I think the capabilities extension is the way to go  |
|
|
|
|
I'd be interested too, please PM me with an address and I'll be sending the coins. Any idea on how long it takes for the signups with invites to be back up?
|
|
|
|
|
I wonder when they changed that one. It was incredibly hard to get the size out of the message, and we had to switch between size length according to the first byte.
|
|
|
|
I'm quite happy that my proposal finally got some attention :-) Protocol versioning is very "coarse."
Smarter protocols export lists of capabilities, as well as a "major" version number. The major version number is left unchanged absent a major protocol rewrite. The capabilities list is how clients notify each other of what features / bugs / etc. they support.
bitcoin has a bit of this already. grep for 'nServices'
+1 for the capabilities. The Protocol spec should have a minimal set of instructions and an overall message format, while all the rest should be built on top using capabilities or as they are called in BitTorrent protocol extensions. And I'd rather use an array of descriptive names instead of the bitfield bittorrent is using, but that's a detail. |
|
|
|
I've temporarily hacked in a hard coded limit of 102 clients. Any connects after that will fail. Unfortunately no message is printed to the client and it immediately retries but it beats the server crashing. You could put haproxy [1] in front of both servers so that the less charged one gets new connecting clients and you even have transparent failover :-) [1] http://haproxy.1wt.eu/ |
|
|
|
|
Sometimes I cant resist but question satoshis choices: a UINT64 size field? It's incredibly hard to implement in Java ( well not really BigInteger helps) and do we really need messages larger than 4GB (4 bytes)? UINT 64 would allow for messages of 18.45 Exabytes. That's more than all the world movies put together.
I think I'll simply drop messages requiring UINT64 sizes.
|
|
|
|
|
Theymos went ahead and added his, previously pastebin hosted, schema definition to the Wiki, I guess we should really start thinking about merging all the ideas before someone start implementing the one rather than the other and we end up with completely incompatible URIs.
|
|
|
|
I wonder what this might mean: checking for json_loads in -ljansson... no
checking for pthread_create in -lpthread... yes
./configure: line 4305: syntax error near unexpected token `LIBCURL_CHECK_CONFIG'
./configure: line 4305: `LIBCURL_CHECK_CONFIG(, 7.10.1, ,' Any ideas? |
|
|
|
|
Not to mention the ed2k links on filesharing sites. I guess all these schemas have a right to exist in their communities and sometimes a schema becomes ubiquitous. As for the Mime idea, it sounds a lot like the VCF cards that were meant to be used to exchange contact information but they are rarely seen today, whereas microformats can be found all over the web.
So +1 on the bitcoin uri schema.
|
|
|
|
Register your domain outside of the states or use Tor links/ Freenet sites / use a dynamic DNS.
Tor Hidden Services would have my suggestion too. It allows hosters to allow access while being hidden from prying eyes |
|
|
|
Let's try to keep this thread alive and unbury it with new findings while we go along. One fact that I stumbled over (for several hours today, hurting myself as I went) is that all numbers in the protocol are not encoded in network byteorder, but rely on little endian. I guess that would be pretty important if we are to create a documentation. I think there are two ways to look at the protocol, a high level one, where everything is expressed in nice words and comparisons, and another dearly needed one that details the actual information and format on the wire. One nice detail to add is for example that each messahe starts with a 4-byte magic _magic = '\xf9\xbe\xb4\xd9' . Also in the original design a lot of attention went into how the size of a message is encoded: def getSize(self):
first = self.getUByte()
if first == 255: return self.getUInt64()
elif first == 254: return self.getUInt()
elif first == 253: return self.getUShort()
else: return first But message types are simply encoded with a padded 16 byte string. So I'm starting to wonder about the design choices. Why make the size field optimized when the other part of the message is large always? No offense intended, but this kind of things just make it hard to implement. Oh and when using Java you might pay close attention on how to read unsigned data types (again, something I had to bang my head against before realizing my error  ) |
|
|
|
|
While this is certainly useful for a site accepting donations it'll not be a solution for Online Shops because the receiving end of the transaction has no way to distinguish payments, and where they came from. For this purpose it is solicited to generate a new address for each transaction, which in DNS and link-rel is not a given.
|
|
|
|
|
I'm all for a specification of some kind of the protocol. We gave it a first shot when trying to get a working Bitcoin Client to work with pybitcoin, but it turned out the protocol is both complex and hard to understand at times. Also a high level overview of how the different scenarios play out would be incredibly helpful.
We do need alternative clients for the Network, as proven by the huge interest in a native Android client, and for that to ever happen we need a specification of the underlying protocol.
|
|
|
|
ich mein, wenn die early-adopters irgendwas umsonst bekommen hätten und das jetz nichtmehr so wäre, könnt ichs ja noch verstehen, aber das ist bzw war ja nicht der fall, alle fingen und fangen bei null an, tuste nix, kriste nix. find ich total solidarisch.  Eigentlich wollte ich die ganze Debatte auskuehlen lassen indem ich nichts schreibe aber ich denke da muss ich stellung nehmen. Ich bin seit Block 1500 dabei und insofern hatte ich's einfacher Coins zu generieren (keine GPU Miner, keine Cluster, ...) aber damals war das Zeug auch absolut nichts Wert, von daher ist's verdient weil man Zeit und Resourcen in ein System mit ungewisser Zukunft gesteckt hat, und einfach darauf gehofft hat es Zahlt sich aus. Es war eben Goldrausch ^^ |
|
|
|
So shall we put it to vote which URI schema is to be used and promoted by us (the Bitcoin Forum users)? Putting things together options are: - bitcoin://IP:port?addnode=1 only applicable to directly invoke commands on a running mainstream client
- http://127.0.0.1:8330/?to=<bitcoinaddress><separatorchar>1.2.3.4&amount=200.00 again quite limiting
- bitcoin:1U1jTCGkQYRaDVStZdDHMFWUMoSJi4HSc?dn=MyAddress&amount=10.00 Bitcoin address as main information, everything else is optional
- bitcoin:period=12,monthly;address="me":17ujzChRb6VPQGyANVyktc1du2Hrjfwhsz,"friend":1FaBVwRg99UcH332AV6BSWmDCnTRHdro5B;amount=1.23;title="subscription to bitwow" same as above but without the address as main entity and with colons, semi-colons and commas as separator (basically a hash set)
Did I miss something? Also I think before voting we all should agree on what resource (URI is Uniform Resource Identificator) we are actually trying to describe. The first few proposals concentrated on how to issue commands to the mainstream client, whereas the latter (to which I personally tend) try to describe a bitcoin address, along with additional information, that could be added to an address book and could be printed to receipts or invoices. I'll start a poll once we gathered all proposals |
|
|
|
|
Thanks theymos, this is a great tool. I've been playing with the idea myself, but I'm happy you were faster :-)
|
|
|
|
|
Any chance of pooling resources in a joint effort? 1 really good app >> 5 average apps :-)
|
|
|
|
I was thinking on working on an Android client (not just an interface to the desktop client, but a standalone client), so I'm intrigued by the Bounty. Sadly I'll only have time after christmas, so I'll contribute if someone's faster than me. One more thing: conditions have to be a bit better specified. I'd go for standalone app (no desktop client needed), manages it's own wallet, barcode scanner that recognizes the URI format, anything else? |
|
|
|
|
Show Posts
