Some Problems I See With Bitcoins (And A Proposed Solution)

[ring2ding]

I attempted to post this on StackExchange, but was told to come here. So here it is:

I've been thinking a lot about bitcoins lately, and I've discovered some problems with the theory behind them.

1Q) How much will transaction fees eventually be?

2Q) There is a lot of wasted computational power, due to the requirement for "proof of work." Assuming they found a fix for #1, this would still drive the transaction fees to be a LOT higher then they would otherwise need to be.

3Q) Banking information is propagated freely to anybody and everybody. If you wanted to figure out how much money your friend (or worse, your enemy) has, and all of their transactional data, it really wouldn't be that hard. This isn't a huge problem, but this information ideally should be on a "need to know" basis.

After those questions came to mind, I did lots of research on the theory and did lots of thinking. I believe I have an extremely simple solution to all of these problems:

We redefine what it means to bitcoin mine. We scrap the entire idea of "proof of work," as well as blocks. All nodes that define themselves as bitcoin miners must now tell every other node that they are a miner, or "validator" if you will.

3A) When a client posts a transaction, that transaction is propagated ONLY to all validators, and NOT to other clients. Clients should not know about the transaction history of other clients.

2A) All validators must validate the transaction, and then post their results to all other nodes. If it is determined (by each individual node) that 2/3 majority of the validators have validated the transaction, then the transaction is deemed to be valid. There is no "proof of work" and clockcycles are no longer wasted.

1A) The reward (transaction fee) is equally split among all validators. Since each individual node knows how many registered validators there are, it can easily calculate a minimum transactional fee. Transaction fee = (time to process transaction) * (cost per time to process).

What do you guys think, does this make sense at all?

[1713998554]

1713998554

[1713998554]

1713998554

[1713998554]

1713998554

[julz]

I'm not going to go into it on a point by point basis - but all you've managed to do is swap the 'proof of work' system, which prevents gaming of the system, with a system that gives control to whoever can muster the largest resources in terms of IP addresses and virtual nodes.
Having scrapped the whole 'block' system - this 'arms race' would happen at a rapid rate, and even if there were a few competing botnets, control of the network would oscillate between them.
In short - your proposal sounds like a disaster, and suggests you've missed the point of the block system and proof-of-work.

[ring2ding]

all you've managed to do is swap the 'proof of work' system, which prevents gaming of the system, with a system that gives control to whoever can muster the largest resources in terms of IP addresses and virtual nodes.
Having scrapped the whole 'block' system - this 'arms race' would happen at a rapid rate, and even if there were a few competing botnets, control of the network would oscillate between them.
In short - your proposal sounds like a disaster, and suggests you've missed the point of the block system and proof-of-work.

Isn't that how it works anyway though? If an attacker manages to get 50% of the processing power of the network then he could potentially validate an invalid transaction (like creating bitcoins out of thin air).

If anything I would think that my system would be more secure, since an attacker would have to have 2/3 majority, not in terms of processing power but in terms of nodes. This security is inherit in the philosophy of bitcoins, and it depends on the philosophy that there will always be more genuine validators than attacker validators.

[SgtSpike]

Let me get this straight:

