That's no different than any other consensus rule not even just P2SH as garlonicon points out.  But say, why not bare pubkeys? Or hash160s ending with 0xbeef, coins mined in odd number blocks, or coins last moved before January 13th 2013?  By fixating on segwit it only shows that your thinking is being distorted by the dishonest fud of third parties.

Since miner's honest behavior is created by user's nodes enforcing the rules-- not just for segwit but for all rules, you'd have a case to make about any rule whose enforcement was less than substantially ubiquitous-- and, indeed, many users refrain from adopting new functionality right after it is deployed for that reason.  But that assuredly doesn't apply to segwit now as enforcement today is very close to 100%, and in general the community adopts deployment plans for new functionality that almost guarantees high deployment ahead of activation (by synchronizing enforcement via the blockchain after a long time is given for deployment).

As tromp noted an reorg wouldn't be very relevant but on that point:  Reorging back that far would be practically and economically infeasible and if one were to do so it would hardly be any harder to reorg back out p2sh or the mining of all blocks.  Also, it's typical for the activation of consensus rule changes to get hard coded in once they're deeply buried-- this is mostly done for simplicity reasons since the activation logic can be replaced with a one line check (or in some cases actually enforced all the way back to the start, if there were no violations in the history), but it also has the effect of making any absurd reorg attack impossible in theory and not just in practice which is helpful for anti-fud even if its real security consequence is irrelevant since if you're assuming attackers powerful enough to rewrite years of the chain the system already can't be secure.

This is the case for segwit:


bitcoin/src/chainparams.cpp:
        consensus.BIP34Height = 227931;
        consensus.BIP34Hash = uint256S("0x000000000000024b89b42a942fe0d9fea3bb44ab7bd1b19115dd6a759c0808b8");
        consensus.BIP65Height = 388381; // 000000000000000004c2b624ed5d7756c508d90fd0da2c7c679febfa6c4735f0
        consensus.BIP66Height = 363725; // 00000000000000000379eaa19dce8c9b722d46ae6a57c2f1a988119488b50931
        consensus.CSVHeight = 419328; // 000000000000000004a1b34462cb8aeebd5799177f7a29cf28f2d1961716b5b5
        consensus.SegwitHeight = 481824; // 0000000000000000001c8018d9cb3b742ef25114f27563e3fc4a1902167f9893


Looking it up, this was implemented in PR16060 in 2019 so anything running that code or later wouldn't fail to activate segwit enforcement at that height even if a fairytale reorg were generated, making the OP's specific attack technically and not just practically impossible.

Musig(1) K of K doesn't require interaction to create the keys, just to spend using them.  Musig(2) K of N requires interaction both to create and spend.

You could add another branch off the tree such that you have a separate subtree of K of K musig1s, which wouldn't need any interaction to create the thresholds (unlike musig2 k of ns).  They'd be more efficient and private to spend assuming that your signers are online and can afford the interaction, but you could still spend using the k of k paths assuming you weren't.

This would provide more incentive to develop the software and processes to use the musig1.   Doing a musig1 is also really attractive because you can store one of them (ideally the one you think you would be most likely or able to use) in the root for a really efficient spend.

Including the separate tree would have a cost assuming you weren't going to use it-- so it might not be justified on that basis, but including at least one k-way musig1 at the top would be entirely free, and wouldn't end up creating a "random private key" that you have to store.  Just take the any K of the N pubkeys keys (maybe the first?), combine them with musig 1 and stick that in the root instead.  No private data, no interaction, and the users gets the option to spend via that path in the future if their software and process supports it.  I don't keep up with bitcoin development, so maybe there is a good reason you haven't proposed this-- but I can't think of one. musig1 is very simple: essentially just hashing all the pubkeys and a counter for each pubkey to get a deterministic per key randomizer, then multiplying the keys by their randomizers and summing the resulting keys.

Having the _option_ of spending existing coins via more anonymous and radically cheaper path is something the users of a scheme like this would really thank you for in the future should Bitcoin have a period of high fees or deanonymization attacks.

