What would you change about the Bitcoin protocol?

[realnowhereman]

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.

There doesn't seem to be any problem requiring that users have the latest version at present....

I'm thinking particularly of the minimum transaction fee being hard coded at transactions smaller than 0.01.  Then being hard coded at 0.0005 when that was too large.  Next week it'll be hard-coded to something smaller again, I have no doubt.

I'm a bit uncomfortable with all the hard-coded magic numbers in the Bitcoin client, for exactly your reasoning: when they change they need a new client not just a config file update.

[1713947118]

1713947118

[1713947118]

1713947118

[1713947118]

1713947118

[xf2_org]

There doesn't seem to be any problem requiring that users have the latest version at present....

You are confused.  There is no such requirement.

Plenty of clients remain on 0.3.19, and you can still find clients from earlier versions.

The earliest bitcoin client may still log onto the network and spend their bitcoins, at this point in time.

[realnowhereman]

There doesn't seem to be any problem requiring that users have the latest version at present....

You are confused.  There is no such requirement.

Plenty of clients remain on 0.3.19, and you can still find clients from earlier versions.

I'm not confused, the requirement is implicitly made by having hard coded values.  I obviously didn't make that clear.

Tell me, now that bitcoins are approaching $20 how these 0.3.19 clients send me 19 cents without a 100% fee?

[BitterTea]

There doesn't seem to be any problem requiring that users have the latest version at present....

You are confused.  There is no such requirement.

Plenty of clients remain on 0.3.19, and you can still find clients from earlier versions.

I'm not confused, the requirement is implicitly made by having hard coded values.  I obviously didn't make that clear.

Tell me, now that bitcoins are approaching $20 how these 0.3.19 clients send me 19 cents without a 100% fee?

They set their transaction fee to 0.00 BTC and then send you a transaction. It may take a while to confirm, but you'll receive it.

Tell me, other than with Bitcoin, how can you send $0.19 to someone electronically without paying a 100% fee?

[kloinko1n]

I'm not confused, the requirement is implicitly made by having hard coded values.  I obviously didn't make that clear.

Tell me, now that bitcoins are approaching $20 how these 0.3.19 clients send me 19 cents without a 100% fee?

They set their transaction fee to 0.00 BTC and then send you a transaction. It may take a while to confirm, but you'll receive it.

Yes, but the point was to have a small fee that can be sent as a reward for the verification.
It's not very nice if you're only left with the choice between sending a huge fee (BTC 0.01 when USD 1 = 1 UBC) or none.

Tell me, other than with Bitcoin, how can you send $0.19 to someone electronically without paying a 100% fee?

That's not the point. One of the intentions of the BTC is to make micropayments easy and cheap. USD 0.19 (or more) isn't cheap

On the other hand, if you'd parameterise (sorry for my UK English) the fee, who is going to decide about a new fee? Some centralised agency (Satoshi and/or Gavin)?
Or the program itself, based on ... yeah, what exactly? Exchange value of the BTC/USD?
Or maybe some kind of closed feedback loop with a fixed (hehe, here we go again: why not also parameterised?) difficulty setpoint? 

[realnowhereman]

They set their transaction fee to 0.00 BTC and then send you a transaction. It may take a while to confirm, but you'll receive it.

Tell me, other than with Bitcoin, how can you send $0.19 to someone electronically without paying a 100% fee?

I think you're missing the point; and these sorts of blind defenses of Bitcoin don't make it easy to discuss the subject of reasonable improvements rationally.

I'm not attacking Bitcoin; I love Bitcoin, that doesn't make everything perfect though.  I'm saying that, despite protestations to the contrary, a later version of Bitcoin is needed for the whole network; and that this idea that older versions are fully compatible with newer versions is wrong.  If I want to perform the send I gave as an example, I can just get 0.3.22.  So it's not Bitcoin versus $NOT_BITCOIN; it is 0.3.21 versus 0.3.22.

