But what parts of the Bitcoin protocol would you change if you were starting from scratch?
the scripting language its just to complicated, and bloated.0_o
Topic: Design Flaws of Bitcoin That Could Be Corrected in Another Digital Currency (Read 2442 times)
October 17, 2011, 09:55:02 AM
0_o
October 17, 2011, 03:50:16 AM
But what parts of the Bitcoin protocol would you change if you were starting from scratch?
the scripting language its just to complicated, and bloated. October 17, 2011, 01:03:12 AM
As I've mentioned in multiple other posts... Addresses paired with an encrypted key file used to authenticate transactions.
Support for signing arbitrary data using bitcoin 'addresses' is in the current development code and 0.5 release candidate.
October 17, 2011, 12:10:53 AM
IMO, the value of stabilizing the currency would be enough to elicit a tandem response without forking.
October 17, 2011, 12:09:47 AM
As I've mentioned in multiple other posts... Addresses paired with an encrypted key file used to authenticate transactions.
I will probably suggest 100 more times. If you want btc to be taken really seriously, you have to find a solution to the fact that peoples money sits on their computer and is prone to possible brute force cracking. Sure the most savvy of us create layers of encryption and backups but eventually the currency must be easily transacted from anywhere and that may require dual wallet, verification key implementation. That way data lossmcan be mitigated because cloud/ served wallet services will only have the data for the transactions which will require a separate key to validate.
I will probably suggest 100 more times. If you want btc to be taken really seriously, you have to find a solution to the fact that peoples money sits on their computer and is prone to possible brute force cracking. Sure the most savvy of us create layers of encryption and backups but eventually the currency must be easily transacted from anywhere and that may require dual wallet, verification key implementation. That way data lossmcan be mitigated because cloud/ served wallet services will only have the data for the transactions which will require a separate key to validate.
October 12, 2011, 12:26:49 PM
A couple of things i'd change:
How are nine (9!) things counted as a couple?
Sorry, I couldn't help myself.
October 12, 2011, 12:23:18 PM
A couple of things i'd change:
1) Use SHA 256 throughout. The cryptography is only as strong as the weakest link, so I don't see a point in using a mix of RIPMED and SHA, now your venerable to exploits in two algorithms.
1) Use SHA 256 throughout. The cryptography is only as strong as the weakest link, so I don't see a point in using a mix of RIPMED and SHA, now your venerable to exploits in two algorithms.
Its the opposite. It would not be good idea to use SHA256 to keep your accounts secret while the whole network puts pressure to "crack" it as Proof of Work.
5) Remove coinbase. Use the previous block hash and timestamp as the entropy for the coinbase transaction.
That would result in doing the same work multiple times. Also, this prohibits merged mining.
9) Block rewards decrease to a minimum block reward of ~1 BTC, meaning no 21 million limit.
This does not scale well in case there is large Bitcoin adoption.
October 12, 2011, 11:57:37 AM
10) use the correct network byte order everywhere in the protocol
October 12, 2011, 11:16:30 AM
A couple of things i'd change:
1) Use SHA 256 throughout. The cryptography is only as strong as the weakest link, so I don't see a point in using a mix of RIPMED and SHA, now your venerable to exploits in two algorithms.
2) Implement changing hash functions as a part of the protocol e.g. each block would include a flag identifying what it was hashed with. Clients should have support for many hash functions, if a one is shown to be weak it can be phased out.
3) Make command uint8 - char[12] wastes 11 bytes every message.
4) Separate Address messages for ipV4 and ipv6. clients that support ipv6 can specifically request ipv6 addresses. No point in wasting 12 bytes for every ipv4 address.
5) Remove coinbase. Use the previous block hash and timestamp as the entropy for the coinbase transaction.
4) Version based on protocol changes, not any particular client.
5) Remove sequence from TxIn
6) No alerts (deprecated already)
7) PING should require another PING response.
Make transaction scripts optional, requiring extra fees. The majority of transactions would use hard coded signing methods.
9) Block rewards decrease to a minimum block reward of ~1 BTC, meaning no 21 million limit.
1) Use SHA 256 throughout. The cryptography is only as strong as the weakest link, so I don't see a point in using a mix of RIPMED and SHA, now your venerable to exploits in two algorithms.
2) Implement changing hash functions as a part of the protocol e.g. each block would include a flag identifying what it was hashed with. Clients should have support for many hash functions, if a one is shown to be weak it can be phased out.
3) Make command uint8 - char[12] wastes 11 bytes every message.
4) Separate Address messages for ipV4 and ipv6. clients that support ipv6 can specifically request ipv6 addresses. No point in wasting 12 bytes for every ipv4 address.
5) Remove coinbase. Use the previous block hash and timestamp as the entropy for the coinbase transaction.
4) Version based on protocol changes, not any particular client.
5) Remove sequence from TxIn
6) No alerts (deprecated already)
7) PING should require another PING response.
Make transaction scripts optional, requiring extra fees. The majority of transactions would use hard coded signing methods. 9) Block rewards decrease to a minimum block reward of ~1 BTC, meaning no 21 million limit.
October 12, 2011, 11:02:58 AM
Faster confirmations would be nice. Is that possible? Is there a price to pay for faster confirmations?
Not a design flaw. A few weeks ago there was a thread about all the things that break if you make confirmations too much faster than 10 minutes on average. And being even faster than that isn't really needed anyway.
October 12, 2011, 09:00:29 AM
I would make sure the guy who invented it didnt run off with a million coins.
Built in reward for early adopters was/is a really smart feature.
October 12, 2011, 08:57:08 AM
I'm asking. But if everything about Bitcoin can be changed, then there are no guarantees. If I buy BTC thinking the supply of BTC can not be changed to allow more than 21 million, I'm wrong. It could easily be changed to allow 21 billion, 21 trillion or more.
Faster confirmations would be nice. Is that possible? Is there a price to pay for faster confirmations?
Faster confirmations would be nice. Is that possible? Is there a price to pay for faster confirmations?
One of the strengths of Bitcoin is that it is very difficult to change. I've seen a few 'oh Bitcoin is easy to change if enough people agree' statements. That kind of agreement is possible if an existential threat were to arise, but there isn't going to be agreement to implement incremental improvements.
I think faster confirmations are a feature of some of the other alternative currencies. I imagine there is a trade-off there. Maybe network overhead/speed of confirmations.
The CPU-friendly currencies address the biggest design flaw of Bitcoin IMHO.
Not sure there's anything else I'd change. Everything else seems to have been exceptionally well thought out.
October 12, 2011, 08:55:11 AM
I would make sure the guy who invented it didnt run off with a million coins.
October 12, 2011, 08:42:41 AM
I'm asking. But if everything about Bitcoin can be changed, then there are no guarantees. If I buy BTC thinking the supply of BTC can not be changed to allow more than 21 million, I'm wrong. It could easily be changed to allow 21 billion, 21 trillion or more.
Faster confirmations would be nice. Is that possible? Is there a price to pay for faster confirmations?
Faster confirmations would be nice. Is that possible? Is there a price to pay for faster confirmations?
October 12, 2011, 08:05:26 AM
What type of flaws can't be addressed? If enough people agree on a solution, it shouldn't be difficult to simply fix the current system compared to creating a new one from scratch.
October 12, 2011, 08:02:37 AM
Are there any characteristics of Bitcoin which you consider disadvantages that can't be change in BTC but that could be changed in another digital currency? If another digital currency is going to replace Bitcoin I would think that it have to have advantages over BTC. Of course there could be external differences that could make another digital currency more desirable. For example, if a country were to issue it's own digital currency. But what parts of the Bitcoin protocol would you change if you were starting from scratch?
Jump to: