pull down to refresh
@Murch
stacking since: #127838
102 sats \ 0 replies \ @Murch 12 Dec \ parent \ on: Making Bitcoin Speak Human - Spiral Blog bitcoin
Using BIP 353 does not require you to type the Bitcoin symbol.
However, on my phone, I have set up an autocorrect rule, when I type “BTCSYM”, it replaces it with the Bitcoin character. On my computers, I input the unicode: U+20bf.
On Linux, you enter unicode symbols by hitting Ctrl+Shift+U and typing the code, there are probably similar ways to do so on other operating systems.
Note that BIP 54 does not talk about transactions of 64 bytes, but rather proposes to forbid “Transactions whose witness-stripped serialized size is exactly 64 bytes”.
Still, perhaps I can alleviate you of some of your sadness: it seems very unlikely that anyone will come up with useful stripped transactions of 64-byte size.
Bitcoin transactions have to have at least one input, at least one output, and the header bytes. Without the witness data that leaves us with:
Header
- version: 4 byte
- locktime: 4 byte
- input count: 1+ bytes
- output count: 1+ bytes
Usually 10 bytes, unless you have a lot of inputs or outputs.
Input
- outpoint:
- txid: 32 bytes
- vout: 4 bytes
- input script length: 1+ bytes
- input script: 0+ bytes
- sequence: 4 bytes
In sum that’s at least 41 bytes, and that is for a transaction with an empty input script.
Output
- amount: 8 bytes
- output script length: 1+ bytes
- output script: 0+ bytes
At least 9 bytes, even with an empty output script.
In Sum
So, a transaction with an empty input script and an empty output script already puts you at 60 bytes, and that means that you’d have to distribute a total of four bytes into input script and/or output script to land at exactly 64 bytes.
The only standard types of transactions that I can think of that would be affected have a single native segwit input (who have empty input scripts), and either a single P2A output (which has a 4 byte output script) or an OP_RETURN output with a 2-byte payload. The former transaction would pay all its money to fees or make it up for grabs per an anyone-can-spend anchor. The latter would pay all its money to fees, or burn it per the OP_RETURN output. Neither seems seem useful to me, but either could evade the block by simply increasing the payload by one byte (e.g., introducing another standard pattern for P2A with three bytes, if it is used frequently). So, we would fix a consensus bug at potentially introducing a 1-byte penalty to a couple tx patterns that don’t seem useful at this time.
Yes, but this is a separate issue. The UTXO set is a way of presenting current state of the Bitcoin network with the minimal necessary data.
libbitcoin simply chooses to store more data than that, whereas utreexo introduces a framework where other nodes can prove that some UTXO exists and is spendable. Everyone still needs to agree that these UTXOs exist and are spendable.This proposal seems to delegate the authority to declare some UTXOs unspendable to some underdefined process/council. Basically, it proposes a framework to regularly softfork out some UTXOs at the whim of whoever gets to author that blacklist.
Edit: Oh, I see. You mean that the motivation for the fork is poor. — I agree with that.
Secp256k1 is defined over a finite field. Only most, but not all of the 32-byte numbers are valid x-coordinates of public keys. If all three public keys were not on the curve, it would be obvious that the TXO is unspendable, but alas, if the key is on the curve, we cannot distinguish whether the private key is known or not.
So, for most we cannot, but my understanding is that the way stamps are interpreted according to those that wear these particular colored glasses, they only read the latter two public keys as data.
The perfidious aspect of Stamps is that they are spendable. They’re 1-of-3 bare multisigs, where the first public key is an actual key and the other two public keys are used to embed data. They cannot be pruned, because they could be spent later, and when they are, the network may be split if nodes evaluate the spend inconsistently as valid or invalid.
This soft fork is like bluffing with a high card at poker while your opponents can see your hand in the mirror behind you.
At least in past years, the program expected participants to solve coding challenges in the first week, so while it may be open to anyone you might find that the pace hard to keep up with, if you're just starting out with programming.
It’s a frequent question we get on Bitcoin Stack Exchange: if a block gets reorged, what happens to the transactions in that block? Do they all get unconfirmed and returned to the mempool?
And the important thing to realize there is, that from the perspective of each chaintip the other block might as well not exist. The best chain has only one block at each height, so competing blocks do not at all influence each other in regard to what is included.
Most of the time two competing blocks at the same height will include almost exactly the same transactions with some minor differences in what txs they had seen when they created their template, or some locally prioritized transactions. Obviously, the coinbase transactions will differ, and very occasionally, one block could include a replacement of a transaction while the other block included the corresponding original. But because miners try to maximize the revenue from the available mempool, they pick all the same transactions, and for the most part, either both blocks or neither confirm a transaction, so it makes no difference for the users which block wins out in the end.
Addendum:
Obvious exceptions are of course when someone is deliberately reorganizing the chain to revert a previously confirmed transaction, or when a reorg is so deep that coinbase transactions matured on both chaintips and said coinbase outputs don’t exist on the competing chains, so a reorg could remove whole chains of transactions from the history.
That’s right, the only way the network would converge back on a single chaintip without intervention would be if the soft forking chaintip outpaced the non-enforcing chaintip and the non-enforcing nodes reorged to the soft fork chaintip.
This is highly unlikely when only a minority of the hashrate enforces the soft fork.
That’s a correct description of what would happen if the hashrate moved that way, but an unlikely scenario.
It’s the best practice to only start enforcing soft fork rules if they are expected to be enforced by a majority of the hashrate, exactly because a minority-enforced soft fork leads to a chain split. It would be against the interest of the miners on the heavier chain to switch to the minority-enforced soft fork chain, as they would be sacrificing their block rewards. Similarly, starting to enforce a soft fork with a minority of the hashrate most likely means that the block rewards will never become part of the best chain and therefore likely to incur the whole cost of mining with no reward.
In effect, anyone proposing to activate a soft fork with a minority chain is essentially advocating to create a forkcoin.
Was the double negative on purpose there, or did you mean “if less than 51% are enforcing the new rules”?
There are just two cases:
- If a majority of the hashrate enforces the soft fork, the non-enforcing minority may occasionally find a block considered invalid by the majority, but the soft fork enforcing majority will ignore such a block and eventually build a heavier competing chaintip at which point the minority will reorganize to the majority chain.
- If only a minority of the hashrate enforces the soft fork, it will create a permanent fork as the minority will not accept the non-enforcing majority chaintip and the majority chaintip will accumulate more work faster. The majority chaintip will simply pull away and the enforcing miners will be stuck on a less-work chaintip.
I imagine that conveyor belts outside would be hard to maintain and get dirty rapidly. I do like Factorio as well, but walking seems mostly fine.