Quote from: NotATether on Today at 09:01:08 AM

Quote from: s2 on Today at 08:52:01 AM

I'd also like to suggest that we add an optional PoW on a transaction submitted to a node so that when someone submits their transaction they can provide a PoW of that Tx alongside to the node to show they really want the tx to be included.

This will not work, because computers and smartphones are not ASICs and they can't possibly be expected to create a hash for transactions. Besides, this will require a complete rewrite of the bitcoin protocol, which is so used to the methodology: transactions --> blocks.

So hear me out on this one...
The PoW for the tx does not necessarily enter the blockchain (it could be a segwit bit of data but actually is easier just reuse the actual signature and keep resigning such that the signature is the tx PoW nonce)

With this change, all bitcoin wallets and nodes continue as they are. No change need.

Doing a SHA256(tx) however gives a normalised value to test for PoW.

Now if we (a node) see a system compromise, we require the SHA256(tx) value to be less than 1/1000000 * 256 bit value, we can be relatively confident the issuing wallet has done a certain amount of pow on that tx for it to be issued.

Why?

This is an emergency brake that bitcoin node operators could optionally enable if there was a system wide compromise. It gives bitcoin owners time to issue their own tx with a local PoW to move their funds to a QC safe or uncompromised signature system.

Yes each wallet would need an option to 'create a tx with PoW' but it seems this would distribute the work to the wallets/clients so a system wide attack vector is reduced.

If nothing else, it would be interesting to include a PoW check on itself within the script

Whilst everything remains as is and no chain split or major technical change is needed, it does give an emergency option to migrate to an uncompromised signature system.