Aside, you I see nothing about your point of "unknown" discrete log that could allow someone to verify that it was in fact unknown,  and a such it could be hiding a backdoor as the document is currently written.

I suggest you consider what I wrote above and do that instead but if you must have a point of unknown discrete log you must generate it by hashing a serialization of G and a counter and lift_xing that and documenting the process of generating it that way.  It's possible that you picked a value from elsewhere that was generated that way, but it must be documented clearly since it's a major attack vector. You could also eliminate the randomizer by making your point of unknown DL be lift_x(H(G||list of all the other pubkeys||counter)) and using the first counter that passes the liftx. Use that directly as the taproot base point, but again, I *really* suggest making your basepoint a musig k-of-k, redundant to one of the ones in the leaves, even if you don't initially expect signers to support using it.

Aside, it was my impression a couple years ago that development of musig software has gone slowly mostly because the industrial participants most interested in writing it (e.g. blockstream) is primarily interested in making software for unattended, automated, byzantine fault tolerant systems.  This means they need a K of N scheme that can still efficiently produce valid signatures with up to M out of  K+M of live participants being malicious.  This is vastly harder than just K of K or  K of N  where if any of the K misbehave the signing jams and its up to the humans to figure it out (which is what happens for a checkmultisig if one of the signers is screwing around).  The more complex use case is a valid one, but many people don't need it-- and CMS like signing that people are using instead of musig(1/2) doesn't really provide it either (though it can be easier to figure out WHY a CMS is failing if a signer is producing junk, AFAICT existing tools don't).


Cheers!

FWIW, the algorithm inside minisketch was created for that purpose.   The idea is that you combine the biometric with non-secret (or not very secret) correction data.  If there is enough correction data the probability of success can be as high as you want.  If you have little enough correction data then the scheme is no less secure than the underlying biometric even against attackers that have the correction data.

How secure would it be?  Who the hell knows.  The security of biometrics is pretty unclear to begin with before you go adding the correction data needed to make them reliable.

In the US overall we have relatively good legal protections against being forced to divulge passwords (though there have been some instances), but we have zilcho protections against being forced to provide biometrics.

From a geek novelty perspective I think it's a cute idea to screw with-- but with a security hat on I think biometrics are across the board a bad idea and the best you can say about them is that they haven't yet been proven to be completely worthless yet.

Conditional *subtractions* with constants. As xor is both addition and subtraction in GF(2^n).

Say you have a 10 bit integer you want to reduce mod 384.  One way you can do it without an expensive division is with conditional subtractions:


In [1]: all([(x%384)==(x-(x>=384)*384-(x>=2*384)*384) for x in range(1024)])
Out[1]: True


In GF(2^n) it's even simpler (because addition/subtraction doesn't carry) and a bigger win (because we don't have fast hardware to do the multiplication/division operations).

You can see the wikipedia article on barrett reduction for more in this class of techniques.

Line 6 is computing  chk*32 + v,  the top is taken first to carry, it's done first so that the range never exceeds 32 bits.  In python you could implement it otherwise though it may push it into poor performance.

I generally would describe % in most code as a bad practice, particularly since if the divisor isn't constant (or the compiler doesn't do strength reduction) it's a hundred times slower than a multiply. But in python everything is already equally a thousand times slow-- but the implementations for the bip were also intended to be transliterateable to other languages and get a reasonable result.


What the checksum is logically computing is taking the entire data being checksumed as the coefficients of a big polynomial (with degree one higher than the number of input digits) mod G, where G is another polynomial specifically selected for its error detection properties.  Because the mods commute it's possible to perform the mod G for each digit as it comes in rather than accumulating up the big product and computing it at once.  That little table used at line 8 is a precomputation of the effect of reducing mod G for a given set of bits that are carried off the top of the 32-bit accumulator.

The implementation of bech32 in bitcoin has a detailed mathematical description woven into the comments,  you might want to check that out: https://github.com/bitcoin/bitcoin/blob/master/src/bech32.cpp

