You can can multiply both with a single number which preserves the DL, you can also multiply Q by r and the resulting DL by 1/r.

The reason to randomize is just because it makes it obvious how strong the black box reduction is:   Even if the BB could only solve one in a million inputs, you could make it solve _any_ DLP just by invoking it a few million times...  So, unless DLP is broken you can't even have a "kinda sorta works" version of BB, it basically can't work at all.

I prove your problem is unsolvable assuming the hardness of the discrete logarithm (in the group in question) via blackbox reduction:

Lets assume that someone has a black box BB that solves your problem with some non-negligible probability. When you invoke  BB(k1,G1,k2,G2,G3,Q) it returns k3 (or it fails).

Now I convert BB into a function that solves the discrete log problem for Q with respect to G:

I pick two random numbers r1 and r2.   I now invoke BB(r1, 1/r1 * Q, r2, 1/r2 * Q, G, Q).  If it fails I pick new random numbers and try again.  If it is successful the result is the discrete log of Q with respect to G.

(I suppose to be precise you'd want to randomize the G and Q inputs in case BB just didn't work for some specific G and Q, but I leave the tiny bit of additional algebra as an exercise for the reader).

Thus, no function BB can exists for groups where the DLP cannot be solved, and your question is equivalent to asking how to solve the discrete log problem -- which isn't an answer you're going to find on Bitcointalk.

One down:

https://finbold.com/australias-biggest-crypto-exchange-delists-bitcoin-sv-bsv/

I'd make a bet that they managed to expose their RPC port on their Tor hs and someone is trying to hack them over the network.

Rather than making public calls-- I recommend people reach out privately, especially to places you do business with.

More public calls for exchanges to drop BSV (bitcoin scammers' version):  https://twitter.com/DanDarkPill/status/1353039875239362565

One comment there mentions coinmarketcap -- maybe even just as important as exchanges are these "market cap"  listing sites,  that end up listing BSV as #14 or whatever due to their illiquid clone-coin fraud... copy the bitcoin ledger then fall to a low enough value that most people won't be bothered generating risk moving the coins.  These presentations do a lot to falsely convince ignorant members of the public that this scam is credible.

Getting them to fix their market cap metrics to not count coins that will never move is probably not going to happen, but getting them to drop a scammy coin that is threatening the whole industry (-- as these sites will eventually be demanded to stop calling Bitcoin, Bitcoin) would be a good move.

It's not clear to me that many if any of those "small size" exchanges matter at all.  Their volume tends to be obviously fake, etc.

It would also act as a signal for exchange integrity:  If only scammy exchanges list BSV you get an additional quick check if an exchange is scammy.

The idea of avoiding him profiting from market manipulation is a good one, but when it comes to BSV there is just no way to stop him OTHER than to reduce the exposure noobs and suckers get to the scam asset.

Another possibility would be for exchanges to change their listing to "PRICE ONLY GOES DOWN" mode:  No order can be entered to trade if for higher than the last price...  exchange it all you want there, but you can never increase the price.

https://www.reddit.com/r/bsv/comments/l3peo2/punishment_of_god_wright_court_filings_expose/

Next project? digging a grave for BSV.

I think in that case it was a .bitcoin directory that included a locked wallet full of someone elses keys (and funds had been sent and swept). There is currently an amazon image with this too (or was as of a few weeks ago).

But the chainstate database/etc. aren't intended as external interfaces and I would be totally unsurprised if there was a way for malicious data in them to result in code execution.

For these questions the applicable time is not when it's activated-- it's when your wallet supports it which will be sometime after the activation.

After your wallet supports it, new addresses will use it.  Maybe in the first versions it will be optional and off by default but eventually it'll just be a default behaviour and you won't have to do anything to get it (besides request new addresses, which you should already be doing for each txn).

Unrelated,  https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018370.html

More than many altcoins BSV is an outright scam-- it's value depends on an obvious lie, it's authors are fraudsters.  If these idiots will threaten to sue bitcoin developers (who wrote much of the code their shitcoin depends on!) -- will the hesitate to ship a backdoored node? -- will that notice if someone submits one?

Clearly a lot of exchanges are fine with the ethics of selling fools gold to suckers, but BSV is just a liability.

A lot of the exchanges that list BSV appear to have clearly fake volume.  So which exchanges with BSV are the ones that matter?

It's worse than that... sha-256 has a 256-bit internal state bottleneck, and so that worst case deviation from uniform is likely massively larger than you estimate (though still extraordinarily tiny).

Basically you just consider your last block of input,  there is 512 bits of input text plus 256 bits of state from the prior block and outputs 256 bits.  Even if you model the 256-bit prior-state as totally uniform,  there is "only" 2^512 possible input values for each output value.

Still, according to this counting argument it's absurdly unlikely for there to be an unreachable output ... just not quite as much as your figures suggested.

Wow no, that analysis is just top to bottom full of errors.

"Papers by themselves aren’t licensed".  Not true.  Post Berne convention, any copyrightable work is copyrighted by default, and you cannot reproduce it without a license of some kind. (excepting some special cases like works of the US Federal government)  Papers often do specify licensing (unless they're all-rights-reserved: in which case you're just getting no license), specifying licensing is a universal requirement in academic publication (though sometimes you're not given a choice, you're just forced to assign copyright to the publisher or likewise).

"Open source documentation is also not copyrighted if it is given away in an open source license."  All licensed open source works are copyrighted.  The license permits you to do all sorts of stuff (if its an open source license), but it's still copyrighted and some rights are usually reserved (for example, even the most permissive licenses don't generally allow you to falsify attribution or strip licensing info).

"If the author or other owner claims ownership and registers it or uses (c), date and the copyright holder’s name at publication then it’s usually considered copyrighted."  post berne convention no copyright notice or registration is required for a work to be copyrighted. It's considered a polite practice, but is legally unimportant now.

In the US you need to register to sue in court, but that doesn't need to be done proactively in advance.

"the gift can’t be taken back and claimed as a copyright." The work is still copyrighted, so this sentence is just incoherent.  The licenses isn't revocable.

"If a copyright holder allows publication of a work by other sources and does not challenge this, the holder weakens its claim.", unlike trademark there is no duty to enforce in copyright.  Though there may be equitable defences in some situations (see mention in the letter) they are generally fairly narrow, and don't implicitly create a duty to enforce.

Providing actually false information doesn't help anyone, even if it's falsehoods used to cheer along a good cause.

Edit: After writing this, I found out that my partner, who is an attorney on the board of the Free Software foundation and is one of the authors of the CC-4.0 licenses independantly attempted to correct many of these and other errors earlier today and was just blown off.

I've updated this with a new most excellent section that was substantially contributed by Arthur Van Pelt using supporting documentation provided by xtraelv.

People have frequently asked what equitable defences means: https://en.wikipedia.org/wiki/Laches_(equity).

We Are All Satoshi

Except for Craig S. Wright.

Craig Wright definitely is not, but he would really like everyone to believe he is.

Satoshi Nakamoto authored the Bitcoin Whitepaper with the intention that it be shared widely, and Craig Wright’s takedown notices are fraudulent, but since he is a litigious jerk who has bankrupted people with his fraudulent legal claims in court, it is sometimes a wise strategic choice to avoid provoking him into suing, which is expensive and disruptive to a defendant even when they ultimately win.

But you might be in a good position to host this paper that Craig Wright so desperately wants taken down and kept under his exclusive control. And you might want to give notice to his attorneys, just to let them know.  Below is an example notice you can send to his attornies.

Warning: sending this makes you considerably more likely to become the target of a lawsuit by Craig Wright. You should think about whether you are prepared to be in that position before sending this letter.

(This is absolutely, positively, not legal advice, and you are strongly encouraged to consult with your own attorney.)



Old version:

That isn't a great way to reason about security. To give an example: Namecoin went with zero protection against stealing names for many years... and then suddenly a bunch were stolen at once.

A lack of attack so far doesn't mean something is secure.

Now-- bitcoin could probably lose hashpower and still be secure enough (esp because you could respond by just waiting days until you considered a transaction final...),  but I don't think you can conclude much from the lack of attack against some random low hashpower scamcoins.  A safer conclusion is that there is such a tiny amount of real economic activity behind them it just hasn't been worth the time and there are more profitable things to attack.

It's also security theatre because most of the coins in circulation are stored in addresses that have been reused.  "If you owe the bank $100 that's your problem. If you owe the bank $100 million, that's the bank's problem."  -- even if it did provide some protection to you (though I don't agree that it does, for the reason Carlton notes), it wouldn't matter because of everyone elses exposure.

I'm pretty confident that I started that whole meme that the hashing was protective,  I intended it as just a minor quip that it wasn't necessarily a pure waste of resources and might have some fringe benefit.  People have spun it into something I never intended, and I regret suggesting it.

Ah, that isn't quite correct-- unless I misunderstand you and we're just violently agreeing.  You can very easily make a program to prove other programs will halt. But it will have to sometimes output "I dunno".  On some programs it will output "Halts", others "Runs forever"-- but if it's deciding a turing complete language it will sometimes have to yield an "I dunno".

The ambiguity of English with respect to the meaning of "any" is annoying which is why the word arbitrary is important.  You can make a decider that decides if some programs will halt, but you cannot make a decider that will be able to decide all arbitrary programs without the possibility of returning that it can't tell. But users of smart contracts don't use arbitrary programs, they use specific ones and can restrict themselves to ones that can be decided.

