I've been in the industry for 6 years now, the UK/FCA has been nothing but a nightmare to work with on crypto front.

I think there is more ignorance than malice, they simply have ruined UK businesses to date and favouring only the larger banks.

Anecdotally, I know a couple companies who moved all operations and market focus outside of UK yet their entire dev teams still reside in the UK and won't service UK customers.

To say UK is crypto friendly is simply untrue unfortunately.

From UK banks I still hear the 'yay blockchain, yay cbdc, yay NFTs' because they have very poor advisors (managment consultants I think is the polite term) who blagged a senior position and talk with such confidence yet have no idea about the real economics or technical merits of the technologies.

Santander and one other that I can't name are somewhat ahead of these others though and now progressing on the lightning band wagon.

Meh, this is too easy... just bung it in ChatGPT and gives you the answer.   Soi easy I'm not bothered about claiming the money.


```
Certainly! Let's decode the riddle step by step:

"Start with a number, the Genesis it reflects, A marker of birth, where history connects."
The clue suggests that we start with a number related to Genesis. In computer science and cryptography, "Genesis" often refers to the first block or transaction in a blockchain. The most famous blockchain is Bitcoin, and the first block in the Bitcoin blockchain is called the "Genesis Block."

So, the number we need to start with is 1, reflecting the Genesis Block.

"Multiply by a prime, a factor divine, A clue to unravel, the path you'll align."
We need to multiply the number 1 by a prime number. Prime numbers are positive integers greater than 1 that have no divisors other than 1 and themselves. Let's consider the smallest prime number, which is 2.

1 multiplied by 2 equals 2.

"Next, find the sum of digits, a challenge awaits, Persistence is key, as complexity abates."
We need to find the sum of the digits in the number 2. Since 2 only has one digit, the sum is simply 2 itself.

"Reverse the result, a mirror's reflection, Digits rearranged, a cryptographic direction."
We need to reverse the result obtained in the previous step, which is 2. Reversing it gives us 2 again.

"Now take the ASCII, the text shall reveal, Letters hold power, a message concealed."
We need to convert the number 2 into its ASCII representation. In ASCII, each character is assigned a unique numerical value. The ASCII value for 2 is 50.

"Decipher the words, unlock the cipher, A key to the treasure, your victory will inspire."
We need to decipher the ASCII value 50 into its corresponding character. In ASCII, 50 corresponds to the character "2".

So, the final answer is "2".

Therefore, the solution to the riddle is "2".
```

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.

We all know QCs are being worked on but most likely decades away from being a danger to ECDSA used in Bitcoin... that said though, when that day does arrive, either due to QC or some mathmatical genius figures out how to break it, it seems prudent to have another signature system in the wings that people could opt to move their coins to.

I'd like to discuss the pros/cons of implementing lattice signatures in bitcoin now such that when ECDSA is broken it's an orderly transition to use a different lock on funds.

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.

In normal usage like we are today, no PoW for a Tx is required.  But if there is a systemic compromise of existing transactions, this PoW feature could be enabled by miners such that they only repeat a tx with PoW offered along side it.  This way even if the unlikely event of a large QC being made and used to attack the network happens, there is a plan on how people can safely move their bitcoin to an alternative locking mechanism.

Thoughts?

Let's pretend that a QC powerful enough now exists to break ECDSA within 10 mins.

Let's put on an "attacker hat" and see how it plays out...  

It's very unlikely an institution would do this due to it being illegal and the fine/lawsuits would ruin a company.  Therefore a single staff member is most likely to use a company's QC to attack the network... a bit like how people used to use company computers to mine with and later get caught.

The weaker, older "pay to public key" transactions would become the first victims.  Whilst this could include Satoshi's first minted coins, it's unlikely they would attack those early coins since any movement of long stored 50BTC tx's will always alert people.  Instead they'd focus on the most recent P2PK tx's and work backwards in time.

* Grab a P2PK tx and obtain the private key.
* Write down with pen and paper.
* Wipe or obscure the operation from QC history.

Manually construct the tx to another address, go to a coffee shop & VPN.. publish tx to a public home run node.
repeat, slowly and accelerate as getting more cocky that they got away with it.

So how is Bitcoin protected after such an attack?

This is the hardest part, we can't hard fork fix this since we wont know what is genuine and what is done by the QC.

Best fix I can think of is addressing the issues...
1. Add a quantum resistant signature system to Bitcoin
2. Require PoW for any transaction submitted to the node.

Ideally step 1 should be done now.   We don't need to use this new signature system but it should be ready to swap to.
Step 2... at a point when QC is believed to have compromised bitcoin, we require PoW of CPU power before accepting a transaction.  The transaction must pay to a QC resistant tx.
The PoW should be significant but not too much.  E.g. 1 hour's worth of PoW of the hash(nonce + signed TX).
The result of the PoW could be put in an OP_RETURN call or even a new OP code.

This way it becomes expensive for an attacker to steal too many coins and valid owners can use their laptops or mobile phones to issue transactions.

Hard to see how this would be rolled out in practice but P2WPKH happened so if there is a demand it could well be done.

This is one of the few reasons why I would back a custodian service to hold bitcoin in escrow.
Having that sort of money on your phone is insane, what happens if there's a zero day exploit on the phone? Putting a large amount like that into cold storage used to be sensible but now it's a terrifying concept of having a password worth that much in your home.

