Any BTC node experts out there to answer a tricky question?

[NoahA]

So I was thinking the other day about this, and by asking, I will either expose my ignorance, and/or also perhaps learn something that I'm missing.

So here is the setup. You set up a bitcoin node, and it downloads all the transactions and your computer has to verify every block. It is my understanding that each transaction is checked to make sure there are no double spends, etc, in addition to performing a hash of the block to make sure no data has been changed.

Now, some people run a pruned node so this way, you aren't storing over 500Gb of data. This pruned node still has to download the whole thing for the initialization, but then it can delete the old blocks.

But here comes the question. When it comes to MultiSig setups, the script details how the bitcoin has to be unlocked. So it is my understanding that when a transaction comes in for a certain UTXO, the node will go find this UTXO, read the script of how it was locked, and then look for the signatures to make sure that the conditions of unlocking are met. (ie. 2 signatures of 3 are produced)

But here is the question. What if the coins are years old, and hence in a block that the pruned node already deleted? How will your node verify this transaction? Maybe your node is just doing a hash of all the transactions in the block and making sure this hash matches up with the proposed hash to ensure that nothing was shared. So maybe its the miner who has to verify the fact that UTXO is unlocked properly and hence those coins can be moved. So maybe the nodes aren't actually verifying the individual transactions, but I thought they were. It likely has to be this way of else there would be no way to look up the locking script for pruned blocks.

Hmmm.. I think I just answered my own question.... LOL

 

[johnarb]

The Bitcoin nodes will reject the transaction broadcasted if the digital signature is not correct

How do digital signatures work

Iow, before the transaction will be accepted into the mempool, the Bitcoin nodes have to accept it in the mempool and the Bitcoin miners will be able to include or not include in the block

The Bitcoin miners usually have a preference of including the highest fees transactions, but some miners are able to fast track txid's, in the past, some of the mining pools have a service online you input your stuck txid waiting to be confirmed and if the mining pool is the successful one for the block, your transaction will be confirmed. Most of them did not charge a fee

I've never ran a pruned node, but the 500GB blockchain are already confirmed transactions

Mempool is the list of pending transactions (I'm pretty sure you knew this already)

Also, before everything else, the local Bitcoin wallet will not allow you to initiate the transaction, i.e. sign the transaction and broadcast on the p2p network tcp 8333 if you don't have all the private key requirements

194 unconfirmed blocks of transactions. Thank you Ordinals! lol

https://mempool.space/

PS: utxo's stored on a Bitcoin address can be unlocked with the corresponding private key multisig or not

there is no need to look up old private keys valid for originating utxo's. The mere presence of those utxo's in the current address have already proven that they were validated transfers in the past

 

[NoahA]

That's an excellent link.

Yes, I can see how nodes will reject it, but each node has a copy of the mempool, so each node has to reject it, which would also mean the pruned node.

But even in the link, at no point in the flow chart is there reference made to looking up the locking script of the original UTXO by the network. I know my wallet software will do this. Before I can spend a multisig UTXO, it will ask for at least 2 signatures for example, and once provided, it will create this transaction and make the message to broadcast with the hash. But you would think that once its broadcast, every node now needs to look up the locking mechanism of that UTXO to make sure I'm using the right private keys.

It just seems to me like in this flow chart, something is missing.

 

[NoahA]

I guess what I'm trying to say is this. Imagine a journalist is covering a war conflict. She shows photographic evidence of piles of bodies and rubble, an obvious bomb of some sort has gone off. She uploads all of this to her news organization so that its published. Along the way, we can verify that those pictures are legit, right from her camera. They aren't altered in any way, because we can check to make sure the image is taken and not created via some AI image generator. We can verify the picture she sent is the same picture that is received. So the picture is 100% authentic.

But what we really can't verify is if those bodies weren't placed there. We need to somehow go back in time to see what happened at the time. Maybe if there is a CCTV camera that recorded the blast at the time, then we can be certain of the explosion. But all the evidence she is providing is the picture she took after the fact, and that picture is legit, but the picture doesn't capture the evidence of the explosion as it happened, just the supposed aftermath.

Likewise, it just seems to me like these nodes should be looking up the original UTXO and reading the locking script. Just because I produce a signature to say I can move these coins with this signature and produce a hash of this proof, it seems to me like everyone first needs to verify via the original locking method used. And then we can see that yes, 5 years ago these coins were locked with a 2 or 3, and I need to see at least 2 of these exact signatures. Now I can see that these 2 signatures in the message are in fact 2 of the signatures that could have been used.

 

[johnarb]

That's an excellent link.

Yes, I can see how nodes will reject it, but each node has a copy of the mempool, so each node has to reject it, which would also mean the pruned node.

But even in the link, at no point in the flow chart is there reference made to looking up the locking script of the original UTXO by the network. I know my wallet software will do this. Before I can spend a multisig UTXO, it will ask for at least 2 signatures for example, and once provided, it will create this transaction and make the message to broadcast with the hash. But you would think that once its broadcast, every node now needs to look up the locking mechanism of that UTXO to make sure I'm using the right private keys.

It just seems to me like in this flow chart, something is missing.


View attachment 317249

I don't use a multi-sig (yet)

So, I'm not an expert on this, but the way I understand it, a multi sig-private key is simply a private key that can be derived by combining 2 ore more private keys

So, let's say public address 88888 containing 2 btc's from 4 utxo's has a private key of 15 (that no one knows, it's one of those numbers that is bigger than the number of all the atoms in the universe)