In GF(2^n) the '^' operation is addition.

The algorithm is effectively reading base-32 digits into a big number mod some polynomial, so at each step you add the current digit. (The gen[] part below handles the carry/modular reduction).

It does so happen that either would work for that operation, but I would say that ^ is operation that is more consistent with a formal description of the algorithm.

Down below where the modular reduction is handled at line 8 the same addition (^) is used, and '|' wouldn't work there.

Of course, since it works correctly for all values, if someone had a reason to use | instead in the place it works I don't see any reason why they shouldn't.  As a reviewer I'd be briefly confused as to what '|' was doing, while (when looking at code working in GF(2))  '^' is obviously addition.  Though I doubt I'd raise any issue with either construction.

One could also argue that it would be algorithmically more clear to write the *shift* as a multiplication, but the multiplication operation needed in GF(2^n) is a carryless multiplication. Languages don't provide clmul as a native operation and it would be silly to write one out because the only multiplication we need is the special case of a multiplication by a hamming-weight 1 number whos base-2 log we know-- for that special case multiplication both in GF(2^n) and the integers can be accomplished by a shift.  Plus if compiled as written the shift will be actually faster than a GF2 or integer multiplication on devices that people actually use (vs | vs ^ which broadly have identical or close to identical performance). Plus every programmer should be familiar with using shifts to multiply by powers of two.

I wouldn't be surprised if a dozen well placed high altitude EMP optimized nuclear bombs couldn't destroy access to substantially more than half of all coins without killing anyone (well, okay, killing some through long term fall out, but not directly).

It also doesn't have to happen all at once to result in totally distorted rates over time, though obviously all at once makes it worse. 4 25% loss events is a 70% loss.

Not sure who you're responding to here, since nowhere did I say that AFAICT.

"Equal to what people lose by accident" is only an equilibrium reached after an unspecified, arbitrary, and potentially very long time.


Right.  So what problem does it solve?   As far as we know today: none.  You can conjecture situations where some specific proposal might do something useful, but the concept as a whole doesn't by itself.  


By the same argument you've made-- that the supply and circulating supply aren't fixed-- a tail subsidy cannot achieve any specific inflation rate.  

The same argument could be made if it weren't viable without an additional "0.1%" subsidy: that if it doesn't work without it, there is a reasonable odds that it's not viable with it.

You've posted an overly technical argument that after an unspecified timeframe constant subsidy will eventually match coin loss.  Yet in this discussion you are acting as though your conclusion guarantees that the subsidy is a tiny % of your wealth,  it doesn't.  This is a slight of hand.   I get that you intuitively and informally believe that would be the case, and I would agree that it's possible for it to be the case.  But it is also unambiguously possible for it to be very much not the case.


Which would also be true in the presence of tail subsidy, particularly if it's not set to a conservative rate to increase the confidence that the rate won't become unacceptable in the face of coin loss or economic contraction.

People chip in when they transact.   How about spending 1% of your wealth to unnecessarily pay people to burn energy with no practical benefit to your security?  Or 0.1% of your wealth and still have the result be insecure?  And it's not just "everyone chips in"-- someone is profiting from this at your expense.  Again:  You argue as if its clear that a credible level of tail subsidy would have make a meaningful improvement to security-- we don't know that.  It might, or it might not.  Right now, as I pointed out, Bitcoin current fee income already produce income greater than the total subsided income for a number of altcoins which are going without attack.  While that's far from conclusive, it's evidence that a subsidy level of 0 may be currently viable.

There have been many altcoin forks to change inflation rates, including several of ethereum's, as the highest profile and highest value example.  (there have been many others that have been forked to change the subsidy schedule, there was even an attempt to create a 50 BTC forever fork of bitcoin back around the first halving).

There are many possible ways to bring coins into existence.

The subject being discussed here is redirecting wealth from the existing users of the system in the long term in order to subsidize providing security to the system.

