Achow's post seems to sound like it's saying that there is some kind of danger in random K because of 'getting more information out' -- there isn't in and of itself,  to the extent that different K's "get more information out" so does signing multiple messages.

The reason for 6979 is that reliably generating random numbers is hard and it turns out that over and over and over again applications screw it up.  Worse, you can't easily tell when a random number is screwed up because it's random, one looks as good as any other. ... unless the screwup is so bad that they're just constantly repeating.  But basically any form of predictability of K will break the signature, even ones like being linearly related to the Ks in other signatures.

You still need to generate a secure random number to get your private keys, but you only need to be successful at that _once_.  RFC6979 is really just a way to safely reuse that ONE random number you successfully got (the private key) for all your further transactions... rather than needing a constant influx of new random values, each one a potential point where a software error could cause the loss of your keys.

The fact that the procedure also gives the same signature every time for the same key/message if you don't use the optional extra-data input to 6979 is a bonus that makes software testing a lot easier,  but it is not the source of the advantage of this approach itself.

This distinction is important because multiparty schnorr (or mpc-ecdsa) signing can use RFC6979 but MUST be constructed in a way where the same signature is not repeated even for the same message.

This site appears to connect back to the server every time a new key is entered...


People should NEVER use any key management webpage or webapp.

I posted the standard recovery procedure for the kind of corruption described here.  It seems to be being ignored.

I would take a substantial bet that the OP here is either scamming or is going to get scammed.

As an aside, it is not safe to use potentially malicious wallet.dat files.  Anyone who gets sent a wallet.dat from a third party should take great care in using it. I would not be shocked if it were possible to get arbitrary code execution from a wallet.dat file.  If a bad guy found a way to do that the best way to exploit that discovery would be to pose as someone who corrupted their wallet and encourages people to try to 'scam' them by getting a copy of their wallet or help them with a promise of an outsized reward.

Now what you have the data backed up, start up Bitcoin Core with the -salvagewallet  option.   It will brutally go through the corrupted file and recover anything looking like a key.

Here is where I post the standard warning:

Bitcoin "hacking" tools have frequently been used to spread malware.

We could make some guesses as to why: Someone creating actual hacking tools is likely to be someone with missing or unusual morals-- if they'll hack other people, why not you?  People who want to use hacking tools are also victims that people won't necessarily feel too bad about ripping off.  The greedy impulse of potentially stealing some Bitcoin may also blind people to being properly sceptical about what they're downloading and running.

Whatever the reasons are, it happens.

Often the 'hacking' tools are not just not real, but they're technobable nonsense.  Other-times they are real, but with an unwelcome surprise inside.

In this case the post sets off a number of red-alarms, for example "64gb bloom filters" make no sense at all. There are about 500k unique output addresses, a filter with a one in a million false positive rate is about 2MB in size. The author's other posts are full of other technobabble nonsense, like "ECDSA primes".

Consider yourself forewarned.

You cannot back up the wallet by copying without shutting down the software first.  The backupwallet rpc lets you back up while running.

I wouldn't use it, it's known buggy.

Older versions shouldn't work any better on Windows XP.  I'm not aware of us removing anything needed to make XP work, XP is unsupported because it is buggy, insecure, and abandoned by microsoft. Bitcoin developers got tired of wasting their time on bug reports from XP users which were due to bugs in XP.

In this case I don't think that is really the motivation, to me it seems that (regardless of his other views) Zin-Zang just has a very specific belief about what "full node" means and has fallen into the trap of thinking that a definition is something that can be "right" or "wrong" independent of convention or context. "In most cases meaning is use", but this fact isn't always blindingly obvious which is presumably why Wittgenstein bothered writing it down.

