Pages:
Author

Topic: Why is ECDSA needed at all? - page 2. (Read 3585 times)

legendary
Activity: 3472
Merit: 4801
October 20, 2016, 11:52:34 AM
#11
What arrogance? I don't see any.

He was just stating facts.

OP doesn't know what he's talking about. That's all.

I try to be a bit more tolerant in the "Beginners & Help" and "Bitcoin Discussion" sub-forums.  Those are filled with newbies that just want to talk about bitcoin related stuff.  I have no expectation that they have any particular level of knowledge about any technical details.

I'm much more critical of threads in the "Development & Technical Discussion" and "Technical Support" sub-forums.  These sub-forums are intended for discussion at a technical level about how bitcoin works and realistic improvements.  If someone wants to post in either of these sub-forums with questions trying to actually learn and understand, then I'm happy to take the time to explain what I know and discuss their ideas.

But when someone comes in with the equivalent of "Lets put windmills on our electric cars so that they can generate electricity and power themselves while we're driving!  Then we can drive thousands of miles without needing to plug in!" 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 wind resistance, conversion losses, and thermodynamics to someone that clearly is more interested in announcing their amazing discovery than trying to learn.

Equivalently, cryptocurrencies are something that has been studied and investigated for several decades.  There are many ideas that have been clearly proven  to not work, and many issues that had to be overcome.  Bitcoin was the first decentralized trustless cryptocurrency system that manages to address some of the biggest issues. 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.

legendary
Activity: 3416
Merit: 1912
The Concierge of Crypto
October 20, 2016, 10:59:23 AM
#10
Arrogance and intolerance like this is what will kill bitcoin eventually so please adjust your attitude or say nothing at all.
There is nothing of merit that can be learned from this type of response and as a Legendary member it is an atrocious example to set.
What arrogance? I don't see any.

He was just stating facts.

OP doesn't know what he's talking about. That's all.
full member
Activity: 217
Merit: 259
October 20, 2016, 10:45:58 AM
#9
A different problem with your approach is that everyone can spam the blockchain for free by sending loads of unsigned transactions that don't belong to him.  Your algorithm requires them to be included in the immutable blockchain before the miners can even start to check if the sender authorized them (including the fee).  Since one doesn't even have to own bitcoins to do this, one doesn't lose anything when spamming.
full member
Activity: 217
Merit: 259
October 20, 2016, 10:37:40 AM
#8
The problem is, what if someone else sends the transactions with your public key.  Of course, you don't send the private key, but how do you unfreeze your funds.  Does it timeout?   What if some-one DoS attacks you by sending another transaction in the moment it timeouts?

If it timeouts, the miners may also steal your coins by claiming that you didn't send the private key, wait for the timeout and then mine a different transaction with your revealed private key.

You may think you can have three one-time functions, private key -> public key -> address to avoid the first problem.  Then only you know the public key and can send the first transaction. But that also doesn't help, either.  The moment you want to spend your coins some peer may use the information to double-spend the coins.  The miners don't know which to include and may include the wrong one.  Then you are back at the situation where the honest person has to somehow convince the miners to switch to a different transaction.
full member
Activity: 219
Merit: 102
October 20, 2016, 09:22:39 AM
#7
What do you think of my idea?

I think you don't know much about cryptography, you don't understand why the bitcoin protocol does the things it does, you don't understand the concept of decentralized and trustless, and your idea has too many holes in it to give much consideration to.

Arrogance and intolerance like this is what will kill bitcoin eventually so please adjust your attitude or say nothing at all.
There is nothing of merit that can be learned from this type of response and as a Legendary member it is an atrocious example to set.
legendary
Activity: 3472
Merit: 4801
October 19, 2016, 07:30:25 PM
#6
What do you think of my idea?

I think you don't know much about cryptography, you don't understand why the bitcoin protocol does the things it does, you don't understand the concept of decentralized and trustless, and your idea has too many holes in it to give much consideration to.
staff
Activity: 3458
Merit: 6793
Just writing some code
October 19, 2016, 06:56:17 PM
#5
What if the private key is sent after 6 confirmations? So the public key is indexed in the blockchain , and after 6 blocks the private key is sent and then the transaction would be finalized.

So that no node & miner could steal / double spend the coins, gets indexed to the blockchain, and then the private key is revealed, finalizing the transaction and confirming the spending.
Ok, so then how do you plan on verifying the signature? What algorithm are you going to use that takes a private key and then verifies to the sha256d hash of that key without revealing the key itself? You most certainly aren't going to be using ECDSA since ECDSA requires a public key derived from the private key in a different way using elliptic curves.

What do you mean by "finalized"? What happens if the key that is published is incorrect? What if the sender refuses to publish the key?
legendary
Activity: 1260
Merit: 1168
October 19, 2016, 06:34:38 PM
#4
Quote
Ultra secure

Just don't do it  Grin
Public key cryptography is there for a reason ...
hero member
Activity: 854
Merit: 1009
JAYCE DESIGNS - http://bit.ly/1tmgIwK
October 19, 2016, 06:28:55 PM
#3
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:


  • 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 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're wrong.

ECDSA is a signing algorithm that has specific requirements (all signing algos have specific requirements). It needs a public key derived from the public key in a specific way using a specific elliptic curve. The signature verification algorithm requires that specifically derived public key.

Your idea of publishing the private key when you send is also a bad idea. This is because the private key gives anyone who holds it permission to spend the UTXOs associated with the address. Once the private key is revealed after the Bitcoin is spent, while the transaction is unconfirmed, someone can retrieve that key and create a double spend and send the Bitcoin to himself instead of the intended recipient. A malicious miner could do this as well and ensure that he gets the Bitcoin because he is the one to include his double spend into a block.

What if the private key is sent after 6 confirmations? So the public key is indexed in the blockchain , and after 6 blocks the private key is sent and then the transaction would be finalized.

So that no node & miner could steal / double spend the coins, gets indexed to the blockchain, and then the private key is revealed, finalizing the transaction and confirming the spending.
staff
Activity: 3458
Merit: 6793
Just writing some code
October 19, 2016, 06:24:04 PM
#2
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:


  • 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 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're wrong.

ECDSA is a signing algorithm that has specific requirements (all signing algos have specific requirements). It needs a public key derived from the public key in a specific way using a specific elliptic curve. The signature verification algorithm requires that specifically derived public key.

Your idea of publishing the private key when you send is also a bad idea. This is because the private key gives anyone who holds it permission to spend the UTXOs associated with the address. Once the private key is revealed after the Bitcoin is spent, while the transaction is unconfirmed, someone can retrieve that key and create a double spend and send the Bitcoin to himself instead of the intended recipient. A malicious miner could do this as well and ensure that he gets the Bitcoin because he is the one to include his double spend into a block.
hero member
Activity: 854
Merit: 1009
JAYCE DESIGNS - http://bit.ly/1tmgIwK
October 19, 2016, 06:16:53 PM
#1
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?
Pages:
Jump to: