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

[johnarb]

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 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)

I guess what I'm trying to say is that if the current address is trying to spend utxo's, why would we need to verify how the source utxo's going back all the way back to when the bitcoins were first mined?

Along the blocks and along the transfers, some were multi sig, most were not, and trying to decode every single one of those seems frivolous or useless, since they were recorded on the blockchain they were already verified at that particular time and instance

Take all the recorded utxo's on the blockchain as valid, is what I'm saying. Yes, verify them through hisotrical records on the blockchain if spending on the current mempool, but accept they are valid

Mempool and the next block is the battleground. Any invalid utxo's cannot be recorded on the next block

We're probably not seeing eye to eye but agree on the fundamentals, haha

 

[NoahA]

I guess what I'm trying to say is that if the current address is trying to spend utxo's, why would we need to verify how the source utxo's going back all the way back to when the bitcoins were first mined?

Along the blocks and along the transfers, some were multi sig, most were not, and trying to decode every single one of those seems frivolous or useless, since they were recorded on the blockchain they were already verified at that particular time and instance

Take all the recorded utxo's on the blockchain as valid, is what I'm saying. Yes, verify them through hisotrical records on the blockchain if spending on the current mempool, but accept they are valid

Mempool and the next block is the battleground. Any invalid utxo's cannot be recorded on the next block

We're probably not seeing eye to eye but agree on the fundamentals, haha

I think I see the confusion. I'm of course not saying everything has to be verified over and over. All I'm saying is we need to be able to read transaction for the current address from when they were recorded. If they were locked in 2013 when multisig first became available, the locking script is in that transaction. So if you want to spend the coins now, I figured we now need to read that locking script, which would be in a block from 2013. But if your pruned node already threw that out, how would you read the instructions for unlocking?

So maybe what I should be saying is we need to be able to look up the locking script, not verify the transaction. The transaction is fine and has been verified, but in order to move the coins from the address now, we need to look up the locking script and now verify that the private keys trying to move these coins are in fact the keys that we said were necessary when we made this new address 10 years ago.

 

[johnarb]

I think I see the confusion. I'm of course not saying everything has to be verified over and over. All I'm saying is we need to be able to read transaction for the current address from when they were recorded. If they were locked in 2013 when multisig first became available, the locking script is in that transaction. So if you want to spend the coins now, I figured we now need to read that locking script, which would be in a block from 2013. But if your pruned node already threw that out, how would you read the instructions for unlocking?

So maybe what I should be saying is we need to be able to look up the locking script, not verify the transaction. The transaction is fine and has been verified, but in order to move the coins from the address now, we need to look up the locking script and now verify that the private keys trying to move these coins are in fact the keys that we said were necessary when we made this new address 10 years ago.

Ok, cool, I finally understand what you're saying that the locking method could be in 2013 and multisig

Look, as I said I don't use multisig (yet) so I'm not an expert, but this is my opinion of the process as shown by the diagram

The local (multisig) wallet is the responsible component to unlock the utxo's and sign the transaction

The nodes all see a transaction with details of amount and addresses with a digital signature, they run a hash function on this and it should match the hash function of the public key being referenced in the transaction details

The nodes do not know how the digital signature is derived whether it's through single private key or multi sig

The diagram shows this

So I think the confusion is that you think the local multi sig wallet will sign a transaction with muliple private keys and the nodes that receive the transaction need to verify the multi sig private kays are valid

But here's the million $ question for you? How would the nodes verify if the private keys in the multi sig (or even in a single sig) are valid?

The nodes do not have access to the private keys

Only the local wallet contains the private keys, single or multi sig

 

[NoahA]

Look, as I said I don't use multisig (yet) so I'm not an expert, but this is my opinion of the process as shown by the diagram

I don't know anything either! But I wonder how different the diagram would look for a multisig transaction.

So I think the confusion is that you think the local multi sig wallet will sign a transaction with muliple private keys and the nodes that receive the transaction need to verify the multi sig private kays are valid

But here's the million $ question for you? How would the nodes verify if the private keys in the multi sig (or even in a single sig) are valid?

The nodes do not have access to the private keys

Only the local wallet contains the private keys, single or multi sig

