SIGHASH precedence for multisig?

[gmaxwell]

You can sign a vin properly by multiple signers and get multiple signatures, each with a different sighash. What I assumed incorrectly was that all signers of a specific vin have to use the same sighash. Can you show me where it says that the same vin can be signed by different signers using different sighashes?

Generally the "says" is that you can signal it. Not that the bitcoin protocol is always a paragon of perfect design, but it should generally not be possible to signal something that shouldn't work-- when thats possible it reliably leads to bugs. so it shouldn't be done without good reason. Being able to control sighash per signature is pretty useful.

But fair enough; I just wanted to make sure you weren't confused in more profound ways, but I follow your thinking now.

I am making the iguana be able to be a lossless codec that uses half the space with the sigs and able to purge the sigs to get a 75% reduction in size, I estimate about 15GB size for the dataset without sigs. Do you see any reason for a non-relaying node to keep around sigs that have already been verified?

There isn't-- though Bitcoin Core can already do this. It can run a full node, with transaction and block relaying (but not serving historical blocks) with less than 2GB of space; this isn't a default behavior yet because we have not yet implemented mechanisms for nodes to retain and locate random chunks of the history so that nodes can collectively support other nodes bootstrapping.

[jl777]

You can sign a vin properly by multiple signers and get multiple signatures, each with a different sighash. What I assumed incorrectly was that all signers of a specific vin have to use the same sighash. Can you show me where it says that the same vin can be signed by different signers using different sighashes?

Generally the "says" is that you can signal it. Not that the bitcoin protocol is always a paragon of perfect design, but it should generally not be possible to signal something that shouldn't work-- when thats possible it reliably leads to bugs. so it shouldn't be done without good reason. Being able to control sighash per signature is pretty useful.

But fair enough; I just wanted to make sure you weren't confused in more profound ways, but I follow your thinking now.

I am making the iguana be able to be a lossless codec that uses half the space with the sigs and able to purge the sigs to get a 75% reduction in size, I estimate about 15GB size for the dataset without sigs. Do you see any reason for a non-relaying node to keep around sigs that have already been verified?

There isn't-- though Bitcoin Core can already do this. It can run a full node, with transaction and block relaying (but not serving historical blocks) with less than 2GB of space; this isn't a default behavior yet because we have not yet implemented mechanisms for nodes to retain and locate random chunks of the history so that nodes can collectively support other nodes bootstrapping.

For a while I was definitely profoundly confused, but debugging the code has a way of clarifying things.

And the whole sequenceid not really doing much, but the docs do say it doesnt really do anything.

Anyway, onward and upward, I am glad the pace of bitcoin improvements is much faster now.

I plan to implement parallel sync support to other iguana nodes based on each bundle (2000 blocks), would need to include the sigs so it can be verified, but after that each non-relaying node can just purge it and save half the space. I am assuming only sigs after block 290000 need to be verified as long as the checkpoints match, or should all sigs be verfied?

James

[amaclin]

I am assuming only sigs after block 290000 need to be verified as long as the checkpoints match, or should all sigs be verfied?

Up to you. Bitcoin is voluntary system.
You have a right not to check signatures at all.

[jl777]

I am assuming only sigs after block 290000 need to be verified as long as the checkpoints match, or should all sigs be verfied?

Up to you. Bitcoin is voluntary system.
You have a right not to check signatures at all.

If I use the block 290000 checkpoint to skip verifying sigs prior to that, could I still claim to be a fully validating node? (without being inaccurate)

[amaclin]

If I use the block 290000 checkpoint to skip verifying sigs prior to that, could I still claim to be a fully validating node? (without being inaccurate)

What is a strong definition of "fully validating node"? (without referring to Satoshi client)
What would you do in case of reorganizing the mainchain from the block #289999? from the block #200000? from the block #1?

[jl777]

If I use the block 290000 checkpoint to skip verifying sigs prior to that, could I still claim to be a fully validating node? (without being inaccurate)

What is a strong definition of "fully validating node"? (without referring to Satoshi client)
What would you do in case of reorganizing the mainchain from the block #289999? from the block #200000? from the block #1?

I am assuming I dont have to worry about bitcoin reorganizing 100,000+ blocks. Do I?

[gmaxwell]

If I use the block 290000 checkpoint to skip verifying sigs prior to that, could I still claim to be a fully validating node? (without being inaccurate)

I think it would be inaccurate to call a node that cannot validate the complete original rules of the system a full node.

Also, Bitcoin Core plans to remove that mechanism entirely. It no longer provides a useful performance improvement on most systems; and right now is really only preserved because it prevents some corner case DOS attacks (ones unrelated to signatures).

I am assuming I dont have to worry about bitcoin reorganizing 100,000+ blocks. Do I?

You don't have to do anything. But a complete and correct implementation of Bitcoin's rules will handle this. Bitcoin core can reorganize back to block 1 just fine (though will refuse to do so while checkpoints are enabled).