My wider point is that problems like this will continue to turn up while the client has so many hard-coded parameters.  If you want a different example, let's talk about the upcoming removal of the maximum block size limit.  When some clients are making 5MB blocks and those are rejected by older clients, is this pretense that backward compatibility is preserved still going to be maintained?

Here are some of the other hard-coded values I've come across.  I've given them symbolic names, but in the official client they are just dumped at whatever point is appropriate in the code.

Code:

	COINBASE_MATURITY = 100;

	MAX_BLOCK_SIZE = 1000000;
	MAX_BLOCK_SIZE_GEN = MAX_BLOCK_SIZE/2;
	MAX_BLOCK_SIGOPS = MAX_BLOCK_SIZE/50;

	MINIMUM_TRANSACTION_SIZE = 100;

	MIN_TX_FEE.setValue(0,50000);
	MIN_MONEY.setValue(0,0);
	MAX_MONEY.setValue(21000000,0);

	BLOCK_TIMESTAMP_WINDOW = 2 * 60 * 60;
	DIFFICULTY_TIMESPAN = 14 * 24 * 60 * 60;
	NEW_BLOCK_PERIOD = 10 * 60;

	INV_MAX = 50000;
	GETDATA_MAX = 50000;
	GETBLOCKS_RESPONSES_MAX = 500;
	GETHEADERS_RESPONSES_MAX = 2000;
	ADDR_MAX = 1000;
	ADDR_MIN_TIME = 100000000;
	ADDR_MAX_TIME_OFFSET = 10 * 60;
	ADDR_DEFAULT_TIME_PENALTY = 2 * 60 * 60;

	// Address directory constants
	ASSUME_OFFLINE_AFTER = 24 * 60 * 60;
	OFFLINE_UPDATE_INTERVAL = 24 * 60 * 60;
	ONLINE_UPDATE_INTERVAL = 60 * 60;

And I'm nowhere near done.  So: putting these things as literal instead of constants is poor form; but I suspect that quite a few of them should be in a configuration file.  When it turns out that one needs changing, a whole new version is going to be needed.

The problem is exemplified by the current need to change the minimum transaction fee that I keep banging on about.  If this were in a config file then nobody would have to wait for the next version to be able to keep up with the market.  It surely can't be a good thing that the client needs changing depending on what the current Bitcoin price is?

Finally: to preempt the idea that hard-coding these protects the network in any way: a motivated attacker will have no trouble downloading a compiling their own version with whatever parameters they want set.  So all the hard-coding does is make problems for honest users.

[xf2_org]

That's not the point. One of the intentions of the BTC is to make micropayments easy and cheap. USD 0.19 (or more) isn't cheap

No, it's not.

Even satoshi's original paper and presentation mention that bitcoin is not the greatest for micropayments.

[jrmithdobbs]

Code:

	COINBASE_MATURITY = 101;

If you're wanting the actual number of blocks (including the block with the coinbase) this is the correct value.

Client also hard limits it to being ignored for 120. Very confusing. But for very good reasons. Prevents some rare chain split / double spend scenarios. Changing that one is actually not in your interest.

[realnowhereman]

Code:

	COINBASE_MATURITY = 101;

If you're wanting the actual number of blocks (including the block with the coinbase) this is the correct value.

Client also hard limits it to being ignored for 120. Very confusing. But for very good reasons. Prevents some rare chain split / double spend scenarios. Changing that one is actually not in your interest.

From official client; main.h:

Code:

inline bool MoneyRange(int64 nValue) { return (nValue >= 0 && nValue <= MAX_MONEY); }
static const int COINBASE_MATURITY = 100;
#ifdef USE_UPNP

[ShadowOfHarbringer]

This thread deserves bumping for great justice.
Especially now, that Bitcoin network is growing exponentially.

return (Block < 500000) ? ripemd(sha256(buffer)) : truncate(sha256(sha256(buffer)))

Ohh... I'd love to see such change to happen. even maybe

return (Block > 300000) ? ripemd(sha256(whirlpool(buffer))) : truncate(sha256(sha256(buffer))) ;// note >

