pull down to refresh
Yes. The pre BIP-110 chain can always be wiped out again and again even if it gets ahead momentarily, while the BIP-110 chain cannot be wiped out when it falls behind.
To neuter this effect a counter-softfork would need to be deployed. Thence the lowest friction to a miner is to go with a soft fork.
I don't really see that angle. If he didn't like the consensus rules he'd be proposing new ones, no?
What you describe doesn't sound really much different from old school bearer gold certificates, i.e. gold-backed paper money.
We know the game theory leads to EO 6102.
Exactly. The "luck fund" of an FPPS pool doesn't necessarily exist at all, but the promise of stable payouts regardless of the pool's luck is still there.
This is probably one of the reasons why in recent years so many FPPS pools have become AntPool proxies.
https://mainnet.observer/charts/mining-pools-centralization-index-with-proxy-pools/
Fair enough. I indulged in a tad too much of clickbait on the title because the content is dense and I didn't want it to go unnoticed.
Love me some damage control with my morning coffee.
The beauty of primary sources is that they cannot "smear" or "slander", they're just records. Anyone willing to make the effort can go read what actually happened 10 years ago, contrast what they read against Peter's claims and come to their own conclusion.
My thoughts exactly. And a big part of why I went through the trouble of collecting all these primary sources and put them up in a post.
Sure, no one is right 100% of the time. I agree with you that attempting to hardcode a blacklist in the code for the SatoshiDice address was retarded.
But Todd's post and mine are about datacarriersize. It has nothing to do with that.
This is just a collection of historical sources.
Feel free to click on the links and verify the information found therein against Peter's claims.
Forgot to address the second question: by design multisig wallets already are watch-only. Because they contain at most one of the required signing keys (if you use a hot key) or even zero (if your signing key lives offline). The rest are xpubs.
I've done this a few times using both Sparrow and Nunchuk.
The only requirement is that signers share the xpub of their own seed with all the other signers. In our case we used PGP for that.
If you want to hold a hot key: Open Sparrow and create a new Native Segwit Multisig wallet. In Keystore 1, choose New or Imported Software Wallet and enter your seed or generate a new one. After importing it copy your xpub and share it with the other signers. As each signer sends you their xpub fill them in the other keystores with the same derivation path that Sparrow chose for your keystore: m/48'/0'/0'/2'. The order of the keystores doesn't matter, every signer could create their wallet sorting their xpubs differently and you'll all still get the same wallet, but of course double check that everyone see the same addresses. When you're done send a small utxo to the first address and try to spend it to the next address, and only if you succeed proceed to moving more significant funds to the multisig.
If you want to hold a cold key: Import your seed on a SeedSigner or the HWW you want to use, then export the xpub as a Native Segwit Multisig wallet and scan the xpub QR with Sparrow. The other steps are the same.
Nunchuk: create the full wallet in Sparrow first, then click in the QR button of the wallet descriptor and scan it with Nunchuk.
VERY IMPORTANT: the usual derivation path for a Native SegWit singlesig wallet is m/84'/0'/0', but for Native SegWit multisig is m/48'/0'/0'/2'. Pay a lot of attention here, because the xpub you get is different in each case. If one of the signers shares a singlesig xpub with the group the wallet will be invalid but the software won't warn you, and you'll burn sats if you send them to these addresses (ask me how I know). I highly recommend trying the setup in testnet first (the derivation path is m/48'/1'/0'/2' in testnet).
Good luck!
Good read.
Reminded me of The Politics of Obedience, a libertarian essay written 472 years ago. Same core idea.
To give a clear-cut definition of spam this common misconception that "transactions bid for blockspace" has to be dispelled first:
Transactions bid for (more or less timely) confirmation, not space in blocks.
In fact "purchasing blockspace" is an undesired side effect to real Bitcoin users. If a new type of address was introduced whose transactions were half the size of the current ones a lot of users would adopt the new format just to pay half the fees at any given feerate. If you could confirm your transaction by purchasing no blockspace at all you would (and that's the idea behind LN: a single onchain tx supports a theoretically infinite number of offchain balance updates of that tx). This dynamic leads to a virtuous cycle where tx footprint gets smaller, users pay less fees, and so more users can use the chain.
On the other hand spammers are true purchasers of blockspace, something that Bitcoin is not designed for (and thanks to the SegWit discount they even get a 4x cost reduction byte per byte). This leads to a vicious cycle where only just a few spammers can quickly purchase all the available blockspace, spike the fees and so less people can use the chain.
Bottom line, since the legit group of bidders want to minimize their purchase of blockspace, while the spammers want to maximize it (and even gets a discount) there's only one possible outcome that we've already seen plenty of times: denial of service. Obviously all that is immaterial to the fees. If someone paid 10 bitcoins in fees to inscribe a hi-res video over the next 1500 blocks as one huge tx per block, that's still spam.
Running
invalidateblockin the manner you described is a consensus rule change (soft fork, introduction of a new rule) that targets RDTS, so.. Yes, that's what I meant.