Topic: Some Problems I See With Bitcoins (And A Proposed Solution) - page 2. (Read 1912 times)

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.

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?

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. 

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

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.

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.

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.

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.

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?