What would you change about the Bitcoin protocol?

[just_someguy]

I would like to see address fields support host names and not just ip addresses.

[1713559640]

1713559640

[Garrett Burgwardt]

IP transactions are disabled already, I believe. In any case they really shouldn't be used.

[just_someguy]

I don't mean for transactions, I mean for Peering.

[Garrett Burgwardt]

Ah, then yes that would make sense, though I don't think that's protocol, just implementation.

[just_someguy]

Its protocol since the addr record only supports ips but it would be easy enough to add another type. Also, it would solve the problem of a nat client not knowing its own ip. You could just enter you dyndns address (and port because I don't like the fixed port.)

[alkor]

• OP_CHECKSIG:  Woah!  It really doesn't seem right to me that a script operator is so complex.  It just feels wrong that the scripts need to be filtered, truncated, and reencoded into a copy of the transaction; and this is done for every TXIN.. and comes up with a different result.  I understand the problem, every component of the transaction needs signing as a whole by all the owners of the source TXOUTS, but OP_CHECKSIG reads like some sort of frankenstein monster.  My first instinct is that the signatures shouldn't have been part of the script, they should have been indexed fields in the transaction header, referenced with an OP_FETCHSIG(1) or similar in the script.  That way the script would be static and the signature could remain outside the block that it is signing.  I suppose to be more generic it would have been better to have a simply parameter block as part of the transaction header, and the operator would be OP_FETCHPARAM; but the idea is the same.  It's not like this is even out of character.  OP_CHECKSIG already requires out-of-script data.

I agree with this one. Was it really necessary to implement a whole scripting language for a single-purpose application like bitcoin? I think it would have been better to go without the scripting part, and just keep things as simple as possible. Right now the code is so complex, that even seasoned C++ coders do not understand it, and everybody has to defer to the judgement of a few specialists. I think the simpler the code-base and the more people understand it, the greater the confidence that the implementation is sound.

Right now for me the code is just one big obscure blob. But then I'm not a good programmer, so maybe it's just me.

[realnowhereman]

Was it really necessary to implement a whole scripting language for a single-purpose application like bitcoin?

It's existence is a nice solution to dealing with future extensibility of bitcoin; but like so many things in bitcoin, the idea is excellent, but the implementation is... complex.

Apart from a few obvious exceptions, the scripting language is actually fairly simple; so much so that I wonder what possible future it is defending against.  The main problem I see is that the interface between script and transaction is opaque.  I would rather have seen the likes of OP_CHECKSIG implemented as simpler component part in the scripting language, with other operators that fetch transaction related information as needed.

OP_CHECKSIG and friends stand out as being of a ridiculously high level in a fairly simple language.  It might as well have been one operation per transaction: OP_DO_ALL_THE_STUFF_THAT_HAS_TO_BE_DONE.

All that being said, I kind of feel myself edging towards your point of view... was the scripting language really necessary?  Especially in the form it is.

[Mike Hearn]

It's necessary for distributed contracts. There's no GUI for that in BitCoin today, but over the next few years it's an area that will be explored more.

[realnowhereman]

But was it necessary to be in the form its in now?

I doubt it.

I don't really know what a distributed contract is though, so I don't suppose I'm entitled to say.

[BitterTea]

There are some really interesting transactions you can make using scripting.

A good explanation by Satoshi: http://bitcointalk.org/index.php?topic=195.msg1611#msg1611

edit... Another, more recent thread: http://bitcointalk.org/index.php?topic=6900.0

[realnowhereman]

In both of those threads, it's pointed out that the "clever" idea doesn't need any special scripting, and the ideas are better done in another way (which didn't involve scripts).  That still pulls me towards the conclusion that scripting in its current form is simultaneously overkill and underkill.  It can't do some things that may be wanted, and it does plenty that isn't.

As I said, I can see the potential in the idea of scripts, I just think the implementation is wrong.  Apart from a load of operations that are unlikely to ever be used (OP_2ROT?) in transactions as they currently are; there are a small number of commonly used operations, and one key one (OP_CHECKSIG) which embeds so much intelligence in a single operation that it might as well have been a flag early on that said "handle this transaction in the usual way".  And the nonsense that is "template matching" of scriptPubKey for spenders to detect what the sender wanted them to put in scriptSignature demonstrates my point programmaticly.

Like so much of Bitcoin, I think the ideas are revolutionary, but the implementation leaves a lot to be desired.

Rather than be one of these drive-by-moaners though, I've become interested enough that I'm working on my own independent Bitcoin code.  As much as Satoshi and Gavin think it will be "a menace", I disagree, and think a cleaner design will allow for easier derivatives.  I know, I know, that's what they all say :-)  No programmer ever wants to write a patch do they?  They'd rather start again on their own.

My ideas:

• Separation of GUI, protocol and wallet
• Librification
• Smartphone implementations
• Desktop "light" client
• Sparse block chain supprt
• "Walletless" node
• Pluggable miners
• More flexible wallets
• More portable wallets
• Strong and easy backward compatible protocol version support

There seems to be a need for many of these, and many of them seem to have been addressed by creating a custom client.

Whether I'll succeed or not remains to be seen; and I certainly don't want to implement all of the above myself.  However, I would like to create a solid enough base that is modular, clear and easily extensible enough for others to get involved and implement what they want more easily than they currently can.  I've browsed the current client code and (sorry if this upsets anyone) it is an unholy mess.  I don't ascribe blame or condemnation for that -- the first version of every new system is always messy, as they tend to grow organically.  As the mythical man month recommends though, "plan to throw one away, you will anyway".

I'm not ready to share yet, but what I've got is going well, and isn't an unholy mess.  Most of my comments here are notes that I've made during coding as I stumble across oddities.  Perhaps I'll hit a wall of complexity that I cannot clear and will give up; so far I don't foresee anything that is going to insurmountable.

[alkor]

Rather than be one of these drive-by-moaners though, I've become interested enough that I'm working on my own independent Bitcoin code.  As much as Satoshi and Gavin think it will be "a menace", I disagree, and think a cleaner design will allow for easier derivatives.  I know, I know, that's what they all say :-)  No programmer ever wants to write a patch do they?  They'd rather start again on their own.

My ideas:

• Separation of GUI, protocol and wallet
• Librification
• Smartphone implementations
• Desktop "light" client
• Sparse block chain supprt
• "Walletless" node
• Pluggable miners
• More flexible wallets
• More portable wallets
• Strong and easy backward compatible protocol version support

realnowhereman,

it's great that you are working on an alternative implementation. I was thinkining of doing something like that too, but I guess I am more of a drive-by-moaner than a programmer And I don't think it is a menace to have an alternative implementation - I would actually rather put my money in a clean clear and concise implementation of Satoshi's idea, rather than the current huge blob of C++ code.

I was thinking of using python to program the application, and use twisted for the networking, and protocol buffers for the messaging over the network.

Can you share with us more details of what language you are going to use for your implementation, and what external dependencies are you going to introduce? What will you use for the GUI? Are you going to keep the scripting, or will you do away with it?
 

[realnowhereman]

I'm conscious that I'm going off topic now, so forgive me forum admins.

Can you share with us more details of what language you are going to use for your implementation

I wouldn't object to any language, but I feel that C/C++ give the most flexibility for a library to be integrated in other languages.  I like object oriented, so C++ it is.

and what external dependencies are you going to introduce?

As few as possible.  Personally I don't like libraries that pull in a mountain more of dependencies, so where it is reasonable to do so I've coded my own library modules.

For the library/server/command line parts it's looking distinctly like the dependencies will be OpenSSL for the hashing and ECDSA; and maybe boost for some reference counted pointers, but if the pointer dependencies stay as simple as they are now, then I'll drop that and use explicit memory management to save the dependency.

What will you use for the GUI?

I use Qt when I have to dirty my hands with graphical interfaces.  But my main effort is in the creation of a useful bitcoin library, so there will be strong separation between the GUI and the protocol.

Are you going to keep the scripting, or will you do away with it?

I'm not planning to fork the protocol and will be aiming for 100% compatibility with the official client.  I have no desire to take over from the official client -- in fact that would be counter to one of my fundamental reasons for starting this: there shouldn't be a monoculture of bitcoin clients.  There is danger in that, so I'd prefer to see multiple competing clients.

[Mike Hearn]

Be aware of the dangers of reimplementations too. If your client diverges from Satoshis code even in a tiny detail you risk forking the chain (if people use your code for mining).

Any reimplementation usable for mining that did not come with a very, very large test suite would be a worrying thing indeed.

[realnowhereman]

Mining is pretty low on my priority list as it happens, so it's won't be a problem for quite some time.

Perhaps I haven't understood how mining works, but I thought it was simply a matter of adjusting a nonce until the hash of the block header has a particular number of zeros at the front of it?

As to forking the chain; since the official client will not accept blocks that don't meet its criteria, it's unlikely that a broken implementation could gain traction, since the blocks it mined would never make it into the majority voted true chain.  Unless of course 50% of miners instantly switch to the new miner code.

If it really is as easy as you suggest to fork the chain, then Bitcoin has a serious security hole in it.

[Mike Hearn]

Yes, the risk is that you end up with lots of people using a slightly different implementation. It doesn't have to be 50%, just a significant fraction. The worst case scenario is that one day somebody uses an exotic or badly tested feature and the chain permanently splits because the two implementations disagree on what's valid. That could potentially be an absolute disaster for the system, perhaps one of the few things beyond being made illegal that could instantly kill BitCoin. Your view on the economy would depend on what software you ran.

[bluecmd]

realnowhereman: Great work, you nailed most of my concerns with the protocol.
I can see how it was quickly prototyped but we cannot continue to use this monster - it is not consistent and/or logical at all!

I read a lots of "It's too late to change that" and whatnot - no it's not! Thats why you support protocol versions. If the version message itself needs to change, then realnowhereman had the answer to that with block based switch.

One thing that has not been mentioned - please pretty please just drop the checksum from the packet - it has no function. Early with IPv4 many people though that this would be a problem so everyone implemented checksums on all layers of OSI. Today this is assumed to be handled by the physical / data layer - IPv6 doesn't have any checksums for instance. Even if you do keep it, why on earth do sha256? It has been said and I will say it again - CRC or something that does not require heaps of computing power would be soo much better.

These issues annoy me to the brink that I'm thinking about forking the client and creating a new protocol and talk the new protocol with those that support it. It's the slow way to revolution but it is very possible.

[xf2_org]

realnowhereman: Great work, you nailed most of my concerns with the protocol.
I can see how it was quickly prototyped but we cannot continue to use this monster - it is not consistent and/or logical at all!

I read a lots of "It's too late to change that" and whatnot - no it's not! Thats why you support protocol versions. If the version message itself needs to change, then realnowhereman had the answer to that with block based switch.

Any incompatible change has huge consequences -- users with older clients will not be able to spend their money.

We will continue to avoid such changes until circumstances demand it.

[bluecmd]

That is only a problem if you do not dualstack.

[tombc]

Any change can't be done easily and each design decision (protocol or implementation) can be source of conflict.
I had so much change to do that it was impossible to merge them with the current implementation, the main source of problem
was to make a client only version (that was the early goal of the bitdollar client)
Instead i started working on a different protocol (i have posted the main differences with the bitcoin protocol http://www.bitdollar.org/forum/viewtopic.php?f=8&t=14 )