An easy way to see this is so is to imagine that it simply looks for any loops or recursion and returns I dunno if they're *used*, in that example the language is Turing complete, but it checks if you use that ability.  Obviously that is a little limiting, so it can then allow them but only when it can prove how many times they'll execute at most.  So for example, if you have a program that does a for(int i=0;i<min(5,max(1,input));i++) and contains no other writes to i, then a program can prove the the loop will run only 1-5 times and thus will halt.

This kind of variable range analysis is something any moderately complex compiler already does already (e.g. it's needed for things like loop unrolling or to prove some code is dead so it can be eliminated).

A concrete example of this is the ebpf system in linux that lets you inject tiny programs into the kernel.  The ebpf language allows arbitrary jumps, but at load time the kernel performs an analysis and will not let you load an ebpf program that it cant prove will halt (in fact, there is even support now for loops like the one I describe above).  Sometimes you will write an eBPF program that absolutely will halt, but the prover in the kernel is just too stupid to reason it out and you'll have to use a different program.  Data-dependant-but-bounded loops are an example prior to the change I linked,  and you could usually work around that limit by always looping the maximum number of times and including conditions to make some of those loops do nothing, depending on the data.

Another really dumb example would be if the prover simply ran the program on all possible inputs, and if it was able to exhaust the input space with fewer than a million operations performed, it would return halt, if it detects (in fewer than a million operations performed) that the program reached a state that it had been in before *exactly* then it returns "runs forever", and if it runs into its million operation limit it returns "I dunno".   This is a dumb and inefficient example.  But it gives an intuition about how even though the problem of deciding is intractable by adding the possibility of returning "I dunno" it becomes tractable.

There is a whole field of formal validation which is all about reasoning about programs, including ones written for Turing complete languages, and proving their properties (including that they will halt).  All turing's thesis means is that it will always be possible to create programs that these systems cannot reason about, but that isn't a problem for a prospective user because they get to pick the programs will or won't use.

In any case, this is just pointing out that *users* can still safely reason about the programs they choose to use when they use a turing complete system, because unlike the turing decider program they don't have to work on all programs, just a subset of them and they can refuse to use any their tools can't analyize.

That's true (though it's overkill, one can protect the network with less potent means -- like how the linux kernel protects itself from rogue eBPF programs), but it's not relevant to the discussion here.  The DAO's faulty script wasn't a question of network protection, it was a question of users failing to protect themselves.  It only became a network issue because the corrupt administrators of ethereum had invested in the dao, weren't willing to take a loss in the name of principles, and had the level of control required to pull it off.

I actually don't think it's a actually trade-off: I believe that every program usefully expressed for a blockchain can be expressed without turing completeness: This is because validating the result of any NP language can be done in P time.   Blockchains don't need to actually compute anything (and ought not to): they can verify the computation performed by some user/host external to the consensus... and that's obviously what you want to do because operation inside consensus is absurdly expensive.

Eh. It was an implementation bug in the smart contract, not ethereum itself-- pretty similar to the DAO.  Perhaps it's better to note that fixing it wouldn't be stealing from anyone: the funds are just frozen.  Vs in the case of the DAO taking the funds back didn't just violate the smart contract, it unambiguously violated the human-language legal contract on the DAO website because it was all-caps unambiguous that even if the smart contract did something nuts, it was what governed the agreement.

Your question is underspecified. A bug in what?  In a smart contract their wallet uses?  That has happened before, tough "luck" for them.  There was even a case that people lost money due to a miner in bitcoin core, and it was just tough luck for them.

An example of this is that MTGox sent thousands of Bitcoin to an improperly encoded scriptpubkey, tough luck for them (and their customers-- which, incidentally included myself and may other long time well know bitcoiners).

The integrity of the system is almost its only reason to exist, and it's not something to be trifled with just because some users messed up.

If instead you mean some consensus bug that allowed, e.g. validation to be bypassed due to a flaw in Bitcoin itself. That's sort of issue can be softforked out -- not accepting the bogus spends -- without breaking the consensus.  And has been:  Originally a spending scriptSig could just toss in a OP_TRUE OP_RETURN and the spend would be accepted before the payer specified conditions were ever even evaluated.  Satoshi deployed a change that wouldn't admit transactions that used OP_RETURN at all (it would have been sufficient to deny it in only scriptSigs, but at the time the interpreter worked by concatenating the scriptpubkey onto the scriptsig so it wasn't simple to make this distinction).  This didn't disrupt consensus because nodes already have the unavoidable ability to decline to include transactions that are otherwise valid... and once more than half the hashpower was running this rule it could be enforced without any potential for a lasting consensus split.

(emphasis mine)

Ethereum blabbered on about "unstoppable code" but at the end of the day for ethereum it's just marketing blather  For whatever its other faults, Bitcoin exists for a reason higher than just making money for people... having principles means that you sometimes have to bite the bullet and take on an uncomfortable cost, because to fail to do so would moot the endeavour.