- For each transaction, each validation node gets an equal split of the transaction fee.
- One person could potentially control thousands or hundreds of thousands of nodes.
- For each node that gets a split of the transaction fee, a new record of said split of the transaction fee being distributed to the node needs to be recorded (i.e., for 10 nodes, you'd need 10 records of 1/10th of the transaction fee being distributed to each of the nodes).
- Suddenly, you have hundreds of KBs of information being recorded for each transaction, because the transaction fee is split between hundreds of thousands of nodes.
- Fail.

[ring2ding]

Let me get this straight:

- For each transaction, each validation node gets an equal split of the transaction fee.
- One person could potentially control thousands or hundreds of thousands of nodes.
- For each node that gets a split of the transaction fee, a new record of said split of the transaction fee being distributed to the node needs to be recorded (i.e., for 10 nodes, you'd need 10 records of 1/10th of the transaction fee being distributed to each of the nodes).
- Suddenly, you have hundreds of KBs of information being recorded for each transaction, because the transaction fee is split between hundreds of thousands of nodes.
- Fail.

Good point. I'll have to think about this some more. There HAS to be a better way to randomly pick like 10 nodes that get to process the transaction.

[SgtSpike]

Keep thinking!  Nothing wrong with a good brainstorming session every so often...

[cbeast]

Good point. I'll have to think about this some more. There HAS to be a better way to randomly pick like 10 nodes that get to process the transaction.

This has been suggested before. Some people don't seem to like the proof of work concept. Maybe it because your math teacher made you do it. 

[ring2ding]

I don't know. I don't think I have enough math skills to figure this out lol. Has the genious who came up with this figured out how to solve Q1?

[SgtSpike]

I don't know. I don't think I have enough math skills to figure this out lol. Has the genious who came up with this figured out how to solve Q1?

Absolutely depends on transaction volume.  If the price of 1 BTC is $2.50, and there are no block rewards, and there are 25 transactions per block on average, then I figure a transaction fee of $0.50/transaction will still provide around 1 TH/s of hashing power, which I believe would be sufficient to secure the network if the entire currency is worth $50M.  I calculated this all out in another thread, but that's the result.

I don't think $0.50/transaction is an unreasonable cost to pay - it's still a heck of a lot cheaper than a wire transfer.  And that's basing it off of today's transaction numbers.  5-10 years down the road, when the block reward really starts getting small, we may have a lot more transaction volume.  If we had 2500 transactions per block, we could still maintain around 4 TH/s per dollar price of BTC, and drop transaction costs to around $0.05/transaction.

The yet-to-be-determined factor is how much hashing power we actually need to secure the network.  In my opinion, 1 TH/s is plenty enough to secure the network with each BTC worth $2.50, but the goal should be linear growth in hashing power relative to price from there.  So 10 TH/s if each BTC is worth $25, etc.  Once we figure out that factor, then some hard numbers can be calculated for transaction fees based on current transaction volume to reach a target hashing goal.

[DeathAndTaxes]

Proof of work is what keeps the network "honest".

I suggest you actually READ Satoshi paper.  Read it from beginning to end.  Now stop.  Don't post.  Just think.  Now read the entire paper again because likely what it said and what you thought it said aren't the same thing.

The block chain is a consensus much like voting is a consensus process.

The key question (which wasn't solve adequately prior to Bitcoin)
How do you reach a consensus among untrusted peers?

The blockchain is a based on a vote.
In an election you have 1 vote = 1 person.  To work you must identify each person and ensure they vote only once.
In a stock motion you have 1 vote = 1 share.  To work you must identify each share and ensure they vote only once.

Bitcoin is an anonymous network.  A single person could have one node, 100 nodes, 100,000 nodes or 99.99999999999% of the nodes on the network.

How can you ensure 1 vote = 1 person/entity?  Simple answer.  YOU CAN'T.  Satoshi didn't even try.

He made it 1 hash = 1 vote.  Since generating large number of hashes is expensive it becomes expensive to attack the network.

There is a negligible cost to form a node.  With some web hosting contract I could form 2/3rds of the Bitcoin nodes for a token amount of time, resources, and money.  Under you system I winz.  I control every transaction, can double spend, can halt the block chain, can prevent transcations from being processed and at a tiny fraction of the cost to gain 51% control over 9TH.

[DeathAndTaxes]

I don't know. I don't think I have enough math skills to figure this out lol. Has the genious who came up with this figured out how to solve Q1?

Absolutely depends on transaction volume.  If the price of 1 BTC is $2.50, and there are no block rewards, and there are 25 transactions per block on average, then I figure a transaction fee of $0.50/transaction will still provide around 1 TH/s of hashing power, which I believe would be sufficient to secure the network if the entire currency is worth $50M.  I calculated this all out in another thread, but that's the result.

I don't think $0.50/transaction is an unreasonable cost to pay - it's still a heck of a lot cheaper than a wire transfer.  And that's basing it off of today's transaction numbers.  5-10 years down the road, when the block reward really starts getting small, we may have a lot more transaction volume.  If we had 2500 transactions per block, we could still maintain around 4 TH/s per dollar price of BTC, and drop transaction costs to around $0.05/transaction.

The yet-to-be-determined factor is how much hashing power we actually need to secure the network.  In my opinion, 1 TH/s is plenty enough to secure the network with each BTC worth $2.50, but the goal should be linear growth in hashing power relative to price from there.  So 10 TH/s if each BTC is worth $25, etc.  Once we figure out that factor, then some hard numbers can be calculated for transaction fees based on current transaction volume to reach a target hashing goal.

The current rules make that impossible.

Nobody would pay $0.25.  Nobody.  They would pay the absolute minimum to get the transaction processed which is closer to 1 satoshi.  It will require protocol rule changes to build a functional fee economy.

[SgtSpike]

Proof of work is what keeps the network "honest".

I suggest you actually READ Satoshi paper.  Read it from beginning to end.  Now stop.  Don't post.  Just think.  Now read the entire paper again because likely what it said and what you thought it said aren't the same thing.

The block chain is a consensus much like voting is a consensus process.

The key question (which wasn't solve adequately prior to Bitcoin)
How do you reach a consensus among untrusted peers?

There is no (trivial) cost to form a node.  With some web hosting contract I could form 2/3rds of the Bitcoin nodes for a token amount of time, resources, and money.  Under you system I winz.  I control every transaction, can double spend, can halt the block chain, can prevent transcations from being processed.

The blockchain is a based on a vote.
In an election you have 1 vote = 1 person.  To work you must identify each person and ensure they vote only once.
In a stock motion you have 1 vote = 1 share.  To work you must identify each share and ensure they vote only once.

Bitcoin is an anonymous network.  A single person could have one node, 100 nodes, 100,000 nodes or 99.99999999999% of the nodes on the network.

How can you ensure 1 vote = 1 person/entity?  Simple answer.  YOU CAN'T.  Satoshi didn't even try.

He made it 1 hash = 1 vote. 

I think what he was getting at is that many people would buy web hosting contracts, and snatch up IP's for nodes.  Kind of like one person would dominate the current model if they were the only one mining with a GPU farm, but because many people mine with GPU farms, no single person has complete control.

Web hosting is a non-trivial cost, especially as IP addresses become more scarce because everyone is trying to snatch them up for nodes.  Now, if you based it off of IPv6, then you're gonna open up a new can of worms.  But with IPv4, and the same level of activity in "mining" as is currently happening with Bitcoin, I think you could be pretty certain that no single person would have control of > 50% of the nodes.

I like the hashing method better, but I *think* an IP-based method could work too, simply because IPv4 addresses are becoming scarce, and the costs are not trivial for said addresses.

[SgtSpike]

I don't know. I don't think I have enough math skills to figure this out lol. Has the genious who came up with this figured out how to solve Q1?

Absolutely depends on transaction volume.  If the price of 1 BTC is $2.50, and there are no block rewards, and there are 25 transactions per block on average, then I figure a transaction fee of $0.50/transaction will still provide around 1 TH/s of hashing power, which I believe would be sufficient to secure the network if the entire currency is worth $50M.  I calculated this all out in another thread, but that's the result.

I don't think $0.50/transaction is an unreasonable cost to pay - it's still a heck of a lot cheaper than a wire transfer.  And that's basing it off of today's transaction numbers.  5-10 years down the road, when the block reward really starts getting small, we may have a lot more transaction volume.  If we had 2500 transactions per block, we could still maintain around 4 TH/s per dollar price of BTC, and drop transaction costs to around $0.05/transaction.

The yet-to-be-determined factor is how much hashing power we actually need to secure the network.  In my opinion, 1 TH/s is plenty enough to secure the network with each BTC worth $2.50, but the goal should be linear growth in hashing power relative to price from there.  So 10 TH/s if each BTC is worth $25, etc.  Once we figure out that factor, then some hard numbers can be calculated for transaction fees based on current transaction volume to reach a target hashing goal.

The current rules make that impossible.

Nobody would pay $0.25.  Nobody.  They would pay the absolute minimum to get the transaction processed which is closer to 1 satoshi.  It will require protocol rule changes to build a functional fee economy.

Oh I absolutely agree.  I'm sure the transaction fee rules will be changed as we get closer to the time where they are needed though.  Right now, transaction fees are purely experimental.  They aren't necessary at all.

[DeathAndTaxes]

Right now, transaction fees are purely experimental.  They aren't necessary at all.

Well they are needed.  The current rules are designed not for economics but protection.  They keep various spam attacks from cost effective. 

[DeathAndTaxes]

I like the hashing method better, but I *think* an IP-based method could work too, simply because IPv4 addresses are becoming scarce, and the costs are not trivial for said addresses.

The largest botnet in the world has ~250,000 nodes.   Bitcoin current has ~15K nodes. 

To acquire large numbers of unique IP addresses lawfully is expensive.
To acquire large numbers of unique IP addresses unlawfully is trivially cheap.

No I don't think an IP based solution is any kind of "solution".

[julz]

all you've managed to do is swap the 'proof of work' system, which prevents gaming of the system, with a system that gives control to whoever can muster the largest resources in terms of IP addresses and virtual nodes.
Having scrapped the whole 'block' system - this 'arms race' would happen at a rapid rate, and even if there were a few competing botnets, control of the network would oscillate between them.
In short - your proposal sounds like a disaster, and suggests you've missed the point of the block system and proof-of-work.

Isn't that how it works anyway though? If an attacker manages to get 50% of the processing power of the network then he could potentially validate an invalid transaction (like creating bitcoins out of thin air).

If anything I would think that my system would be more secure, since an attacker would have to have 2/3 majority, not in terms of processing power but in terms of nodes. This security is inherit in the philosophy of bitcoins, and it depends on the philosophy that there will always be more genuine validators than attacker validators.

Well it's not *quite* how it works anyway. 
Yes it's a competition to throw resources at the problem - but the 10minute block system is an elegant way to determine who has contributed resources. The maths does it.
Your method wastes just as many resources - but also wastes bandwidth in determining how many nodes there are at any instant, and what proportion have validated what transactions.
so
a) you haven't solved the wastefulness regarding electricity and hardware-stacking anyway
b) you've introduced more wastefulness in terms of bandwidth.
c) you've thrown away the history and auditing system the whole thing relies on... so once someone has 2/3 majority under your system, they can rewrite not only events from that point onwards, but also the entire history.
d) you now have no mechanism for the currency distribution.
Your reward seems only to be transaction fees - so how did you propose to complete the distribution phase of the currency, which still has many years to run?

