Search content
Sort by
Showing 8 of 8 results by polaker
1) I noticed that the version number could be different for blocks. How could we introduce a new version number by soft forking?
A soft fork isn't required to use a different version number. Some numbers cannot be used, but, for the most part, miners can set whatever block version number they want. This is what allows them to use the version number to signal soft fork readiness and also allows them (unfortunately) to use asicboost.Does this mean that version number actually is not part of the consensus rule, since miners could set whatever version number they want?
⭐ Merited by ETFbitcoin (1)
I got these questions while reading the protocol doc.
1) I noticed that the version number could be different for blocks. How could we introduce a new version number by soft forking?
2) Why doesn't it use compact Int to save bytes?
1) I noticed that the version number could be different for blocks. How could we introduce a new version number by soft forking?
2) Why doesn't it use compact Int to save bytes?
⭐ Merited by ETFbitcoin (1)
Yes, the scriptWitness is malleable.
While you could malleate a transaction to be larger, I'm not sure why you would. You can't change the fee that is paid by that transaction, so your malleated one would have a lower fee rate than the original, so it would most likely be rejected in favor of the original. That also means that the malleated transaction is less likely to show up in a block than the original transaction. Additionally, such malleation would make the transaction non-standard, so most nodes would discard it regardless of whether they had seen the original.
While you could malleate a transaction to be larger, I'm not sure why you would. You can't change the fee that is paid by that transaction, so your malleated one would have a lower fee rate than the original, so it would most likely be rejected in favor of the original. That also means that the malleated transaction is less likely to show up in a block than the original transaction. Additionally, such malleation would make the transaction non-standard, so most nodes would discard it regardless of whether they had seen the original.
Since the original transaction and the malleated transaction have the same transaction id, the mempool will accept the first it receives, right? Will mempool compare the fee rate for transactions with the same id?
Users do not have any motivation to malleate the transaction. Just some malicious relaying node could do that. I admit that it's not a big issue in practice.
⭐ Merited by ETFbitcoin (1)
With segwit, now the transaction id is not malleable. However, I could still modify the witness part during relaying and make the modified transaction still valid. Am I missing something here?
A potential attack is to make the block size larger by making the witness script larger?
A potential attack is to make the block size larger by making the witness script larger?
Re: Can I/Miners spend an output with anyone-can-spend public script?
Does this mean that by default anyone-can-spend scripts are disabled and cannot be used?
AFAIK it's the opposite.
Since segwit is a soft fork, what would happen if a miner treats some of the segwit outputs as anyone-can-spend scripts (as pre-seg scripts) and spend them in a new block?
Most Bitcoin full nodes (whether it's run by miner, exchange or regular user) would reject such block because there's no valid redeem script or the UTXO is invalid.
Then I don't quite get the point of "Wallets should be wary of any-one-can-spend scripts"
Can I/Miners spend an output with anyone-can-spend public script?
As I am reading BIP 141, there is a sentence saying "Wallets should always be wary of anyone-can-spend scripts and treat them with suspicion."
Does this mean that by default anyone-can-spend scripts are disabled and cannot be used?
Since segwit is a soft fork, what would happen if a miner treats some of the segwit outputs as anyone-can-spend scripts (as pre-seg scripts) and spend them in a new block?
Does this mean that by default anyone-can-spend scripts are disabled and cannot be used?
Since segwit is a soft fork, what would happen if a miner treats some of the segwit outputs as anyone-can-spend scripts (as pre-seg scripts) and spend them in a new block?
Let's start with something obvious,
1. Maximum Bitcoin script is 40000 weight (or 10000 bytes before SegWit activiation)
2. Non-turing complete Opcode
1. Maximum Bitcoin script is 40000 weight (or 10000 bytes before SegWit activiation)
2. Non-turing complete Opcode
I meant to compare P2SH with all other possible Bitcoin scripts. My bad, I did not express it clear enough.
The first point about script size still stands. Is there any good&useful example on-chain that uses many bytes close to the limits?
Thanks!
I just got this thought experiment in my head: can we live only with P2SH?
I like the succinct P2SH approach. It sounds perfect if all the scripts could be done in this way.
Let's ignore segwit for this experiment
I like the succinct P2SH approach. It sounds perfect if all the scripts could be done in this way.
Let's ignore segwit for this experiment