Topic: random transaction checking (Read 695 times)

It's not two transactions, it's one transaction plus the number of inputs transactions and their merkel paths. However, if you're asserting that an input simply doesn't exist there is no compact proof for that currently (though one could be added with an additional commitment). Proving things like "coinbase takes too much subsidy" also requires additional data. I enumerated many (most?) of the things that need additional data to be proved a long time back: https://en.bitcoin.it/wiki/User:Gmaxwell/features#Proofs

SPV header checks

Proof of invalid script

Proof of double spend

Proof of false inflation
Proof of block too large

Proof of spending a non-existing input

The overhead of that would significantly reduce any efficiency gains.

Is that a real world test of some static verify the same signature with a key in memory?

The reason I ask is because throughput on block verification seems to be more than three orders of magnitude slower than that.  Yes block verification has some other overhead be we aren't talking about rounding errors.  Or is it that bitcoind implementation is just very inefficient?

libsecp256k1 does over 40,000 ecdsa verifies per second on a desktop class quad-core cpu. I suspect any need for accelerators may be over-blown.

The overhead of that would significantly reduce any efficiency gains.

This would have to be combined with fraud proofs.  If you find a badly signed transaction, you have to be able to tell all the other nodes about it.

Revisting this topic.   While changing the protocol to allow transactions with implicit public key recovery is worthwhile it would be a breaking change so I understand not moving on this.  However there is absolutely no reason for the Bitcoin-Core client to require an address when verifying the signature.  The PubKey can be recovered from the signature the PubKeyHash produced from that and then the address generated from that.  

Can anyone think of any reason why the Bitcoin client requires the user provide the address (something it can and already does compute)?
I would add the UI in the core client for this section is not user friendly.  A user verifying signature has to copy and paste three separate components into three different boxes (one of which is pointless).  How about a unified copy and paste of a single signed message block?
Why not have the user supply the message & signature (preferably in a unified encoded form (i.e. similar to PGP signed message) and then the client verifies the signature and computes and displays the results?

An example which puts it all together.

Input

and the client responds with either
Message verified to be signed by 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T

or

Message not verified.  Please double check signed message is copied in it entirety including the BEGIN and END lines.


Brainwallet.org has something similar and is more intuitive than the Bitcoin Core client.  Still even the brainwallet website adds a "warning" that is pointless and vague.

Message verified to be from 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T (but address was not found in the signature!)

The address is not found in the signature?  Is that bad?  Should I be worried?  Am I being scammed?  To most users, yellow is a color of caution.   The expected outcome would be a definitive "SUCCESS" (and green) but instead there is this ambiguous partial success.  The "yellow" response is pointless as anyone can add the address in after the signature is created to remove the warning.  So what is is warning about.  Adding the address 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T just above the signature looks like this and provides the expected "good" response.

Message verified to be from 1JwSSubhmg6iPtRjtyqhUYYH7bZg3Lfy1T

The "caution" response only undermines the point of even allowing signatures that don't include the (unnecessary) address.  Imagine you are a company which sends out signed messages to customers.   Lets use the 80/20 rule.  If you exclude the address 80% of your users will understand the "warning" is pointless however that means you are going to confuse 20% of your customers and that means extra cost and work.  So why not just include the (pointless) address so it shows up as green.

Still the behavior isn't as bad as the core client which refuses to validate the signatures and throws an error.

This one.  If each client checks a randomly-selected one-third of all transactions, each transaction would still get checked thousands of times and we'd be running considerably faster.

Change the software so that not all clients have to check all signatures. This was raised in https://bitcointalksearch.org/topic/m.94314 in the context of speeding transaction propagation.