And in reply to this, my million dollar question is, if the nodes don't know its a multisig, why does multisig even exist at the node level? It wouldn't need to be in the locking script to begin with. But since each byte costs money to add to a transaction, it has be to be critical. The multisig transactions take up more room, and from the samples I've seen of the code, the data specifies that its a multisig transaction, and you need m of n signatures, and then it goes on to list the public keys or addresses or whatever it is of all the participants involved. I therefore think that this has to be critical for when it comes time to spend this UTXO.

So its true the nodes don't know the private keys, but I think the nodes have to know that they need to see multiple signatures.

 

[NoahA]

Ok.. I'm getting closer... but I need to read this over several times and really think about it... I underlined and made bold the critical part I think....

https://unchained.com/blog/bitcoin-address-types-compared/

P2SH
Pay-to-Script-Hash (P2SH) was introduced to bitcoin as a soft fork in accordance with BIP 16 on April 1, 2012. Like most forks, the story behind it is fascinating. P2SH shares a lot in common with P2PKH. The main difference is that the address is created by hashing a redeem script instead of hashing a single public key.

A redeem script can be thought of as coded instructions specifying how bitcoin received to the P2SH address can be spent in the future. There could be a wide range of possibilities, including multiple different public keys. The receiver, not the sender, determines the script details, and the spending instructions are not exposed publicly until bitcoin is spent out of the address.

While advanced users can construct complex scripts, the most common uses for P2SH have been to create Nested SegWit addresses (covered below) and multisig wallets. For example, a script can include three public keys and specify that signatures from any two of the corresponding private keys can spend the bitcoin. This would create a 2-of-3 multisig address.

P2SH addresses are exactly 34 characters in length, and they begin with a prefix of 3, as specified by BIP 13. Before the soft fork on April 1st, a handful of transactions experimented with this alternative prefix, the first of which is found in Block 170,052.

 

[johnarb]

IAnd in reply to this, my million dollar question is, if the nodes don't know its a multisig, why does multisig even exist at the node level? It wouldn't need to be in the locking script to begin with. But since each byte costs money to add to a transaction, it has be to be critical. The multisig transactions take up more room, and from the samples I've seen of the code, the data specifies that its a multisig transaction, and you need m of n signatures, and then it goes on to list the public keys or addresses or whatever it is of all the participants involved. I therefore think that this has to be critical for when it comes time to spend this UTXO.

So its true the nodes don't know the private keys, but I think the nodes have to know that they need to see multiple signatures.

I think there are multiple components being conflated or interchanged

Local wallets can be full nodes

Bitcoin nodes don't care about fees, miners do

for example you can pay 1 satoshi per byte, does not mean the miners will confirm the transaction, I believe after a couple of days of unconfirmed, the bitcoins go back to the wallet

In the past you can initiate a transaction with 0 fee, but that might have been over 5 years ago, newer Bitcoin wallets won't let you do it

So, nodes care if the transaction is properly formed, the signature matches the hash of the public key, they don't care if you pay a low or high fee for the size of the data consumed by the transaction

The mempool is is congested now, to get to the next block it's estimated you have to pay more than 15 sats/vByte, but if you configure your wallet to pay 1 sat/vbyte, it's going to be accepted by the nodes into the mempool

There's a lot of reasons the size of the transaction is bigger, not just due to multisig, it can be because you're using multiple utxo's from several addresses as inputs for the transaction, or having ordinals inscriptions

As long as the transaction is properly formed

But it's cool that you're diving deep into this, I basically never thought much about all of these, only my experience from using the wallet, doing coin controls, and adjusting the fees based on how congested the mempool is

PS: come to think of it, having had to use multiple utxos from multiple addresses, never thought about it much but those would require proper signatures for each of the source wallet addresses involved in the transaction

 

[NoahA]

PS: come to think of it, having had to use multiple utxos from multiple addresses, never thought about it much but those would require proper signatures for each of the source wallet addresses involved in the transaction

Yup... this is a really good point as well!

 

[johnarb]

Chiming in again, just some thoughts related to the title "BTC node..."

When I first got into Bitcoin in 2013, there's always an encouragement to run a full Bitcoin node... and also to mine bitcoin

These 2 are the most important ways to support the Bitcoin project, and buying and hodling bitcoins is actually not as important as those

In fact, if you own bitcoins but do not run a full Bitcoin node or mine bitcoins, you are considered a parasite or a freeloader, unless you support in other ways, of course, like running a website for Bitcoin education, or running a business that accepts bitcoins as payment

I've always run a full Bitcoin node, especially the bitcoin-qt core wallet that holds most of the bitcoins I own(ed). And I've mined bitcoins in the first few years

