The fact that witnesses are push only makes the witnesses for many common scripts non-malleable, but you're correct for other scripts.

One of the motivations for annex in taproot is being able to later add a field that sets the weight of a transaction (which must be greater than or equal to the actual weight) which gets covered by a signature to address the point you were thinking of, among other reasons.

The Bitcoin protocol shouldn't be specified by invitation private meetings.

Typical consensus rule changes usually take a couple years to mature.  By trying to fast track things you are doing exactly what hearn did with bloom filters.  I hope Bitcoin has matured to the point that when someone overloads proposal bandwidth the response is just "no" rather than letting it happen.

Bitcoin development right now barely has the bandwidth to be even minimally responsive to basic bread and butter stuff.

There is a *single* proposal.  It has three parts, for engineering/review reasons.  You can't separately implement the different parts and you wouldn't want to if you could.  By themselves each of the parts is not very useful, its their combination that makes them very useful. Sort of like how a car has many parts which can be separately engineered and analyized, but the drive shaft in isolation isn't useful.

Segwit was split across 4 BIPs (5 if you count the later bc1 address stuff).

If another branch gets more work it will fetch the blocks on it, undo the blocks on its current chain back to the point of the fork, then it applies the new blocks. If it encounters invalidity in the new blocks it marks the invalid block and any descendants as invalid which would make that branch no longer the longest, then it would undo back to the common ancestor and apply forward back up to the tip.

So your original thinking is close, except it doesn't even start fetching the data or storing it unless it would be the best chain by POW if it was also valid.

Indeed, assuming a very powerful attacker then limiting them to weird technical attacks is unimaginative.

'just have to catch some miners, gather them up on stage and shoot them in the head. (Or more realistically put them in prison). Don't hypothesize weird technical attacks when boring things will do.'

https://buildingbitcoin.org/bitcoin-dev/log-2012-05-17.html#l-642

Even outlaws don't have that much use for an outlaw currency. Actually destroying bitcoin would be very hard but depriving it of almost all of its value would be much easier for a major nation state attacker.  But why would people want to do such a thing? -- in general, they wouldn't.

How do you imagine preventing an attacker from spending all your coins at once and sending most of their value to fee?  E.g.  you have three 1 BTC outputs which require that the output be a 1 BTC payment to address bc1apple.   A transaction which spends all three at once to a single 1 BTC bc1apple would comply, and yet turning 2 BTC to fees is probably not what you intended to permit.

In my opinion that BIP is essentially focused on a single use case but it kinda pretends to be more generic. The single use case absolutely requires no malleability, and that ends up creating a lot of limitations.  But even without that, additional flexibility is difficult to get right.  I think it would be worth the time to do it right.  The protocol's author disagrees and instead believes he'll be able to ram it down the network's throat really quickly if he keeps it narrowed to his use case.

I hope the network does not deploy that proposal.

It's simpler, it's consistent with the rest of the spec, it's faster, there is a security consideration, and if you don't like it you can do something else.

Simpler: RFC6979 is the way it is because it was designed to really be another FIPS certified RNG in disguise so that parties who were stuck with certification could potentially use it without losing their FIPS certification. This isn't a consideration for anything using secp256k1 at all. An implementation that doesn't need rfc6979 will save a fair amount of development time and a bit of code size too.

Consistent: The rest of the spec also uses the same kind of tagged hashes. The scheme in the spec is also very similar to ones used by e.g. ed25519.

