Duplicate. https://bitcointalk.org/index.php?topic=5284407.0

It wasn't on my blacklist but that isn't too surprising, that behaviour causes bitcoin core to instantly disconnect for a little while now-- so if I ever connected to it I probably didn't stay connected long enough to notice its other misbehaviour.

It's going off-topic, but I also read the OP like wind-fury did-- but trusted y'all would set it all straight, and you did.

Current versions of Bitcoin core will first try to spend all outputs paid to a common address as a group.

That behavior is controlled by two options:



The first, if enabled, forces all payments to the same address to always be grouped.

Otherwise,  it tries computing the transaction both ways, and if the grouped way doesn't pay more than a threshold amount of fees more then it uses the grouped way.  The default threshold is the conservative value of 0.  ... so it will prefer to group the inputs, but only if doing so doesn't make it pay more in total fees.


This is still kinda dumb: the threshold should probably be in terms of fee ABOVE the minimum feerate (e.g. so if your transaction is at the minimum feerate, it'll always do it, because you were going to pay the minimum feerate eventually in any case)... but at least it's something.

I checked my last week of logs and don't see any "inv sent in violation of protocol", which is what gets logged if a relay=false peer sends an inv.

You're either sending the flag wrong, you're sending a mempool message, or you're getting confused by fake nodes again.

Neither of my block-relay-only peers have any invs sent or received, and sending tx invs is unambiguously gated on the relay flag in the code.

For example, here is a 256-bit key decoded with gpt2tc and the 1558M model:


Good luck entering that in exactly, character per character.

Here is the same key in hex:

c4c54956ea89760bfb1f1c22752765cbdf7a21606e3dd17f80d81e2668518d4d

And in the gramtropy failmail grammar:


or the breezy grammar:


or the silly grammar:


or the english grammar:


(Failmail and breezy grammars were intended to be purposefully hard to remember, english model had a hard time constructing a 256-bit model so that is four 64-bit encodings).

It's pretty straight-forward to do this, but the number of bits per word ends up extremely low, so the strings are absurd long.

GPT2 and similar gives you a probability distribution over the next token as a function of the prior token.

Imagine output tokens as boxes laid along a ruler of unit length. Set the width of each token equal to the probability, so they all add up to 1 and span the whole ruler.  For each token, subdivide it into the tokens for the next symbol, again, sized by their probabilities so they add up to the bounding token.

In this model we just take the private key as a position along the ruler and read off the tokens at its position.  Assuming rounding is handled correctly, this process is totally reversible. See also: https://en.wikipedia.org/wiki/Range_encoding

GPT2TC will basically do this for you, https://bellard.org/nncp/gpt2tc.html  though due to various implementation details the result is not always reversible, so it loses a little information.


Or you could use https://github.com/sipa/gramtropy which is explicitly made for this purpose, but uses a simpler language model.

But really I think all this stuff is mostly pointless and hurts key security rather than helping it.

The charting tool draws straight lines between datapoints, and after restarting the node refilled over time (presumably it's been modified to use the mempool p2p message to do so).

Please don't confuse some guys random node for the operation of the network.

The search space is 2^256, though some keys map to the same addresses. The non-uniformity means that some keys are more likely than others in your search, but all are still possible..

If you were searching for keys beginning with B  and the first letter of the set of keys matched in this pattern  [..B...B..............B....B.............B....BB.B..BBB]  the probability of selecting that last B would be 1 in 54 (because only 1 in 54 starting positions will select it) while it would be 14 out of 54 for the 5th one (because 14 different starting positions will end up there).

But on the real (enormous) range this doesn't really matter... it's just a pedantic detail.

There is continual realtime mirroring of all that stuff.

Maybe a couple of the most recent updates might get lost if github shuts it down, but otherwise it shouldn't be a big deal.

At different points parties connected to wright and ver indicated that they were going to do this, though they haven't yet.  You should just assume it'll happen eventually and when it does it'll be a little disruptive but otherwise not be a big deal.

FWIW, the story would be pretty much the same on any other hosting service.

It's perfectly secure to do this.  Searching this way creates an infinitesimal bias in the keys that are selected (the selected key is more likely to be found after a long run of non-matches than after an immediately prior match) but even where an attacker knows the exact prefix searched for the bias is extremely tiny-- because nearly spaced solutions are extremely unlikely to begin with-- and not exploitable (because you can't search only keys that meet that criteria... since the criteria itself requires generating the pubkeys to check).

Schnorr without taproot isn't really that useful: it makes it simpler and safer to write threshold signatures but that's it-- you can already threshold signatures using burdensomely complicated client software.  And threshold signatures by themselves don't even do that much-- they let you make signatures somewhat smaller but only when you don't need to be able to tell which parties signed.   It's better --- but perhaps not worth the trouble of a consensus change by itself.

Taproot without schnorr isn't really that useful: without threshold signatures, which are burdensomely complex to write software for without schnorr, it only lets you have a single party key at the top (which is pretty useless.)

There is a third logical part of taproot,  which is the merkelized script. This part is probably the most useful of the three on its own, but it's much more useful in combination.  With it you can use trees of N of Ns to make thresholds work usefully even when you need to be able to tell which parties signed, and  N of Ns are much easier to deal with than arbitrary thresholds, because the latter requires interactive secret key generation.

In order to have the property where arbitrary complex scripts are normally indistinguishable from one-of-one payments you need all three.  They also can't just be independently implemented: taproot changes the pubkey that goes into schnorr verification to commit to the merkelized script.

There were other techniques proposed, including graftroot (allows you to add scripts to an output after someone has already paid to it), and improved signature flags--  but those were possible to implement independently without leaving the rest not very useful.  There were also a number of next steps like signature aggregation which would have been best implemented in combination but were still left out because the three main features of the taproot bip were still useful without it.

Looks like all the new testing is done with the python framework. I'll prod Pieter to add old style vectors.

They are over here: https://github.com/bitcoin-core/qa-assets/blob/master/unit_test_data/script_assets_test.json

It isn't just about the hype, it's also about the exit scam.

Most defi things are constructed in a way that makes them a nearly free option on shitcoin vs btc price.  You put up some shitcoin to get loaned Bitcoin.  Shitcoin price tanks relative to bitcoin?  Default on the loan, lender gets worthless shitcoin and you laugh off into the sunset.  Shitcoin price moons? repay the loan and get your shitcoin back.

Most are also constructed so that some centralized party (or worse, some Sybil attacker) can just walk off with the coins-- low to no security and zero effective disclosure of the security risks.

Legitimate use for these things is essentially zero, the only one you see people promote in any detail is the use of loans to avoid capital gains tax but that *does not work*, because that activity is a "constructive sale" as any clueful accountant could tell you.

These schemes get pumped at the promoters expense to attract suckers to buy otherwise worthless associated tokens and to bring in masses for the exit scam.  It's like bugs to a bug zapper.

There are vectors at https://github.com/bitcoin/bitcoin/pull/19953/files#diff-6794e4c8edce5f4dd1a21181a91f0c166f34c876809e40f015e5926ee3d6a126

A pretty decent amount, anyone with the leaked mtgox data can see how much... in USD amounts at the time it wasn't particularly stupendous.

Nah. A lot of people barely had any idea of who he was for a long time-- beyond the hothead blockchain.info guy that was doxing users.  But I have no doubt that he was very important in the little bubble where he was funding a collection of sycophants, and that's probably sufficient to build up the kind of hubris that you mention.

Fingerprint auth is mostly snake oil.

The way it is implemented is almost always bypassable. Because the device knows what your finger looks like and is just looking for a match, so someone with access to tinker with the device innards can bypass it.

There are better ways to implement it-- where the data is literally encrypted with your fingerprint and the device doesn't know what your finger print is...  but this requires extreme rocket science (to deal with the fact that each fingerprint read will be slightly different) and so no one does it that way.  Even with that, you leave fingerprints all over the place so the security can only be so good.

Per coinmarketcap (ugh used to be an okay site before eth heads got them to abandon their integrity and list premined coins), it made it under 0.02 briefly back on September 25th!

I was pretty surprised by it, since it really looks like someone has been spending a lot of money to keep BCH above 0.02/BTC and I've been waiting for that peg to fail.


But I guess this is just how most of these schemes die... not with a bang, but with a wimper.

Not that polite to go digging through other people's transactions!

God knows, I half think that ver has been cynically dumping BCH (and later BSV) on his suckers the whole time.  We know that BU kept 90% of their funds as Bitcoin instead of going all in on bcash.

If he really followed through with what he promoted to others he'd be looking at devastating >>90% losses (esp if he also went hard in on eth at the time he was pumping it it would be more like 98% losses), and probably we wouldn't be hearing from him anymore.

Like the waves of ICO and "world computer" scams before them, these things probably have a short term benefit by bringing in people-- and a long term drag as they bankrupt the people that fell for them and make the whole space look like a bunch of scammers.

Most "exchanges" are primarily shitcoin gambling sites.

You log in and get popups urging you to "invest" in some latest scammy ICO or pointless shitcoin.

It's really disappointing and I'm sure it slow Bitcoin's growth a little that there aren't many options for sending people to someplace that won't just try to exploit them by dumping garbage on them...  but I doubt it makes a big impact on Bitcoin's adoption.

Changing how money works just takes time.