The explicitly stated goal right in the BIP62 document was a reduction in dependence on OpenSSL for consensus; which the truth and nearly the whole truth all that was missing was that the concern was less theoretical than presented. But yes, the unstated privately known consensus vulnerability was a driving force for clearing up that ugly corner with BIP66 immediately rather than mopping it up as a side effect of BIP62. Especially due to fact that BIP62's progress has been slow-- and had grown over complicated. The fact that BIP66 accomplished one of the necessary steps will make BIP62 or its logical successor easier to move forward.

If you note from the timeline that BIP62 had already been revised to accomplish a BIP66 like goal prior to us knowing about that specific vulnerability: We were aware of the risk class in principle before having specific knoweldge with enough concern that we thought it was worth closing off. Knowing that it was _actually_ exposed had only an impact on timing and sequencing; and only after it was clear that BIP62 was not rapidly converging (unfortunately, in spite of much progress on BIP62 we continued to find problems with it).

It's sad, there is a vastly superior-- simpler, more comprehensive, and with secondary benefits like enabling more degrees between full and SPV-- malleability 'fix' in elements alpha but I don't have any way to get it into Bitcoin, BIP62 is disappointing by comparison (brillant ideas welcome).

an anonymous person hard forks the current Bitcoin code with the only change being a lifting of the limit. he provably destroys the commit key (a Bitcoin private key) over at github thru a op_return spend. the result being a Bitcoin source code with no core devs and thus no ability to change it going forward. would that be enough to carry Bitcoin forward for the next century?

This message is technically incohearent-- there is no such thing as a a "commit key", and "op_return spend" doesn't destroy information if there were; achieving what you suggest simply requires people stop upgrading (which is also part of the reason that we do not use automatic 'push' upgrades)---- but I certantly get the _intent_. and it's one I've forelorely expressed multiple time myself, going back years:

That it would be philosophically ideal and achieve the highest security properites if the system were completely involatile, defined by it's own mechnical construction, and any change to it would simply be a different system which people could voluntarily move to by their own free choice. Through this the system would be immune to whilm, political control, or subterfuge in a much stronger sense.

Sadly, that result currently appears to be pratically be beyond the scope of human engineering abilities-- or at least beyond the efforts expended on any software system I'm aware of thus far.

We've had a pipeline of newly discovered non-public vulnerabilties in the Bitcoin protocol running almost all the time since 2012. I don't have a great answer to that hard questions, but sadly burying our heads in the sand cannot work-- it would just result in a regular series of potentially devistating "emergency" changes, rather than a orderly, planned, resolution.

CGMiner is GPLed software. Antminer was obligated to distribute the complete cooresponding source to their modifications under the same license. If they failed to do so then antminer would be in violation of the license.

This is the argument for TXO commitments. But it's a storage vs bandwidth tradeoff, instead of storing a (say) 64 byte UTXO entry you need a 2.5KB proof when its spent. It takes some pretty tortued assumptions about storage vs bandwidth costs to make this win unless you assume a very low probablity of being spent and only use the proofs for accurately predicted low probablity of spend transactions.

If you search the #bitcoin-wizards logs for that term you'll see some instances of this proposal-- you might find it informative.

As you'll probably see in the logs, I disagree with the claims of this approach preventing doublespends. The result of it, at best, is similar to RBF scorched earth, which many people don't consider to be an improvement.

I also disagree with the claim that it in any way addresses nothing-at-stake; in particular it's already common for schemes to suggest that duplicate signatures void coins (which can be done just by system rules without a single show signature) and yet those schemes also do not solve the nothing at stake problem: you cannot punish someone who has left the system and they can produce their conflicting signatures long after leaving it.

There are some pratical concerns as well. For example, now ephemeral data k must be securely stored and if lost result in loss of the key. Signing devices must be carefully stateful and avoid repeated signatures. If the user pays inadequate fees, they'll have no mechenism to revise their transaction to update them-- as even a completely benign double spend (e.g. one that pays the same destination) would result in key loss.