Tail subsidy as discussed by the author of this article doesn't solve that except to the extent that it forever enshrines an additional industry in that privileged position.

The potential for abuse can be irrelevantly small.

For example, allowing your coins to be spent by another party if they go 120 years-- which will cover the expected lifetime of the owner *and* their heir-- without moving appears to me to have an inconsequential risk for abuse (and the risk could be mitigated by making it somewhat longer).  And it would be economically rational for a very long lived entity to pay people small amounts to encumber their coins accordingly, and economically rational to accept those offers.

I think I've given a completely realistic way that it could become extremely low.  I think it's inevitable that if bitcoin continues to be widely used that such schemes will be adopted at some scale, though I admit I'm less confident that they'd be universal.

At the time what I'd considered was writing far-future timelocked spends as soon as the coins were received and sending them off via tor to a host that collected them.  Though today that kind of thing is better accomplished by having an alternative spending path with a relative timelock on it.

How's that been working out for you so far?    Speculation brings its own varrious annoyances, but it's an important part of adoption too.  I believe that a high inflation rate Bitcoin would never have taken off at all-- and, if anything, just been replaced by a low inflation coin.

It is, of course, impossible to prove such conjectures about alternative histories-- but as far as I can tell every high inflation rate altcoin  (or things with similar economic policy) have been total adoption failures so far.  I can't attribute this to Bitcoin's first mover advantage because they've been unsuccessful compared to other bitcoin alternatives not just bitcoin, including when they had more to offer.

I take it you would argue that this trend will reverse in the long term.  I doubt it: I think network effect is more important than jealousy (not that this doesn't conflict with the above: network effect doesn't happen until something is already successful).  It's just a fact of life that the people that came before you had myriad opportunities you missed.  Imagine how wealthy you could have if you bought apple shares in 1985 and held it till today, San Francisco real-estate in 1982, or traded your silver for gold in the year 1200?

[And you could apply this argument to real estate-- $/acre can differ by 1000 fold based on just the network effect of people already in a location.  Those who were there first are enriched by this.  People could abandon the high price place and go elsewhere-- they do to some extent, but seldom enough to change which places are expensive and which places are cheap.]

Economic activity diffuses wealth over time-- particularly if some systematic effect isn't sticking it back in the hands of the few as our central banks do today or as tail subsidy might in some cryptocurrency schemes. It might not diffuse as quickly as we might like.  The OP's argument was fine with reasoning about the state of the system arbitrarily far in the future: if we adopt that approach we can argue it doesn't even matter how the wealth was initially distributed, since at some arbitrarily far point in the future it won't matter.  But that doesn't hold true in the presence of tail subsidy:  Tail subsidy will always continue to enrich the mining industry (and those close to it in the economy) at the expense of everyone else, creating a "winner" that can't be displaced by diffusion.

This has been a monero marketing point for a long time.   To some extent I think it's kind of pointless navel gazing.

Imagine a currency that was perpetually inflationary by having everyone's holdings equally increase by 10% every year.  Other than some logistic impacts with pricing and contract terms and some psychological effect, this would be a complete economic no-op: no one would be richer or poorer because of it.  The "inflation" isn't what matters economically, what matters economically is how the inflation is distributed.

In light of that, I feel that the answer given by Todd and Monero promoters is answering the wrong question.  When people are concerned about inflation they're really concerned about two things:  Inflation unpredictability/uncertain, because unpredictable inflation can't be efficiently compensated for, and the cantillon effect-- the fact that the normal ways of creating inflation enrich parties close to the source of the money at the expense of the rest of the economy.

My toy example lacks both those issues: since it's predictable and everyone is proportional 'close' to the new money, which is why it's an economic no-op even though it is "infinite inflation". By contrast "nocturnal[1]tail emission" fails both of those criteria and so it has an economic impact even if you accept that the argument that the supply of circulating coins is finite. ... a conclusion that shouldn't be at all surprising since if it has no economic effect no one would argue for it to begin with: having an economic effect is the point.