[tlhonmey]

To all of this add the fact that the proposed "solution" to question 3 doesn't solve question 3 since there would be absolutely no reason for anybody to start a node that wasn't a "validator" node.  Aside from the large bandwidth requirement that is...


The elegant solution for the question of how much the fees will be to devise a statistical tool for calculating how long it will take a transaction at a given fee level to be incorporated into a block given the fact that miners prioritise transactions based on fee level.  Once people have a way to see that, for instance, a fee of 1 will likely get a transaction into one of the next two blocks, and a fee of .01 will get it in within the next 10 blocks, and a fee of .0000001 will get it in sometime within the next year and a half, they will choose how much to pay depending on how quickly they need it done.  The system should find an equilibrium point from there.   

[Ente Erstickenfickër]

I attempted to post this on StackExchange, but was told to come here. So here it is:

I've been thinking a lot about bitcoins lately, and I've discovered some problems with the theory behind them.

1Q) How much will transaction fees eventually be?

2Q) There is a lot of wasted computational power, due to the requirement for "proof of work." Assuming they found a fix for #1, this would still drive the transaction fees to be a LOT higher then they would otherwise need to be.

3Q) Banking information is propagated freely to anybody and everybody. If you wanted to figure out how much money your friend (or worse, your enemy) has, and all of their transactional data, it really wouldn't be that hard. This isn't a huge problem, but this information ideally should be on a "need to know" basis.