So, 15 is the private key but to get output functions of the private key 15 , you need Bob's private key and Alice or Bob and John or Alice and John

So, let's say through some math calc when Bob is combined with Alice, Bob is a 7 and Alice is 8 = 15

when Bob is combined with John Bob is 6 and John is 9 =15

Alice doesn't know Bob's private key nor John's private key, only when combined do they produce the proper output of a private key 15 that is unknown to anyone in the universe

And the wallet uses 15 as the private key (without ever knowing this number) to sign the transaction and send it out along with the public key details

The nodes do the hash function and they don't know the private key is 15, but the signature matches the public key for address 88888

I saw on a video something about MPC utilizing a secret private key that might have some relation to this process

So, TL;DR, there is only one private key that unlocks the utxo's but the nodes don't care or don't know the private key was single or multi sig, all they know is that private key output matches the public key in the digital signature

That's the way I understood it from years ago when I looked into it, but I could be totally off

 

[NoahA]

That's the way I understood it from years ago when I looked into it, but I could be totally off

Its an interesting suggestion. I kind of this though that private keys aren't combined.

Here is what I do know after some reading. We know that you only need 2 or 3 keys to move coins, but this is if you have the working wallet. If you need to reconstruct the wallet, then you need all 3 keys again. Having just 2 or 3 keys won't reconstruct the wallet if you don't have a backup. So all 3 keys are used to make XPUBs and derive addresses and all that jazz. But when it comes to unlocking, I would assume that each key has to be used on its own.

And here is why I think this. If you have a 12 out of 15 setup, which is I think what they have for major companies from what I read, there would be too many combinations to add up. In your example, it makes sense to use 15, and this is what the hash need to match. But each different combination of signatures would produce a totally different hash.

So I don't think it can be the case that the node already knows the answer its looking for in order to match. The signature for the address can come from so many different combinations.

I think I should finally go start an account at bitcointalk.org and see how they all shoot me down over there!

 

[johnarb]

Its an interesting suggestion. I kind of this though that private keys aren't combined.

Here is what I do know after some reading. We know that you only need 2 or 3 keys to move coins, but this is if you have the working wallet. If you need to reconstruct the wallet, then you need all 3 keys again. Having just 2 or 3 keys won't reconstruct the wallet if you don't have a backup. So all 3 keys are used to make XPUBs and derive addresses and all that jazz. But when it comes to unlocking, I would assume that each key has to be used on its own.

And here is why I think this. If you have a 12 out of 15 setup, which is I think what they have for major companies from what I read, there would be too many combinations to add up. In your example, it makes sense to use 15, and this is what the hash need to match. But each different combination of signatures would produce a totally different hash.