I also use SPV-wallets for small amounts that are for spending. My choice was Bitcoin wallet by Schildbach on Android phones but I've moved to Electrum as I can run it on Android or desktop OS

Nowadays, everyone pushing for hardware wallets like Trezor, Ledger, and other hardware wallets that are not full nodes in the name of "security"

Anyways, back to a full Bitcoin node... Even running a full Bitcoin node has a nuance, i.e. whether to open tcp forwarding port on your router to let other Bitcoin nodes connect to your Bitcoin node?

Running a full Bitcoin node but not opening up the router is ok, but.... (for more info on this, there's discussions on reddit)

So to put it all together with the premise of the thread, pruned nodes and how it affects the behavior on the Bitcoin network when old(er) blocks are not on the local copy of the blockchain

I don't run a pruned node but I always run a full Bitcoin node (over tor - Umbrel node - good for ISP traffic censorship, traffic shaping) as stated in the beginning, this is 1 of the 2 most important ways to support the Bitcoin project, with the other one as mining

On the Bitcoin network, my node has full participation in the consensus protocol, the full security enforcement of the rules

SPV-wallets do not have this level of participation... a full Bitcoin node that is not open for others to connect (i.e. router port forwarding or firewall permissions) will have less participation

A pruned node might have somewhere in the middle of the 2 above and if that is the case, there really would not be a problem if it is unable to verify certain components of the Bitcoin protocol and would be a passive participant on the network, listening from other full Bitcoin nodes for updates to apply to its local copy of the blockchain

My 2 satoshis opinion uninformed on multisig nor pruned nodes

 

[NoahA]

These 2 are the most important ways to support the Bitcoin project, and buying and hodling bitcoins is actually not as important as those

I understand what you mean, but I think buying is just as important. I have also heard that using it is also important. Simply HODLing isn't enough. The network needs transactions. In some respects, ordinals are actually helpful. Jesus, for a few days there, the miners were getting just as much in fees as the block subsidy!

Everyone thought its a bad use of blockspace, and sure, this may be true, but I like the idea of letting the market decide everything. Clearly these guys will run out of money soon if they keep spending 6 BTC or more per block for their crap. And sure enough, it seems to be gone.

So the importance of transactions I think cannot be overlooked.

Nowadays, everyone pushing for hardware wallets like Trezor, Ledger, and other hardware wallets that are not full nodes in the name of "security"

I would not be comfortable having my keys on the computer. I love that I can use a hardware wallet, currently using a Jade, in fully airgapped mode with just QR codes. Plus, using Bitcoin Core, I don't think it will produce seed phrases.

I remember how you said you have your wallet file encrypted and backed up... and I can see benefits to this setup as well. But its certainly more tech focused I think and not for the average user.

Anyways, back to a full Bitcoin node... Even running a full Bitcoin node has a nuance, i.e. whether to open tcp forwarding port on your router to let other Bitcoin nodes connect to your Bitcoin node?

Running a full Bitcoin node but not opening up the router is ok, but.... (for more info on this, there's discussions on reddit)

This is I think the problem I'm having. Months ago, if you recall, I was asking for help because I can't get any incoming connections. I gave up on it. But now that I have a source for KYC free sats, I'm stacking this in a new wallet, using my Jade, and want to use Sparrow Wallet with my own node. But I'm sure I need to get Bitcoin Core setup for handling both incoming and outgoing connections for this to work properly.

The thing I like about this as well is that with just sharing my XPUB with Sparrow, it can generate all the receive addresses, and since I'm just stacking, I never need to access the Jade in order to spend. This way, there is literally no way I can fuck something up on the software side and accidentally lose the bitcoin. If I was using the wallet in Bitcoin Core, I'm sure I would find a way to fuck it up and expose my private keys. I am running the node on an older laptop, but its still a windows machine, and I have no interest in switching operating systems. I just need to figure out the damn router issue.

My 2 satoshis opinion uninformed on multisig nor pruned nodes

I have another issue to pick your brain. I love this guy's videos. Been following him on Twitter for a while and he started a channel to upload his content. Here he shows how to use RBF. I link to the part where he just finished increasing the fees for a 3rd time in order to get it into the next block faster.

Now here is the thing. I know that miners take all the transactions they like, the high fee ones, and start mining a block. The first miner to get a solution that satisfies the difficulty level wins that block. Once this block is mined, those transactions are in the block, and everyone starts mining the next block. So they take all the next transactions waiting and get to work.

But here we see him bump up the fee, and in less than a minute, the block is mined. But I figured that with him changing the fee, it means that it can't be in the block that is currently being mined. It takes 10 minutes to mine a block, and if your transaction isn't being worked on, you can pay a higher fee to get it in the next one. But once that block starts getting worked on, I didn't think anything can be changed because that would change the hash, and this hash is what everyone is working hard to solve. I know each miner would have a slightly different block, since they all have different transactions, but I would think that if you swap out a transaction, then you would be starting all over again with the hashing.

So I don't understand how he can change the fees, and in less than a minute its confirmed. I can see his transaction going into the next block, so that block can start getting mined, but once again, I figured that it would take at least 10 mins (of average). How can a miner already be mining a block, but then accept a high fee transaction, when this would completely change the hash of the block that they are working on?

 

[johnarb]

I understand what you mean, but I think buying is just as important. I have also heard that using it is also important. Simply HODLing isn't enough

Yes, buying, spending, then re-buying the same amount or more is encouraged and supports the growth of the Bitcoin network adoption

It's not a black and white topic. Simply buying and hodling also takes out supply, supports NGU, which has a second order effect of more adoption

Buying also leads to spreading the message of digital gold, hard money, sound money

I would not be comfortable having my keys on the computer. I love that I can use a hardware wallet, currently using a Jade, in fully airgapped mode with just QR codes. Plus, using Bitcoin Core, I don't think it will produce seed phrases.

I saw a on a YouTube video that there is an Android software that can be used as an airgapped signer, you can remove the wifi on the phone, and of course no sim, so you can create the transaction on a computer and then sign it with the Android phone that contains the private key(s) and have your node broadcast on the network. These are all documented features on the bitcoin core qt console or the bitcoin core cli client

But all these complexities add risks even if you think you know what you're doing. There have been a lot of bitcoins lost as miner fees due to the messing around

https://www.coindesk.com/markets/20...-bitcoin-this-mining-pool-is-looking-for-you/

As you know, when you spend (transfer bitcoins) all the balance is sent and the excess (i.e. spending 0.5 btc and input utxo's total 1.25 btc) to a change address

This is a different behavior than Ethereum or other non-bitcoin fork crypto coins

This is I think the problem I'm having. Months ago, if you recall, I was asking for help because I can't get any incoming connections. I gave up on it

Just be aware of OpSec risks

It is trivial to find out all the ip addresses that have incoming tcp 8333 open and if that IP address is on your home router, there may be some bad guys that may find that info useful if you are geographically accessible to them and may pay a visit for one of those wrench exercises

Even limiting to only outgoing tcp 8333 (i.e. firing up the bitcoin wallet) have its own set of security risks. Your ISP or its employees can be paid to produce a report, by whom? who knows, gov, bad guys mentioned above, or an ISP employee with desperate needs, too much in debt with the local mob due go gambling but tech-savvy enough to know the value of Bitcoin and cryptos

Consider using a VPN or a proxy setup on the bitcoin wallets

At the minimum, a Bitcoin full node should be run on tor (and/or vpn) or if on clearnet a solid vpn setup

---

I love RBF, my wallets are setup for it. It's an optional flag, but merchants hate it, lol. Every time I pay a Bitpay invoice, it complains that I have RBF turned on and it should be changed to off

mempool.space is a wonderful resource

When you make a Bitcoin transaction, you can copy and paste the txid on mempool and you can see which block your transaction is expected to be mined

If your transaction is pushed to let's say 3 or 4 blocks away due to low fees, you can use RBF, pay additional fees, there's a minimum the wallet will suggest which you can increase if you really really want to be confirmed on the next block

RBF is signaling protocol on the mempool. As soon as you initiate the RBF transaction, the txid with the lower fee becomes "invalid" flag

I don't have an RBF transaction right now, so I cannot show you the details as displayed on the blockchain explorer (like mempool.space)

Replace by fee is exactly as it says. Most of the time it can be used to speed up an existing transaction stuck in the mempool.... but it can also be used to change the destination address, which is why merchants and payment processors hate it

B1trefill will actually credit your account (in good standing) with 0-confirmations, but if you have RBF turned on, they of course will not

To summarize, RBF is accepted protocol signaling on the mempool, it cannot be used do double-spend as it still follows the rules of no extra utxo's being spent/created