After those questions came to mind, I did lots of research on the theory and did lots of thinking. I believe I have an extremely simple solution to all of these problems:

We redefine what it means to bitcoin mine. We scrap the entire idea of "proof of work," as well as blocks. All nodes that define themselves as bitcoin miners must now tell every other node that they are a miner, or "validator" if you will.

3A) When a client posts a transaction, that transaction is propagated ONLY to all validators, and NOT to other clients. Clients should not know about the transaction history of other clients.

2A) All validators must validate the transaction, and then post their results to all other nodes. If it is determined (by each individual node) that 2/3 majority of the validators have validated the transaction, then the transaction is deemed to be valid. There is no "proof of work" and clockcycles are no longer wasted.

1A) The reward (transaction fee) is equally split among all validators. Since each individual node knows how many registered validators there are, it can easily calculate a minimum transactional fee. Transaction fee = (time to process transaction) * (cost per time to process).

What do you guys think, does this make sense at all?

The responses here would have you believe that Bitcoin was cast in stone perfectly on the first try. The creator(s) of Bitcoin are nowhere to be found for their input, so practically speaking they not only cast it in stone but they threw away the design notes. The most intriguing assumptions in its design are likely to be the ones that won't be found in the Nakamoto paper, but we may never know what they were.

Under these conditions Bitcoin is less likely to be improved than it is to be abandoned for something else.

[casascius]

Whenever I see a post whose subject line says Bitcoin won't work, I automatically know their post count is in the single digits before I even look.

By the time their post count reaches the triple digits, they're converted and enthusiastic.

Welcome to the community in advance.

[ineededausername]

Whenever I see a post whose subject line says Bitcoin won't work, I automatically know their post count is in the single digits before I even look.

By the time their post count reaches the triple digits, they're converted and enthusiastic.

Welcome to the community in advance.

haha!  every once in a while you see these geniuses popping up in the newb forum thinking they know the answer to everything.  No offense to OP, but I've seen it a dozen times.