Faster: RFC6979 is quite slow and turns out to take a significant amount of the total signing time.  The scheme in the bip takes two compression runs at runtime, the second of which can be done faster if you care a lot about about speed. (Not 4: it's designed so you can precompute and cache the tag part, eliminating two compression function runs).

Security consideration:  If you use ECDSA with the same key, nonce, and message as the BIP, e.g. by signing the same message with both and using RFC6979 with both, you'll leak your private key same as you would with nonce reuse across different messages in ECDSA. The BIP points this consideration out explicitly. This is due to a design flaw in RFC6979 in that it provides no domain separation, it should take the signing scheme as an input but it doesn't and without it the security goal isn't met. Signing the same message with the same key in both signature schemes is slightly contrived, but not absurd (for example there is bcash stuff that does so, and is only saved by the hair of their chinny chin chin, that the schnorr implementation they copied from us and stripped the attribution off uses a non-standard RFC6979 that takes an 'algo' input-- which we created because we were aware of this issue)... and the resulting break would likely surprise people, so it's probably better to avoid it by specifying something else.

Finally, the nonce generation scheme is non-normative. You can ultimately do what you want and you'll be compatible.  The BIP suggests several alternatives that we're likely to see in production.

I just discovered this captcha bypass and it 90% answers what I wanted... but since it's not 100%:

Is there a reason that the site couldn't use an old login cookie to let you bypass the captcha for the same account only and get upto one wrong password?

This way a user that enters their password successfully doesn't ever need to captcha again after the initial sign-up.  There would also be no risk of losing control of the cookie, since it will only allow one unsuccessful captcha-free login per successful login to the same account.

[I find the captcha a nuisance because I have to temporarily disable third party script blocking, plus I sometimes fail to be human enough for it...]

It makes more sense when you consider codeseperator.

Say there is some txout that can be spent by:   (yoursig AND mysig) or (mysig and hash-preimage-you-provide).   You tell me you're gonna redeem using the hash path and ask me to sign a transaction paying to you.  I'm happy with you taking the coins so long as I learn the hash, so I sign.

But then you're evil and you use my signature in the first branch along with your signature which isn't what I agreed to.  If there is a codeseperator between these branches the signed scriptpubkey is different and the signature cannot be rebound.

You could use a different pubkey for each of these cases, but that's another 33 bytes required which could be avoided.

Satoshi also might have been anticipating sighash flags that didn't commit to the input. In those cases you'd still want the scriptpubkey in the signature. It turns out that not signing the input creates a big mess... so if he was thinking of that he might have abandoned the idea because of all the issues with it.

Your prompt is a non-sequitor.  Increases in hashrate or computer technology don't make sha512 more attractive.

One change in technology has made it a lot less attractive:  Modern high speed CPUs have special instructions for computing sha256 extremely fast. ... these instructions don't do sha512, so it the speed gap between the two has widened further.

Multisigs with more than 15 participants is the most common...

But BC1 addresses don't have this limit, and if you're doing something big you'll want that in any case for efficiency sake.

P2SH is antiquated now, not the best place to look for novel functionality.

This does a decent job taking the blog post apart: https://medium.com/@samwill102244/response-to-unbounded-capitals-attempt-to-show-that-craig-wright-is-satoshi-4256602c2a64

So you agree that Satoshi was part of 'Core'?  Because it was Satoshi that deactivated opcodes... no one else.

In addition to doing this, I think it would be useful to attempt to circumvent the AV... since the listing is mostly lazyness they probably won't try to actively work against some simple countermeasures.

Some stuff before indicated that some were simply triggering on the string "wallet.dat" and others on some mining function function names. It would be pretty non-intrusive to mildly obfscuate them in the binary (e.g. renaming the function and just xoring wallet.dat with something or similar).

That in no way replaces reports-- it compliments them. If it's been heavily reported as okay, then they'll be less likely to work around some simple countermeasures.

unfortunately the court ruled he doesn't have to respond to that because they filed it too close to the close of discovery. Kind of a dumb decision, considering that the delays are craig's fault...

in my experience it's more often because it contains the string "wallet.dat" these days.

I just crossed 3000 merit! Yippie.

The only way to regenrate it would be to obtain and reprocess _ALL_ prior blocks and build a new utxo set from them. The undo data is the outputs removed from the utxo set by the block, so the data in it is not in the UTXO set after that point, nor is it in the removed block itself... it comes from prior blocks.

So if thats how you 'unprune' you are back to refetching the whole chain in order to do it.

This is what the OP wants: https://bitcointalk.org/index.php?topic=68121.0

Unpruning is not possible without changing the p2p protocol and storing more data, at a minimum.

You can't fetch undo data right now, and you couldn't verify undo data as correct even if you could fetch it.  So you'd have to store hashes of pruned undo data, and have some way to fetch it from peers.

I doubt anyone would want the extra code or testing burden for supporting a 'half pruned block' state where some blocks have block data but not undo data.