Less importantly, miners also have free pass to ignore the effects of this scheme and there is a simple non-trustless but private protocol possible to allow someone to have a third party privately mine their transactions. (You put up a 25 BTC bond with the miner, and give them the transaction hash you want them to mine, with a promise that you'll instantly give them the full transaction if they present you with a winning block or else forefeit your bond).

Quote

especially those that already have stealth addresses.

Stealth addresses are linearly related, and the relation is known to the paying party. So if I use the stealth address method to create two one show public keys for you and you sign with both of them, I can derrive your private key. I am not aware of a mechenism to securely generate 'stealth address' pubkeys for single show signature without bilinear groups. If not for this a single round trip schnorr treshold signature would be possible. [I hope this point makes it clear how tricky working with an intentionally fragile cryptosystem is, as someone could have followed the suggestion in the original post without realizing that they were giving away their private keys.]

Interesting and I gonna to try it out later today. This will make file management easier and it seems I won't need to manually change filenames by renaming anymore.

Bitcoin Core has had the ability to set the wallet file name with -wallet= for years. There is no need to rename files, and hasn't been a reason to do so for longer than your account here has existed. You cannot change the path because if you split the BDB recovery logs and wallet file itself onto seperate media you will end up with irreparabile data corruption if there is an unclean power off with (un)reasonable probablity.

50% is still much better than very low change you have on a late broadcast; I believe one of the revised selfish mining attack papers presented something similar to your suggestion (the original one was just busted).

I've thought before to use a similar rerandomization metric but include some sigmoid function of time so that the randomization is decreasingly likely to reorder the blocks the farther apart they are... but I was unable to find something that I felt I could analyize.

Quote

Break ties in favour of the earliest header

No, the earliest received block. If the header's time were used there is trivial attack where you relay the header as fast as possible and withhold the block.

On the facts the above desciption doesn't describe behavior in the network at the moment-- e.g. backlog isn't there, and substantial amounts of the funds that went into the DOS attack paid for outputs, not fees.

The scheme you describe is scale-free; I see you clarified in later messages that you think the "solution" is dyanmic controls rather than a removal of limit but the bold increase blocksize response in your initial is quite confusing-- more than half your text is spent spinning hyperbole, it would have been much more useful to spend that text on describing what you're actually talking about.

Perhaps most importantly, it does not make a case that the attacker produces increased income relative to his hashpower. Consider:

His average cost for spam is 1000 coin/block (2000 * 1-rate).His average income is 2000 coin/block (4000 * rate). (He doesn't get income from his spam, he saves its cost however; see prior line)His net income is 1000 coins/block, on average.

Now consider the consolidation of other miners:Their average cost for spam is 0.Their average income is 3000 coin/block (6000 * (1-rate)).Their net income is 3000 coin/block.

Both groups have 50% hashrate, so the non-attacking miner has a fee income of three times greater the attacking miner per unit hashrate!

Normalized for hashrate thats 2000 vs 6000.

----Lets instead imagine that there is also a backlog of fees episilon beflow the attackers floor, and he mines those instead of his own and that doing this doesn't somehow eliminate the floor effect:

Attacker average cost for spam is 1000 coin/block (2000*1-rate)Attacker income is 3000 coin/block (6000 * rate)Attacker net income is slightly under 2000 coins/block, on average.

Attacker cost for spam is 1200 coin/block (2000*(1-rate))Attacker income is 1600 coin/block (4000*rate)Attacker net income is 400 coin/block

Honest miners cost for spam is 0 coin/blockHonest miner income is 3600 coin/block (6000*(1-rate))Honest miner net income is 3600 coin/block.

Normalized for rate, thats 1000 vs 6000.

---

Finally, we already know that the system is not incentive compatible when a single party (or collaborating conspiracy) has more than 1/3rd of the hashrate: http://arxiv.org/abs/1311.0243 (The results below 1/3rd require information asymetry advantages which are handwavy, but at 1/3rd or beyond no such asymetry is required)-- though such attacks are highly conspicious.

At best, this attack allows a sizable minority group of miners to engage in price fixing without running out of money, under the constraint that legitimate transactions are still wiling to pay enough to fill half the block.

Exactly, like anyone they can generate transactions to drive up fees; large miner hashpower gets a discount on fees; but they still lose funds; and everyone else shares the income.

After reading this, I had a scary thought: what if hardware wallet companies made this technology easy to obtain and use, allowing anyone to compromise wallets on devices such as laptops, and in turn forcing Bitcoiners to purchase a Trevor or something similar.

Small hardware wallets tend to be more vulnerable to this sort of thing as they have much less room for adequate shielding, less CPU cycles to run hardened algorithims, and run at slower speeds that make observations easier.

Thanks for the clarification. But, it is not nice to argue that PaperWallets are unsafe just to back up electronic storage. PaperWallets are not supposed to be generated online and offline generations are quite safe. If someone dowaloads bitaddress.org source code from Github and generates PapaerWallet in an offline (which I assume is not in the vicinity of this new gadget), then what is wrong with it ?

Nothing about this attack involves online anything. It involves radio emissions of a device while it is generating keys or signing. Use of the "paper wallet" only dramatically increase your vulnerablity to this rather fringe attack over behavior normally-- because the sofrware used for paperwallets is (as far as I've seen) never even constant time much less reduced-emi...

But seriously. If I don't personally want to facilitate someone shooting their foot of (where undoubtly some will blame me and attack my reputation), then thats my call-- not yours. And whining about it is offtopic for this thread and subforum.

Please people; this person has a completely reasonable techsupport request. Yes, I agree-- windows GUI is not the "right" way to do headless, but the software certantly shouldn't be crashing when run in 16 bit color mode!

I intentionally did not publish the patch I gave F2Pool that allowed them to do this because I knew that people would use it for themselves even after being told that it would leak their private key.

SECP224K1 and SECP256K1 share the same 166 bit string doubled to produce the generator. Doubling a short string is an "obvious" enough way to choose a generator that I thought to halve the existing generator. Folklore is that some curves use SHA1 outputs to produce their generators.