NSA would be furious...  

Here is an idea for a poll!

* ShadowOfHarbringer likes this.

Would use INT128 so it can be claimed that Bitcoin is 'infinitely divisible' (well that's near enough for most people) as a selling point.

Right now saying it's 8 decimals divisible isn't so catchy.

+1

[kloinko1n]

That's not the point. One of the intentions of the BTC is to make micropayments easy and cheap. USD 0.19 (or more) isn't cheap

No, it's not.

Even satoshi's original paper and presentation mention that bitcoin is not the greatest for micropayments.

Edit:
I need to be very humble because you people have put so much effort, ingenuity and skills into this program, and I'm just a newcomer/user of the system, but I really have fun taking part in this kind of conceptual discussions.
So I wanted to say that I think that probably you are right and Satoshi is right.
And I think we can make it better, no? (Oops, excluding myself from the 'we', because I'm a very poor programmer.)  

After checking his whitepaper I found this:

"The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions..."

Mentioning this as a disadvantage for 'old' currency in a paper in which he proposes a new one, means for me that he intends the bitcoin to perform better in that respect. Sorry if I missed later posts on this forum in which he states otherwise, but that's how I read it.

And a micro-payment requires a micro-fee, so I think the only fixed parameter for the minimum payout of a fee, would be the minimal denomination of the bitcoin, i.e. something like 10^-8 BTC(?).

[jrmithdobbs]

From official client; main.h:

Code:

inline bool MoneyRange(int64 nValue) { return (nValue >= 0 && nValue <= MAX_MONEY); }
static const int COINBASE_MATURITY = 100;
#ifdef USE_UPNP

Yes. But that doesn't include the block that has the coinbase. So it's actually 101 before it matures, and 120 before it shows in the gui or bitcoind as matured and it wont let you spend it until then.

[realnowhereman]

From official client; main.h:

Code:

inline bool MoneyRange(int64 nValue) { return (nValue >= 0 && nValue <= MAX_MONEY); }
static const int COINBASE_MATURITY = 100;
#ifdef USE_UPNP

Yes. But that doesn't include the block that has the coinbase. So it's actually 101 before it matures, and 120 before it shows in the gui or bitcoind as matured and it wont let you spend it until then.

Interesting information. But all I was saying was that 100 was the number written in the source, so saying it should be 101 is not true. If that constant were changed to 101 then it would need 102 blocks to mature.

[Stevie1024]

Well, I'd want some very fundamental changes, probably only realizable in a fork. Please have a look:

http://www.newbitcoin.org/documents/newbitcoin.pdf

[alkor]

http://www.newbitcoin.org/documents/newbitcoin.pdf

I like some of your suggestions, but I am not sure if the new transaction fee structure you propose will work. Also I am not really sure I understand how the new block-chain will work.

I don't think you are correct in claiming that

Some of the mentioned shortcomings may very well lead to a suffocation or even collapse of the current Bitcoin system.

I don't see any significant shortcomings in bitcoin that will lead to its collapse. I think it suffers from the fact that the protocol is still not well defined and the implementation is overly complicated, but there are no major flaws that will lead to its collapse. The main idea behind it is very sound.

For any successor to bitcoin to actually have a following, I think it needs to provide some minimal backward compatibility with the current client. Even if a completely different protocol or a different blockchain is used, at the very least the current wealth distribution must be preserved, or there must be a smooth path to move current bitcoins into the new bitcoins. Lacking that, the new currency will probably have to start trading from zero and compete with the old implementation of bitcoin.

[Stevie1024]

http://www.newbitcoin.org/documents/newbitcoin.pdf

I like some of your suggestions, but I am not sure if the new transaction fee structure you propose will work. Also I am not really sure I understand how the new block-chain will work.

Thanks, I'm very easily flattered! It could very well be that I didn't explain it clearly enough, but could you please be more specific about what part you don't understand?

I don't think you are correct in claiming that

Some of the mentioned shortcomings may very well lead to a suffocation or even collapse of the current Bitcoin system.

I don't see any significant shortcomings in bitcoin that will lead to its collapse. I think it suffers from the fact that the protocol is still not well defined and the implementation is overly complicated, but there are no major flaws that will lead to its collapse. The main idea behind it is very sound.

It'd be quite easy to defend that the system MAY collapse, but I won't be so bland. Some quotes, maybe that'll initiate some proper discussion:
- Higher transaction fees lead to slower transactions
- Enforced limits are not optimal
- Not truly decentralized
- Unmanageable storage requirements
- Technical difficulty
- Current distribution is unfair

We could discuss about where the 'main idea' (which I too find very sound) stops, but until these issues are addressed I think bitcoins will not get much further than a nice new subject of unfounded speculation for the not-so-technically-literate.

For any successor to bitcoin to actually have a following, I think it needs to provide some minimal backward compatibility with the current client. Even if a completely different protocol or a different blockchain is used, at the very least the current wealth distribution must be preserved, or there must be a smooth path to move current bitcoins into the new bitcoins. Lacking that, the new currency will probably have to start trading from zero and compete with the old implementation of bitcoin.

You are absolutely right, I'd be happy to be convinced otherwise (I happen to have some bitcoins myself), but at the moment I think starting from zero is the only way. I remember reading in this forum (or in some documentation) about some smooth transition policy.

[tombc]

Most of these issues are what make me start a new protocol.

[Mike Hearn]

Thanks for writing an interesting paper Steve. I need to think about some of its proposals more, but here are a few early comments:

• Bitcoin already defines the winning chain to be the chain of highest total difficulty, not the longest.
• I think you are over-concerned about storage costs (I think Satoshi was too). Storage is incredibly cheap and the price has been falling for a long time. When I look at the costs involved with running a high speed Bitcoin node, the bottlenecks are things like CPU time and disk seeks, not number of bytes storable.
• Removing script and simplifying the transaction format is superficially attractive, but would eliminate a lot of useful features that are helpful for a non-trust based financial system. The script language isn't really that hard to implement or review. Bitcoin is still millions of times simpler than, say, a web browser. My gut feeling is that Satoshi made the right flexibility:complexity tradeoff here.
• The idea of allowing peers to peel off fees for themselves before relaying is very interesting. I think this is the strongest part of your proposal. I also suspect it's possible to implement on top of Bitcoin using the features that are already there, but I haven't thought about it enough to prove it.
• Early adopter wealth might seem "unfair" but I don't think that's enough to convince people to switch to another currency. People who used Bitcoins when they were worthless deserve a reward for their efforts. Nobody is going to end up owning big chunks of the planet because it's so very unlikely Bitcoin will fully replace existing currencies within our lifetimes, perhaps never. Much more likely is that it finds a niche in the electronic payments space, grows to fill that niche then stabilises.
• I didn't really understand your proposal about chain difficulty. Blocks have a cost associated with them, even though it's small, so allowing people to flood trivial blocks that then have to be stored and verified doesn't seem to help. It's just another DoS avenue.

Don't get me wrong. I think it's great that people are exploring evolutions of the Bitcoin design.

[Stevie1024]

Thanks for writing an interesting paper Steve. I need to think about some of its proposals more, but here are a few early comments:

Thanks Mike. I was just starting to think every developer was too busy following mtgox...

Bitcoin already defines the winning chain to be the chain of highest total difficulty, not the longest.

The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it.

What i'm missing is clear, unambiguous specs. But maybe you have a link?

I think you are over-concerned about storage costs (I think Satoshi was too). Storage is incredibly cheap and the price has been falling for a long time. When I look at the costs involved with running a high speed Bitcoin node, the bottlenecks are things like CPU time and disk seeks, not number of bytes storable.

I agree that you probably know best what the bottlenecks are. But I don't agree storage isn't a problem. Say one transaction is 0.2 kb, suppose we want Bitcoin to be used by millions of users, say 100 million. Then storing that one transaction costs at least 20 Gb. Which is not good enough for micropayments I'd say.

Removing script and simplifying the transaction format is superficially attractive, but would eliminate a lot of useful features that are helpful for a non-trust based financial system. The script language isn't really that hard to implement or review. Bitcoin is still millions of times simpler than, say, a web browser. My gut feeling is that Satoshi made the right flexibility:complexity tradeoff here.

My gut says it's too complicated, but you might be right. Haven't seen a killer application yet, but must admit I could do some more studying on this one.

The idea of allowing peers to peel off fees for themselves before relaying is very interesting. I think this is the strongest part of your proposal. I also suspect it's possible to implement on top of Bitcoin using the features that are already there, but I haven't thought about it enough to prove it.

Think it basically comes down to including a possibility to send private keys along with transactions.

Early adopter wealth might seem "unfair" but I don't think that's enough to convince people to switch to another currency. People who used Bitcoins when they were worthless deserve a reward for their efforts. Nobody is going to end up owning big chunks of the planet because it's so very unlikely Bitcoin will fully replace existing currencies within our lifetimes, perhaps never. Much more likely is that it finds a niche in the electronic payments space, grows to fill that niche then stabilises.

Then for your sake I hope your right. As long as you understand that a completely 'fair' system, as described, is very feasible too.

I didn't really understand your proposal about chain difficulty. Blocks have a cost associated with them, even though it's small, so allowing people to flood trivial blocks that then have to be stored and verified doesn't seem to help. It's just another DoS avenue.[/li][/list]

I wanted to get rid of arbitrary limits (maximum block size, difficulty) and 'time'. There will be more chain-forks, maybe chaos and anarchism (up to a point: the specification). But don't believe flooding will get you far, I expect an optimal equilibrium difficulty.

[tombc]

Sorry i hadn't read all your document in depth, it's done.

I would join you unfortunately i'm already working on the implementation of another protocol,
here the differences between the issues you point in the document, and how i handle that:

Higher transaction fees lead to slower transactions:
That's right, but it is a problem only if a large majority of nodes do that and if some does:
Since transactions are spread all over the network, only the transactions' hash are transfered in blocks.
Nodes are supposed to already have the transaction in inventory, if they dont have, they wont validate
the block until they have received all.
Low block spread is bad for all nodes, but the block of someone that kept some transactions will be transfered
over the network slowly compared to others and could lose race.

(there is also a system to extend the transaction fee of an emited transaction, which could be used to
"award" nodes having it, if client see that transaction has been correctly spreaded)

Your way to solve that problem is good but each transaction would need to access to more accounts which have a cost in disk IO
also i use a one time signature scheme (using hash chains) which can't do that, an emited transaction can't be modified.

Enforced limits are not optimal and Not truly decentralized:
i haven't put limits, limits means doubts in the protocol capacity.

Unmanageable storage requirements:
Huge storage needs also means huge bandwidth needs.
By reducing this, we increase the network number of nodes, strenght
and reduce the transactions fees.

The way i manage accounts and transactions is different, but final result is similar (transactions are only stored 3month, all is kept in a list containing all accounts).
I differenciate account and addresses (address = public key, used to create an account).
Very old accounts without activity also have a small fee each year (these will be mostly account of users that have lost their private key)

I also think storage is a problem since it is the easiest way for someone to attack the network.
For example, without being paranoid, someone could use 1million $ to create transactions that will
take the most possible definitive storage in the chain, that could make serious problem to nodes.
And it could be far more, mass storage capacity is part of the network security.

(Assuming the network is a real p2p network and that nodes have average user disk storage, if there was only
few hundred nodes maybe they could handle, but the currency would not be "p2p" anymore)

No unnecessary difficulty:
I have keep the way bitcoin manage the block race, but with some optimizations and more challenge
between nodes that spread the block.

Proof-of-work as ’currency’:
the way b$ is done, i could not handle a non fixed number of units.
instead i have made the award proportional to the target a of block