If someone doesn't understand why mining and ECDSA signatures are part of that solution (or even what makes something a "public key" or "private key", and comes in with "Lets get rid of ECDSA and use SHA256 to prove authorized access to bitcoins!", they are wasting their own time, and the time of every person that accidentally reads their post. I'm not going to waste time explaining all the many technical details to someone that is clearly more interested in announcing their amazing discovery than trying to learn.
I think we should give this guy a chance and proof him wrong.
This may sound silly or even genius, and I am not a big expert or cryptographer, but as I look at it, the public->private key system is 1 directional, so why do we need to use ECDSA when we could just use a SHA-256 instead or something like that. Lemme explain my theory, how we could make a blockchain without ECDSA:
- Private key generated with RNG, then hashed with SHA256, the SHA256 hash , this would be the pubkey, and a Base58encoded checksumed version would be the bitcoin address
- Bitcoin address and bitcoin private key included in blockchain at spending, so miners can verify the owner without the need for asymmetric cryptography, the private key would be revealed when you send money to a new address, so this way addresses will be forcibly reused, and would no longer serve as "accounts" but only as a receipt of transaction
- The public key would be sent first ,and after 6 confirmations, the private key is sent, this would ensure that nodes/miner cant steal/double spend the coin. The pubkey gets indexed in the blockchain, after 6 confirm the private key gets indexed too ,and after another 6 confirm the transaction is finalized
- If nodes/miners reject the public key and is not included in the blockchain, then the user would not send out the private key (the private key revelation is the finalization of the transaction)
- The change would be sent back to the owner's change address, fee sent to miners, and the sum sent to the destination address
- Mining protocol not affected
- A lot of unnecessary work would be eliminated for both nodes and miners
- More efficient cryptocurrency model
- When you would sign a message with the address, it would automatically send the money from that address to a new address of yours, so that a message signing would still prove that you own that address, but the money need to be sent to a change address to ensure that the verifier doesnt stea it
- Ultra secure, quantum secure, since we would no longer be constrained by a 128 bit private key, but by even a 1000 bit key by using numbers, letters, special characters to generate the private key, it would be way more secure
What do you think of my idea? Did Satoshi miss this thought?
You are saying that you would wait for 6 confirmations and then send the private key. However, anyone could just pretend to own the private key while the network cannot verify that you own the private key. This means that it did not matter how many confirmations you have waited as your transactions only becomes worthy once it can be verified (in your case once your private key is revealed).
As such, problems arise which others have described.
Scenario 1: Mallory sends 1 BTC from Alice address. Mallory is an attacker and actually do not control Alice address (private key) but I can still make the transaction as the pub key is visible e.g. base64decode address. After 6 confirmations Mallory is doing nothing. I suppose in your example you would probably state that the transaction becomes invalid after e.g. 12 transactions without revealing the pubkey, which is fine - no funds are lost for Alice in this example, but way lay the groundwork for the next.
Scenario 2: Alice sends 1 BTC to Bob (Transaction 1). Transaction 2: Mallory impersonates Alice (can be easily done as per Scenario 1) and send 1 BTC to himself. After 6 confirmations Alice reveals her private key. Meanwhile Mallory established a Man-In-The-Middle between Alice and himself. Mallory does not forward the private key to the network for Transaction 1, instead Mallory will forward the private key of Alice to the network for Transaction 2. Since there is no signing in you scheme this can easily be done. Mallory will continue to block Alice until e.g. 12 transactions as per Scenario 1. After this point all funds are forever lost for Alice.