In an alternative universe it could well have been the case that the Bitcoin convention established it the other way-- I believe in ours it did primarily because the whole usage of  the term "full node" came about in discussion of the security trade-offs of different ways of using the network (specifically in section 8, simplified payment verification, of the whitepaper).  If instead the term full node were first used in section 7 (reclaiming disk space),  it might have turned out differently-- though only might, because the big difference between having the old history on disk and not is just not terribly important in practice, while the difference between full verification and lite is substantial (including, re: the subject of this thread-- mining!). ... which is also presumably why Satoshi, like developers since, considered pruning as a function a node can do, not a different kind of node*.  [*though I expect as pruning becomes more common and more sophisticated we'll probably think more of nodes that have the full history as a different kind, the term that seems to be coming into use is 'archive']

If you're still thinking that it's improbably convenient that someone is suffering from mere confusion or explicable cognitive traps when those misunderstandings just happen to support some obvious-to-you batshit political argument... you shouldn't.  There are a zillion people on the internet and you can imagine misunderstandings being assigned by a (non-independent) lottery, some unfortunate folks are just going to by chance get assigned the mix of confusion that is compatible whatever it is that they're bugging you with and you don't hear from all the other people that got a different set of blessings from the confusion fairy.  The mistaken understandings and the bonkers politics can also self-reinforce...  It's true enough that malicious actors exist, but they're indistinguishable from sufficiently advanced ignorance and probably more rare than is easily assumed.  We're usually best off assuming ignorance:  Ignorance can be cured, even if people's commitments to past arguments sometimes make curing it difficult.  The success rate for the education wolves may not be that high but assuming malice has pretty much never cured anyone who was actually just confused.

A pruned node will not be fooled by a very long range / complete rewrite attack.  They can either reorg like normal (and download missing data) or shut off and tell their user they need to redownload to sync up, but in no case will they be fooled by an attack that wouldn't impact every other full node... if they were that would be a concerning bug.

Pruned nodes are more or less externally indistinguishable from other full nodes-- even the fact that they don't serve old blocks doesn't distinguish them, since archive nodes will also not serve old blocks if they've run close to their upload bandwidth limits.


You are just making up new terms then, because full node has always meant fully verifying and enforcing the rules and has always included pruning.  You're free to do this, but expect your words to confuse and then anger people when they realize you're misleading them because you were autistically unable to accept terminology that was in widespread use long before you showed up (this thread being an example of that-- the idea that a pruned node couldn't mine only remotely makes sense if you think that they aren't full nodes)... Words have meanings and you will not make friends by rejecting established ones and substituting your own.

The function described here is not asic resistant, in fact it looks like an outright scam. Buyer beware.

lol what.  Craig Wright and Roger Ver are both conmen. Coingeek is a conman shilling platform,  and their claim that [I have] "come to the realization that Bitcoin SV is the real Bitcoin," is malicious whole cloth fabrication.  Now, Is "Bitcoin SV" the real fake bitcoin (bch)?  Maybe but who cares.

I think it's unfortunate that Wright's over the top mania is causing dissension in his bamboozled army, as having a scam run by an obvious scammer is a win-win... but it seems that there is nothing to be done for it now, the psychosis is just too strong now.

There are a dozen different two way satellite services... they cost like $10-$20/mbyte transfered, which is fine for sending a transaction here and there

Here are a few randomly selected public IRC discussions about satellite transmission of Bitcoin data.


But hey, if you want to take credit for suggesting something that we'd been discussing for at least 4 years and had even started to implement before my post, knock yourself out.  That isn't half as crappy as wishing you'd patented it and thus actually gotten in the way of anyone actually doing it...

Kinda sad that you claim to have come up with it but seem to not get the point.

Two way isn't all that that interesting, relative to the complexity/economics of it: There are 1001 ways to send a transaction.  There are commercial two way sat internet services-- they charge by the byte and would cost about $50k - $150k per month to get the blockchain streamed,  but only cost cents for a single transaction.  You can send single transactions by SMS, you can send them on QR codes printed on postcards.  You can send them along with the order you make to the party you're paying however you are doing that, etc.

Not even remotely.

Also, when P2SH embedding is in use (which is AFAIK by far the most common) you will mistake an output for non-segwit until its spent (and of course, once spent it doesn't get included in that count...).


Also the later posts indicates that the poster you're responding to is deceptively only counting non-embedded outputs as segwit.  Of course those aren't common-- they're not universally supported, so if you want people to pay you you don't generally use them yet.... p2sh embedding exists because it took years until everyone could reliably send to p2sh addresses... So segwit was introduced without a new address type to ensure it could be used instantly by anyone who wanted to use it, and so unsurprisingly that's primarily how its being used. (Later-- only after segwit was deployed-- a new address type was also created for the extra benefits it provides.)

To me it's becoming a little hard to swallow franky1's extreme dishonesty. Saying segwit adoption is low because a new address type specified a year after segwit isn't yet being that widely used in the face of almost half of all transactions using segwit and continuing to argue it after being patiently corrected isn't just an honest mistake.

Relevant: https://bitcoin.stackexchange.com/questions/37077/how-much-inflation-does-bitcoin-have-year-by-year

The DER encoder in OpenSSL is correct, but the above examples apparently weren't using it.  The result of "I made my own DER encoder" is usually wrong... it's not hard to encode DER correctly but it takes a little effort that people don't bother to put in.

Even once you get the encoding right, you'll still have to obey the lowS rule: https://bitcoin.stackexchange.com/questions/59820/sign-a-tx-with-low-s-value-using-openssl

https://bitcoin.stackexchange.com/questions/4943/what-is-a-block-withholding-attack

It's even possible to profit from it if you have a large percentage of the network hashpower: This works by combining withholding at a PPS pool (to lower the network difficulty while still getting paid) and solo mining.

piotr_n basically answered the question decisively above based on his own analysis-- work that any of you could also reproduce.  He gave numbers in terms of percent of transactions spending one or more segwit inputs (so segwit using, by definition) as well as percentage of bytes.

As usual franky1 is trying to bamboozle people, by arguing someone isn't using segwit yet when they still have some older outputs they're spending that haven't yet become segwit outputs.

If you want to talk about users adopting segwit for their own transactions then figures like piotr_n's are exactly what you should be looking to.  If you want to, instead, talk about the resulting capacity increase then either the ratio of block size to weight (e.g. number of transactions is irrelevant) or the typical minimum fee rates to get into blocks are interesting.

That paper is very bad advice.  It's just wrong. It complains that regular bitcoin nodes can be triggered to ban tor exits, sure, but tor HS bitcoin nodes do not.  The "bad" outcome they are concerned about is that if you use tor you might find it doesn't work and you need to turn off tor to connect: even if that were a real risk it isn't worse than not using tor at all!