I think it's inevitable that at some point in time something will break ECDSA.. I mean there's a pretty good incentive to find a solution to it so is a matter of when and not if.  QC or not.  The issue is how does cryptocurrency (and every other crypto related sector) survive.  It's pretty easy in my mind, it's no different than that bug where billions of bitcoin were printed once upon a time... it's a hard fork where new code fixes the issue.

So here's how I'd see it playing out.

Assumption 1.
Most likely it's the public keys in the chain that get compromised first as that's a lot easier than P2PKH style transactions where you need to derived a private key and script that matches the hash.

Assumption 2.
It takes a period of time to do P -> k solution (i.e. > 10mins).

With those assumptions we would likely get early indications of a compromise.  Early satoshi coins move, large accounts compromised to move the market, etc..
An update to the chain could be put out that offers a new signature system. 
If the attack is convincing that either a QC or fundamental crack has happened, a certain block number (even in the past) could be used as the reset point.

Everyone who wants to adopts the new hardfork.  Yes we have the BTC/BCH rubbish again but this is part of the bitcoin evolution process.  Strongest mining is 'the bitcoin' chain, so only through decentralised concensus is that reached.

Next anyone who wants to spend from an OLD tx has to also provide some PoW on their provided signature.  This means a simple GPU running for say a day does enough PoW to state they are the owner of the signature.  This would prevent even a compromise or QC attack from spending everyone's coins since they'd still need to do PoW for every tx they try to steal.

I'm sure there are even better ways to approach this but my approach is not to worry as we can always rollback and be inventive even on the worst possible attack imaginable.

I love this project because it is a heater foremost but also simple and easily introduces people to bitcoin with only using 1kW of power... no need for 3 phase or crazy loud setups.

Yes it's a hefty price right now and not for industrial earnings, but at scale this should be much cheaper and put that heat to actual use.

I got into Bitcoin because it was simple and accessible, these days it's freakin' difficult to setup a node + lightning + safely store a wallet + trusted exchange/banking support.  I mean it's tough right now but will get better as more tools like this one bring bitcoin back to the general population without having to understand wtf grpc and macaroons are.

Has it actually been confirmed that Luke had his money moved yet and that it isn't just his PGP key and twitter are compromised?

I'm somewhat surprised he hasn't already posted here to give a bit of an update as to what may have happened so people can help figure it out.

Luke, care to share any update please?

Many thanks for the reply, can I just clarify how I can do this.

Firstly I've not used wallet descriptors before so this might be a daft question but this bit here...


I initially read that as do a shell script with a custom wpkh executable but now not sure.   Is it shell script or is this something in the wallet descriptor format I should be learning about?

If I have an xpub key (well ypub, but same thing) from my Trezor and I want to query this coldstorage balance using bitcoind... I can't see an obvious way to do this and feel I must be missing a trick as surely everyone does this?

In absence of bitcoind allowing an xpub key query directly, I believe we can generate a bunch of addresses from the xpub key and was planning on asking bitcoind via rpc calls the balances of these addresses however this doesn't seem straight forward.  Firstly it requires rescanning which seems like it would be unworkably slow as addresses are generated all the time.  Secondly it would indicate another bitcoin node (or at least another bitcoin wallet) would need to be created since it would conflict with my hotwallet.

I see many sites do offer exactly this capability so looking for help on how to do this.

I don't want to use any external API service like blockchain.info or trezor.io since I want to actually do this using our own tech stack.

Any help/pointers really appreciated. 

(We use node.js as a backend if anyone happens to know any node modules that may help too.)

Thanks,

Thanks all, much appreciated.  Will try the electrum verification route first as it was a real hassle doing the offline transaction safely last time so rather not have to do that again but may need to if the tx fees are too low like you say.

Would like some help on a weird question...

I have an old transaction I generated about 2 years ago on an offline computer however I never published it.  The intention was that I'd keep this transaction and post it in future when I want to access the paper wallet funds.

It was to transfer 0.1 BTC from my paper wallet to my hardware wallet address.

I've not spent the paper wallet and my hardware wallet is still the same, is there any risk in publishing this old transaction? 

Is there a date/timestamp in there that may cause miners to reject it and/or cause it to linger in the mempool meaning I can't spend it for some reason if this fails?

Thanks, you might be right!  I will have a gander... 
Thank you again!!

Would anyone be interested in writing this?  I am happy to pay (in bitcoin).  PM a quote and I will select someone.  Happy to use escrow if that gives reassurance.
Thanks

I'm looking for a self contained JS module that will take a key in hex string form such as


and allow creating a public key via EC to give


and create a signature via ECDSA such that I can do...

and finally allow verify



Basically a really easy JS module that has these simple methods all taking hex strings as input

•   create_private_key_hex_string();
  
•   derive_public_key_hex_string( k );
  
•   create_sha256_hex_string( message );
  
•   sign_hash( msg_hash, k );
  
•   verify_hash( signature, msg_hash, pubkey );

Ideally so it works in all browsers and in node.js.


Any suggestions or anyone willing to make it?  

It just needs to work easily in all browsers and in node.js and not require babel or dependencies.

If you need this feel free to PM me and I can put you in touch with a few professionals who do this.  They will want to meet via skype and have payment made via escrow as this is their fulltime professional job...

Great site, hope it stays up to date as this information seems to change quickly...

Thanks for sharing, great to have all in one place

Looks interesting, looks very well made so far.