So I don't think it can be the case that the node already knows the answer its looking for in order to match. The signature for the address can come from so many different combinations.

I think I should finally go start an account at bitcointalk.org and see how they all shoot me down over there!

Btw, my PS on my first reply was trying to make sure that blockchain is committed truth (confirmed transactions, utxo's et al) is immutable

Think of the Blockchain as the bible, infallible and always correct

I'm only saying this as you have mentioned going back to utxo's in the past and validating those signatures, and stuff, that would be a waste of time and computing power. Just take them as gospel, as truth

Pruned node or not, they know the blockchain is the abosolute truth

The battle is on the mempool and what is to be recorded on the next block. We don't want someone creating a million bitcoins with made up utxo's not verifiable on the blockchain

and within the mempool, there is a double spend detection if a utxo is being spent on multiple transactions

 

[johnarb]

And here is why I think this. If you have a 12 out of 15 setup, which is I think what they have for major companies

This is a high-risk setup

Four of the private key holders traveling on private jet that crashes, bitcoins gone forever

Four private key holders going to a company retreat or conference and a fire breaks out, bam, bitcoins gone forever

Read the Bitcoin Billionaires book on how the Winklevoss twins setup their private keys backups able to withstand location disasters

I don't think multisig was available in 2012-13

They used shards recorded on paper stored in bank safety deposit boxes, that cannot be used without some combinations from other shards

Fascinating, but who knows if they still have the same setup. They owned 1% of all the bitcoins that will ever exist (probably much more now) during that time they got into bitcoin 210,000 btc's and it only cost them less than $2M from what I remember

 

[NoahA]

I'm only saying this as you have mentioned going back to utxo's in the past and validating those signatures, and stuff, that would be a waste of time and computing power. Just take them as gospel, as truth

I'm not sure what you mean here. Each new node needs to go to the very beginning and verify everything for itself. Even a pruned node which will delete most of these will still need to verify everything for itself.

Pruned node or not, they know the blockchain is the abosolute truth

This is only because they verified themselves!

The only reason why I mention going back to previous blocks was simply to look up the locking script.

The reason why I'm obsessed with this is because I'm worried about either a) someone accidently generating the same seed (yes, I know, mathematically almost impossible), and b) more security. If I have my backup seed phrase and someone finds it, I'm fucked. But of course if I lose my backup, I'm also fucked. If I create multiple backup copies, how on earth am I going to make sure none of those are ever found accidentally? So in a way, it makes way more sense to create a 2 or 3 multisig, and therefore, there isn't a single point of failure with one seed being compromised. This way, having multiple backups of each seed isn't as risky, and having multiple backups of each seed will ensure that losing one backup isn't catostrophic.

 

[NoahA]

Read the Bitcoin Billionaires book on how the Winklevoss twins setup their private keys backups able to withstand location disasters

I will absolutely search for this... but I swear, I read somewhere that some company has this setup of roughly 11 out of 14 or something crazy like this.

I don't think multisig was available in 2012-13

I just saw this amazing thread on the various address types, and in here, they state multisig came in April 2012. (its actually a very interesting thread, and especially to read the distributions of coins in the different address types)

https://twitter.com/x/status/1668678551380303882

Funnily enough, this is also in this post....

"P2SH creates an address by putting a redeem script (rather than a public key) through hash functions, and the redeem script contains the instructions for how the bitcoin can be spent later."

So this is what I'm going on and on about. You need to look at the redeem script in order to spend the UTXO. Having a hash of it just simply means I think that you can verify it hasn't been changed. But in order to read the instructions, I would think you need to read the script.

Its like a will. Maybe you make a will, hash it, and give all your relatives the hash. Then when you die, each relative gets a copy of the will. They can hash it themselves and verify that every letter is the same. So they know the will hasn't been changed. But having just the hash doesn't tell them what's inside. They still need to open the will and read it.

OMG... this is the perfect analogy for what I'm trying to say!!!! No estate could start distributing the assets of the will by just knowing that everyone verifies the will as being authentic. They still need to read the will (ie. the locking script)