([1] Aside, the fact that many altcoins have been created by eastern Europeans seems to have resulted in using the word 'emission' instead of 'subsidy', but the word in the singular form is very uncommon in American English (rather than 'emissions', which is more common). For many people the immediate sophomoric association is the titter inducing "nocturnal emission".  Advocates of these schemes would do themselves a favor to call it "tail subsidy" instead as subsidy was the established term for the ex nihilo mining reward before altcoins started calling it 'emission'.  I think it's more economically honest too-- as it is indisputably subsidy, and advocates for it ought to be explaining why miners need to be subsidized)

So any discussion of it should really be about the economic effect and its merits or harms-- the discussion about an "infinite" circulating supply is just a pure red herring.

But I'll embrace the red herring for a bit to highlight some of its limitations:

The convergent inflation argument has some striking similarities with Rizun's "A Transaction Fee Market Exists Without a Block Size Limit", in which Rizun effectively argues that Bitcoin there is some block size where the marginal increase in orphaning risk for a transaction makes it unattractive to add transactions paying under some threshold fee.

Rizun's argument is known to be fallacious due to its assumption that there is a marginal increase in orphaning risk.  But any such risk is a technical artifact in how blocks are propagated and validated by miners and can be made arbitrarily low by centralizing mining or even eliminated completely by changing how block propagation works (and there are concrete schemes described that accomplish this).

Similarly, the convergent inflation argument assumes there is some consistent coin loss-- but that isn't a fundamental property of the system!  One could easily imagine a future where long lived entities like states offer people payments (or discounts) if they encumber their coins with CSV-like releases if they go 1-2 lifetimes without being moved.  In such a future coin loss could become arbitrarily small, maybe even effectively zero (if, e.g. standardness rules were put in place to avoid accidental losses).  In some hyperbitconized future it would make a lot of sense for things to move in this direction.

(At one point I even drafted up a mailing list posts suggesting that Bitcoin core should consider offering an option for people to dedicate their long lost coins to development help fund future development, but never finished it because I figured it would generate too much drama for the amount of benefit it would provide.)

Rizun's argument is also flawed in that at best it only makes a case that an equilibrium exists (and it also requires endless mining subsidy, but I'll ignore that), not that that the equilibrium is an acceptable one:  It might only be achieved at transaction levels far beyond any conceivable demand or only at a level where the computational costs of running a node would be unreachable by practically anyone.  The convergent inflation argument is somewhat better in that it seems clear that the equilibrium would eventually be reached (where Rizun's doesn't even achieve that), but the equilibrium point might further out than the lifespan of our sun.

Unlike Rizun's argument I don't think these points are strong enough to demolish the idea that continued subsidy could be convergent entirely, but I think they do point out limits in the argument.

But as I said above, I think the argument that the supply of circulating coins converges is really a red herring.  Instead, we should consider the economic effects:

Is it desirable, much less moral, for a percentage of the world's wealth be continually diverted to support mining?   I wouldn't take an absolute hard line position that it wasn't desirable, or even that it wouldn't be moral (at least in so far as it was a system people consented to use)-- but the reasonableness of this depends critically on the amount.   Would 0.001% be acceptable?  I suppose! would 10%? Absolutely not.  And here the convergence from loss argument actually makes a case against the policy it intends to support:   It admits and depends on uncertain coin loss, but by that same token we can't know the rate.  It's completely credible that after some major war or disaster that suddenly a large percentage of coins could be lost at once (particularly if the above mentioned recovery schemes hadn't been widely implemented yet).  If that happens the "transitory" inflation might become extremely market distorting, ultimately harming civilization by directing an unconscionable share of resources to mining or (more likely) causing the system to be abandoned.

I think it's also worth considering that the total supply of non-lost coins and the circulating economy are quite distinct things.  Our civilization has undergone a couple centuries of tremendous sustained growth as a result of technologies such as fossil fuel and the haber process-- and I think it may be giving us a rather biased perspective on the dynamics of mankind's economies in the far future: There are straightforward thermodynamic reasons that an expansion of our economy (much less an accelerating expansion) shouldn't be expected for indefinitely long time. Even if you assume we'll someday populate the stars, absent new physics that makes FTL travel possible, the size of an interconnected economy is finite (though perhaps quite large!).  Fanciful speculation aside, even in our current economy we go through periods of higher and lower activity, and so if the miner's income doesn't depend on the current circulating economy (which could be a fraction of the stashed wealth) it could easily become distortingly large during slow periods-- which should be common in a less expansionary economy (and may last generations!).

The uncertainty of the amount works in the other direction too:  Continued subsidy isn't guaranteed to be enough to support security in any meaningful sense, it could be too small to achieve its intended goal as well as too large.  Because of economic cycles the same scheme could even be both, disruptively overpaying during economic slumps (diverting resources to excess security) and disastrously underpaying during economic booms (failing to achieve the security goals).  Without thinking carefully you might think that sometimes underpaying would still be better than zero subsidy but that isn't clear to me because unpredictability in security is itself a problem because it interferes with compensating behaviors.

With these points in mind I think Satoshi made a very good decision.  Bitcoin's tail subsidy scheme of zero is the unique amount of tail subsidy guaranteed to (eventually) never overpay. It is the value with the minimum amount of economic uncertainty, excluding security considerations.   It does make a weaker argument for long term network security, but since tail subsidy schemes are unable to make a strong argument that they're actually able to meaningful improve security (much less guarantee it!) I don't find that weakness particularly compelling.   There are many uncertainties about Bitcoin's security and long term income for mining being insufficient is one of them (probably not even the most concerning one).  Making the economic policy clear and simple is worth it, especially since security isn't going to be clear regardless.  I'm pretty confident that if Bitcoin originally had perpetual subsidy the market would just be further diluted by variants that had different amounts of it. Zero is a pretty strong attractor in the design space, 0.01 vs 0.02% is far less clear.

I think our experience so far makes a basic case for Bitcoin's security: Bitcoin generates fee income today which is greater than the total (inflation subsidized) income of many altcoins that seem to be going without attack.  Is this a security guarantee?  No, but it's the first test and Bitcoin appears to be passing it.  Assuming it does work I think we're obviously better off with it as it is-- I don't think anyone arguing for tail subsidy would still argue for it if they were confident the system would be secure without it: The only time you can make a clearly moral case for forcing someone to pay someone else is on the basis of necessity.  If Bitcoin's scheme turns out to not work out then users in the future will have many alternatives they could consider-- including adopting Bitcoin variants that are created that have constant subsidy (as tail subsidizers propose) or attempt to achieve security through other means.   To those people, should that future ever come to exist, the discussion will be much simpler though because they'll know if Satoshi's simple economic-effect minimizing scheme works or not, they'll know if alternatives are necessary.

The subject just creates drama today because we all clearly signed up for a system with a particular economic policy, for better or worse.  It would be immoral in the extreme to try to coerce people onto a different one. And since for the moment Bitcoin does work I think it's hard for some people to see conjecture on this subject as anything but a call for coercion. Fortunately, for the same reason I think it would be impossible to do so, unless it turns out that Bitcoin isn't viable-- and in which case it wouldn't be that big a deal because few would want to stick to a system that wasn't working.  If Bitcoin users didn't think a non-cocersive system was extremely valuable they wouldn't be using Bitcoin to begin with.  I think Todd's post acknowledges this out too,  but people seem quick to ignore that point because they'd rather stress themselves out over the drama (presumably this propensity was also a factor why Todd stopped developing bitcoin many years ago. ).

Combining them also doesn't work for another reason: The whole point of using different sighashes is so that the txn can be changed by some of the parties without the involvement of the others, yet a combined signature requires all parties to be present.

What could be done (though not with current consensus rules) is non-interactive half-aggregation.   With half-aggregation the S values from the different signatures get combined but the R values are distinct-- so asymptotically the signatures end up half the size.  Unfortunately, this prevents completely concealing the policy as a normal threshold signature would do -- so you don't get the privacy gains, but just a space gain.

The half aggregated signatures are also pretty much as slow to validate as individual signatures (in batch verification).


I think that in general there is pretty little reason though to actually post weird sighashes to the blockchain:  You could compute txn offchain as a backup, but then assuming all parties are available, replace them with a final sighash all version signed with a threshold signature. ... and once you're thinking in terms of only using the masked versions as a backup there isn't really much need to aggregate anything at all since unless something goes wrong only the N of N is ever going to get posted to the blockchain.

If it's a CTF then they presumably setup an intentionally broken key generator or (more likely) signer.  Google for information on nonce reuse or related nonce vulnerabilities.

Bitcoin script is purposefully not turing complete-- it's not an accident, in fact it's extremely easy to be accidentally turing complete.  Turing completeness provides no value for this application and creates additional risks.  Helping someone make a bitcoin clone turing complete is like 'helping' them have an infinite coin supply.

There are plenty of limitation in script that are make it less useful, but lack of turing completeness in the script language is not among them.

https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki#specification

The only thing set to zero is the hashOutputs portion of this.

If the entire 'hash' were set to zero, someone could instantly steal anyone's coins, which is presumably what you were trying to do instead of ethically reporting a vulnerability you believed you found.

anyone want to take bets on the above 'precompiled binary' from the newbie account being malware?

Quite the opposite, Bitcoin destroys time travel.

Bitcoin's cryptographic hash based randomness means that any change to the timeline that impacts a bitcoin transaction in any way will radically change the future.

Unless they were making some post that gave a credible statement that they were banned in error, I'd just nuke the account and not even think twice about it-- especially if they appeared to be acting abusively w/ the new account.

This is a forum, not a court of law.  Unjust bans don't deprive people of their freedom or their life (particularly people who've demonstrated that they're willing and able to evade a ban).  False confessions are a thing, sure, and I wouldn't be completely shocked if a couple people saying they were banned were just trying to sound cool... but I think it's no major loss to lose a user who thinks saying they were banned makes them cool.  If they would eventually grow into a good participant, better that they do it from an account that doesn't have the boat anchor of bragging about being banned in their very first posts.

I don't see any cause to investigate in any depth.  If someone admits to breaking the rules we should feel comfortable taking their word for it.  Perhaps if they didn't behave abusively with the new account we shouldn't hold it further against them -- just nuke it and move on.

Most likely, though-- these people were actually banned.  Excessive exposure to internet crackhouses like reddit and twitter where bragging that you were banned while posting violent harassment usually won't get you banned again unless you blunder into also offending the politics of the corporate overloads just has people thinking they can get away with saying crap like that.

Nope. That isn't how patents work.  If someone publishes an invention that publication becomes prior art and is an absolute bar to patentability, after a year even the inventors own publications count as prior art.

So no, Satoshi themselves couldn't even do this.

But your misunderstanding is one of that faketoshi fraudsters like Wright like to exploit.

"Upon review and consideration, the Court does not find a basis to disturb its prior conclusion from the August 2019 Order that Defendant has failed to present credible evidence that Ms. Wright was a member of W&K."

The court already saw Lynn's claim to have ownership and determined that it was a baseless forgery.  Just another fucking lie of wright's.

Nah, that's another lie of wrights.

https://www.reddit.com/r/bsv/comments/rc9iev/judge_bloom_has_already_seen_the_wk_operating/

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html

There is no simple and efficient membership proof in these sorts of accumulators.

Yes, though we didn't fully appreciate the depravity of clones and the creation of so clones that fraudulently call themselves "bitcoin"-- though fortunately as far as I know none of the name clones have kept the HRP.

And indeed, it was designed to be both easy to change and also less excusable to not change "What do you mean FooCoin address, it begins with BC ... Bitcoin!". 

BC was shorter than BTC... I personally also liked the homage to the original Bitcoin icon (which was a coin with BC in it).