You pulled a gimmick that got you 115 merits with 0 effort, providing 0 value; and if some people are critical of that, you wax indignant? 

Your “not gonna break any rules, but” qualifier doth protest too much, methinks.  I am not familiar with your post history; but within the four corners of your post, that is what alerted me:  It looks like you yourself thought that you were doing something shady.


In my experience, these things don’t always work out so well...


At least, that was a sly way of offering something of value that others may find meritorious—well, earning the merits in the manner of a meretrix.  It’s just too bad that she (or “she”) turned out to be a scammer who wound up banned for ban evasion.  Otherwise, I think that it would have been worth 100 merits!

As I discovered empirically, the system does not allow self-ignore.  (I needed to use an alt account to make this screenshot.)

I have not been following this (just peeking in); but if I spend the time to catch up on the context, I may consider breaking out my red pen.  I have tagged merit beggars before; and I do not care what any of the Reputation regulars say about that.

---

Quote from: Slot Kid on March 28, 2021, 01:52:31 PM

Quote from: JayJuanGee on March 29, 2021, 04:41:27 AM

ImThour got 115 merits for his merit begging post

WTF!?  That’s sick.  It goes to show that meritorious effort is worth an awful lot less than gimmicks and scams.

I know that effort on this forum is worth jack shit, because I used to have a tip address in my signature; and it never received anything, way back when.  (N.b. that at the time, I was earning merits at a terrific rate.)  Thus if shameless begging is now permitted in WO, I have a better idea.

I will HoDL 1 BTC for each BTC sent to this address:

bc1qjq0f2vywmd0u65gqm7kjzy2d8v98kwjxhr89ak


^^^ I will HoDL 1 sat for each sat sent to this address.

Fuck merits.  I’m a merit whale.  And what is a forum merit worth?  Fuck merits—I want bitcoins!  Preferably all of them.  For I have a sexual fetish for bitcoins.  It thrills me to hold them.  Days and nights and in the wee hours of the morning, I find myself staring at my UTXOs on the blockchain, ogling them, mesmerized by their beauty...  If you send me your bitcoins, then I will take them away to a secret place where I will hodl them and cherish them and perform with them erotic crypto-rites involving the deflowering of virgins beneath the full moon.  Yes, MOON.  BITCOINS.  ME.  HODDDDDDLLLLLLLLLLLL..... mmmmm...

Merits are an overvalued shitcoin.  I want Bitcoin!

...and here I thought that WOers were not fond of shitcoins.  Why the fuck are you throwing shitcoins at a shitcoin beggar?

ImThour and Slot Kid are obviously weak-hands day traders who will pull a mindrust at the drop of a hat.  They need an extra incentive to buy Bitcoin—and the incentive is intrinsically worthless, totally centralized and permissioned forum merits (!).  Think about that.  What is next?  Pumping XRP?  

WOers who gave 115 merits to ImThour are promoting shitcoinery.  It was wise of vapourminer to crack down on Slot Kid.

Perhaps there may be hereby a language barrier.

What I meant was that “SO” is a nondescript, androgynous, inhuman term.  I hate anything called a “partner” or an “SO”.  I want women, in the form of wives, girlfriends, hetaerae, or whores—I want women, damn it!  No “SO”.

---

If that is your worldview, then it is a self-fulfilling prophecy.  For you and for her, too.

In this context, that is a word for eunuchs.

No, I don’t need a “partner”; I have never had one, and I never, ever want one.  Girlfriend, yes.  Wife, yes.  “Partner”, never.

(Whereas you need a sense of humour, as does anyone else virtue-signalling on this thread.  Oh, the outrage!)

---

Who the fuck wants a “partner” or “SO”!?

Bitcoin is becoming even more attractive.

BTC can hire you a GF (or at least, “GFE”).

---

Yes:  https://old.reddit.com/r/GirlsGoneBitcoin/ NSFW link, moderated by theymos.

That is strictly online-only.  But surely, there are also IRL sex workers who accept Bitcoin.


Bitcoin can hire a cook, too.


What hippie nonsense is this?  You will be very disappointed when you grow up and attain some relationship experience.

A girlfriend does not give you a “deeper connection”; and if she does, then she is your wife, and she is connecting you to the heirs to whom you will bequeath your Bitcoin when you die.  That, money cannot buy; money can buy almost anything else!


In the world as it is, money is a necessary but insufficient precondition for happiness.  I learned this the hard way.

---

Well, there is such a thing as a Bitcoin sexual fetish.  Actually, I myself invented it; evidence is buried somewhere in my post history.  I believe that I can safely claim to be the first-ever author of Bitcoin erotic literature, intended for a female audience.  It is all in service to the god of Bitcoin.

---

Warning:  I found this post amusing; it reminds me of old “why beer is better than a girlfriend” lists posted to Usenet.  However, I always do a quick check before raining down plaudits; and I advise caution before laughing too much.  If OP tries to sell you a girlfriend, what you actually receive will probably be an inflatable sheep.

If you make an utterly ignorant screed which demonstrates a manifest misunderstanding of Bitcoin, do not expect smarter people to jump to reply with scholarly analysis.


OK, you are just here to pump your idiotic shitcoin.


You should follow this man’s posts:

https://bitcointalk.org/index.php?action=profile;u=9636

He offers confirmed maths and science for proof that Bitcoin has already failed!

HTH.


Learn something about Bitcoin before you opine.  What you are saying is tantamount to a proclamation that the banking system must fail because SWIFT is too slow and expensive to use at the supermarket.  See my above post for some hints, and seek education about how this Bitcoin thing works.

---

Damn it, Phil, that merit is worth more than his whole shitcoin portfolio.



Imagine if gold had a built-in global settlement layer that worked over the Internet, upon which you could build rapid, low-cost payment rails for various different money transfer applications.

Link fixed to be usable:

Bloody hell, you call that a “free country”!?

If anyone ever wonders why I sneer at America (and Americans), this is why.  In the Soviet Union, at least the average person realized that he was living under the yoke of an unbearable tyranny.  And that is why the system eventually collapsed...  In America, the people are dumb enough to call themselves “free” (and to bomb others into unwilling submission to the same “freedom”).  Americans are too stupid to understand that they live in one of the worst countries in the world.

Protip for the OP in that Reddit thread:  “Crypto” did not destroy your life.  Your insanely tyrannical government did.  Blame must be laid fairly.

---

^^^ That.  And if you get wrecked trading on margin, don’t you dare post to Reddit that your life was “destroyed by crypto”.

---

There, you are just being rational.

I am too cautious to predict “when”; but for my part, I will answer the “why”:  Bitcoin’s fundamentals.

We are in the mid-$50k range with ATH >$60k, and very far from market saturation.  Market cap is over $1 trillion.  Absent a mass-catastrophe (e.g., disappearance of the Internet), the size of the Bitcoin market will grow at least another 20x–30x.  That is a conservative estimation; it will probably grow much more.

Supply is capped.  >88% of maximum supply already exists.  We currently have a low inflation rate, which will be economically negligible after the next halving.  Therefore, price must increase.

This analysis ignores the inevitable and accelerating devaluation of the dollar.  When I call Bitcoin at a long-term value of over $1 million, that is according to the value of today’s dollars.

If Bitcion >$1 million seems crazy to you, just remember how crazy “Bitcoin >$50k” would have sounded five years ago.

—Oh, did you say $100k?

I want to kill myself.

---

Others have given various answers.  Some good, some bad.  Perhaps others have answered too much.

Does anyone else think that such threads as this may be a good way to gather intel on—what to search for?  Especially to catch low-hanging fruit?

Kerckhoff’s Principle applies only to ciphers.  It is way overused.  Security by obscurity is oftentimes useful, and sometimes necessary.  Much of tradecraft relies on obscurity.  If you have worked out some special way to exfiltrate your own secrets from a repressive dictatorship,
then maybe you don’t want to advertise on the Internet just how you do it.

Anyway, seriously...


I melt down my seed, forge it into an all-powerful Ring in the manner of Der Ring des Nibelungen, and stick it on my finger.  A Rhinemaiden accompanies me, acting as my wife; thus, border guards will simply assume that it is my wedding ring.  Nobody ever questions this ruse, and I have never had any mishaps this way—unless I go with Floßhilde; that girl is trouble!  In the future, I plan to upgrade:  I will wear the Tarnhelm to make myself invisible.


If you want to use this method, beware that the high melting point of a BIP 39 standard seed requires the use of an acetylene torch; and reconstituting the ring into bitcoins requires throwing the ring into the Rhine River, then killing the gods and destroying the heavens.  (I need to file a Github issue about this.)

HTH, HAND.

Username checks out.

<snip>


You need to learn some actual data about Bitcoin, before you start these types of discussions.  The Bitcoin blockchain only supports a low rate of transactions; but Bitcoin, the currency, can support a practically unbounded transaction rate on L2, L3, and otherwise off-chain (using the blockchain as an occasional settlement layer).

---

Eh, can’t resist...

Classic.  When Bitcoin has an up day, “I’ll buy in the dip.”  When it dips:

---

You have not said anything about your risk tolerance.  (Among other things.)  There is no one-size-fits-all formula to apply to the numbers that you stated.

And I am probably the wrong person to ask:  I bought into Bitcoin for political reasons, without regard to the market.  It has worked out well for me; but I did not plan it that way!

Ah, I see what you are trying to do.  I did not see your previous thread; and it was not clear from OP that you are using the public keys to handle the wagered funds.


My assumption was that cards are being dealt from a shared deck, so that the protocol could be applied to any traditional card game such as blackjack, poker, etc.  Thus, if Alice is dealt the Queen of Hearts, then Bob needs to pick a random card from a 51-card deck that does not contain the Queen of Hearts—and Bob is not allowed to know which card is missing.  (It seems obvious; but I have found that in such matters, it is important to state such things explicitly and precisely so as to avoid subtle mistakes.)

This thread caught my attention because I have tried to solve this problem before—but not integrated with Bitcoin transactions.  I did not yet find a practical solution which satisfied all of the various requirements I imposed.  Computing the state of the deck is a weird case of secure multiparty computation, where each party only has access to limited information; and I don’t know enough about MPC to say if there may already be an existing solution.  (I also suspect that what I am attempting may be impossible; but I have not been able to produce an impossibility proof, either.)

I will need to think more about what you have explained thus far...  Interesting problem.

---

Note:  My previous post has been edited with a bugfix, CVE-2021-NULL.  Whoops.

That’s a much clearer explanation, at least of the first part of it:  You are essentially trying to build a cryptographically secure hash table of the integers.  The second part, the use of those values, still seems unclear; but I suggest breaking this down into pieces for analysis.

There is no reason to use public-key cryptography:

• Elliptic curve public keys are not uniform random strings.  That may or may not have an impact here; but it is irrelevant, because...
• It is an unnecessary complication.  Simplicity is better for security analysis.

BIP 32 uses HMAC-SHA512 internally.  Why not simply use that directly, without any point multiplications, with the player committing to a random seed in an ordinary commit-and-reveal scheme?

• Alice picks a seed S_Alice, and commits SHA-256(S_Alice) to Bob; Bob picks a seed S_Bob, and commits SHA-256(S_Bob) to Alice.  (For brevity, I will omit describing Bob’s side of this in the next steps.)  After the game is concluded, Alice and Bob will reveal their respective seeds to each other for retrospective proofs that neither party cheated.  <edit> As I specified it, this would, of course, be vulnerable to length extension such that a party could search for a more favourable seed after committing.  This could be solved by requiring a constant-length seed (say, 256 bits), or by using HMAC with a protocol-specified key, or by using a hash that is not vulnerable to length extension. </edit>
• For each of the integers 0 to n, Alice calculates a hash H_{Alice, n} = HMAC-SHA512(key = S_Alice, data = n), using a protocol-defined encoding of n such as a 64-bit integer in network byte order.
• Alice sorts the list with H_{Alice, n} as the sort key and n as the value, to create a pseudorandom permutation of the integers in range [0, n].

So far, so good?  I hypothesize that this can be reduced to the security of HMAC-SHA512 in the random oracle model; at least, I don’t immediately see any way to attack this without attacking HMAC-SHA512.  (If I am wrong, somebody please point out the flaw...)

---

Next question:  How is this turned into a hand of cards?

For ease of analysis, assume an oversimplified card game:  Alice and Bob are each dealt 1 card (*).  Each player looks at his or her own card, then chooses an amount to bet; after both players bet, they reveal their cards to each other.  The player with the highest-valued card wins.


So, at the point marked * above, exactly what data do Alice and Bob exchange?  (Note that there have been no previous moves.)  You seem to imply that there is another layer of indirection in mapping these randomly sorted lists of integers to card values:  Alice and Bob each produce a permutation; and their permutations are merged interactively, step by step, to form the deck of cards.  Am I on the right track here?

I know quite well what ECDH is.  I also know about commit-and-reveal schemes using ECDH or similar.  OP didn’t mention ECDH; he spoke of ECDSA.  Moreover, and more importantly, ECDH does not solve the problem.

The players in a multiplayer card game need to agree on a shared card order which is secret to all of them, such that each of them knows only his own cards.  Whereas ECDH lets two parties agree on a secret known to both of them, over an insecure channel; or as you imply, it can commit the players to their keys, such that each player knows only his own key.  How does this help, praytell?

OP seemed to imply some sort of cut-and-choose protocol:


But I don’t see how that helps, either:  All players must use the same permutation of the deck; it must be an unbiased pseudorandom permutation; but none of the players can know the permutation.

---

That is a
...however, you have implemented it with modulo bias.  It is one of the most common implementation errors of this type; if I had guessed one error that would pop up in this thread, it would have been modulo bias.  Dealing with randomness is hard!

Your to variable must be selected from a uniform random distribution in the range of [0, i].  Your entropy is (I hope) uniformly random in the range of [0, 2²⁵⁶ - 1].  Using the % to go from one range to another introduces a bias; and it’s bad enough if enough money is on the line, someone will probably exploit it in practice.  The floor division that you apply to your remaining entropy will also introduce some additional bias.

If given an input of 256 uniform random bits (still not explained), and a goal of Fisher-Yates shuffling a card deck, I would suggest using the 256 bits of entropy as the input to a KDF, using the KDF to expand the entropy, and then using chunks of the expanded entropy with the algorithm described in my above-linked “modulo bias” post to pick numbers uniformly at random in the ranges of [0, 51], [0, 50], [0, 49], ... [0, 1].

But be wary of how you do this, because...


Well, it depends how you apply them.  You need for each of the 52! possible card permutations to be equiprobable (or so close to it that any bias is negligible).  If you get this part wrong, then you can run into a sort of a different version of the modulo bias problem...  See what I said about “state space”.  It will not be a problem if you use a KDF as I said.  It may be a problem if you try to design your own ad hoc scheme for turning the random seed you have into the random numbers you need.


Nit:  It is actually a 226-bit number.  2^225.581... has 226 binary digits.

How do you map the pseudorandomness of keys to cards?  —Or more precisely:  How does your scheme generate the ordering of cards in a deck?

The ordering of a deck of cards is a permutation.  You have not explained how you permute a single deck of cards, in a way that is agreed between players.  You need to do a Fisher-Yates shuffle, or something similar—but you want to do it based on BIP 32 keys, you want to do it based on keys held by different players, and you must somehow do it without letting any player discover any other player’s cards.

I read your post twice; and I do not see any hint of how to solve this problem.  (There are other issues, but let’s start here.  N.b. that because 52! is not a power of 2, you will need a very big state space to do this securely...)

Go fuck yourself.

Joe_Bauers is asking a question about the mining algorithm for his altcoin, which currently has “Market Cap Rank: N/A” on CoinGecko—but it’s listed on Yobit with a 40% spread (!) and no depth (!!), if you want to get cheated.

His mining algorithm has a flaw he does not see.  When time permits, I may post on his altcoin’s development thread with advice for miners who want to exploit it.  The discussion is off-topic on this thread; I will delete further posts about it.


What he is actually doing is arguably even worse than that.

<edit type=off-topic>

No, the dreadful result is that your chain tip will be unstable.  You are giving miners an incentive to build only on blocks that require the next block to use an Nfactor of 18; but you are also giving miners an incentive to broadcast any block they find.  You are also giving miners with significant % of hashrate an incentive to withhold any blocks they find that require the next block to use an Nfactor of 18, build on that in secret, and then broadcast the result.

The ultimate result will be many orphans and reorgs, and a chain that messily converges on having mostly or only blocks that require the next block to use an Nfactor of 18.  If your coin ever has enough value to attract an ASIC designer, then the ASIC will probably do Nfactor = 18 only, and still dominate the network; so I guess that this has the benefit of being ASIC-friendly.
</edit>

---

Thanks for the link; I had not seen that thread.  Some of the posts there invited a Nullian rant which is yet unfinished...

Summary:  We went to sleep, and dreamt of a universal platform.  We awoke in a nightmare where the universal platform is the web browser, the universal language is Javascript, the universal ISA is Webasm—and the morals of youths have been corrupted so that they promiscuously run network-loaded executable code from random strangers as a lifestyle.  I want to kill myself, or at least take up a hobby of severe alcoholism.

There are no good ways of dealing with this.  How can one mitigate the horrors?  If I were developing a web app that needed to generate secrets inside the browser, then I would start by reviewing the major browsers’ implementations of crypto.getRandomValues().  Then, I would hope that the “move fast and break things” browser developers don’t change it, accidentally or on purpose.  —Then, I would take a strong drink and/or shoot myself in the head.

As for other platforms:  Every major OS offers an API for obtaining randomness.  Use it.  If it is bad, use a different OS.

A much bigger problem nowadays is an OS running inside of a VM.  A hypervisor must offer a hypercall for obtaining randomness from code that runs “on the metal”, and a guest OS must use it.  Otherwise, the guest OS kernel has the same problem as any application running in userland:  It lacks sufficient hardware access to measure nondeterministic inputs.  Another big problem is, of course, embedded devices... sigh.

The good news is that you only need to obtain a 256-bit random seed.  If you have a 256-bit secure seed, then you can expand it to as much “randomness” as you may desire.  That is what BIP 32 does!  It is cryptographically secure; and there are good ways of doing this for any application, including applications that require forward secrecy.  The focus of my OP here was about extracting randomness into a secure seed, not about what to do after that.

---

This reflects the beginning of OP here, and also an essay that I have been intending to write for the Ivory Tower...  We do not live in the physical world.  The real world, the crypto world, is a world of numbers and computations, where all attackers are computationally bounded.

You behave accordingly, when you generate a Hierarchical Deterministic wallet with BIP 32:  It is computationally pseudorandom, and thus secure against a computationally bounded attacker.

In this context, people who obsess about “information-theoretic security” have no idea what they are talking about.

(N.b. that the whole Linuxland argument looks very foolish to me.  On my BSD systems, /dev/urandom is a symlink to /dev/random; and /dev/random behaves more or less similarly to urandom on a Linux system, except for some extra safety features at boot time when the system hasn’t yet been able to seed the random generator.  In my opinion, Linux should do the same thing.)

Everyone got sidetracked with the fun game of cracking keys that were purposely created to be insecure.  Nobody answered the essential substance of OP’s questions.

From an inexpert position, Phillwilk politely and intelligently some important questions about Bitcoin’s security.  He is completely incorrect in some of his basic assumptions; his questions should be answered!

The summary version:

• Securely generated public keys that are exposed on the blockchain are not vulnerable to being broken.  Not even by Pollard’s kangaroos.
• The exposed public keys being broken in the challenge thread are from a restricted keyspace.  They were purposely generated to be insecure.  That is why they can be broken.
• The reason to avoid address reuse is not security, but privacy.  Exposing your public keys does not make them vulnerable to cracking.  Whereas reusing addresses is sort of like publishing your bank statements to the whole world.  It reveals information about how much money you have, and where that money is.  That can make you vulnerable to attacks by hackers or armed robbers.  But it does not make your keys vulnerable to cracking, whether by Pollard’s kangaroos or otherwise.

The whole purpose of a “public key” is that it is safe to make public.  If a public key that gets revealed is vulnerable to cracking, then the cryptographic algorithm is totally insecure!  Whereas Bitcoin uses the secp256k1 algorithm, which is quite secure.

---

Define “drastically”.

In nontechnical terms, think of it as if Bitcoin’s public-key security were a mountain.  Pollard’s kangaroos hop in with some dump trucks, and they remove some dump-truck loads of rocks from the top of the mountain.  The mountain is still huge!  Taking a bunch of rocks off the top does not make a meaningful difference.

The challenge keys that are being cracked are purposely created not to be a mountain, but rather, to be a pile of rocks the size of a house.  Pollard’s kangaroos hop in with their dump trucks...  It doesn’t take them very long to haul away all of the rocks.

The problem with this metaphor is that Bitcoin’s security is not the size of a mountain; it is more like the size of a planet.


Yes.  However, this causes no meaningful loss of security.

The notion of some security benefit to hiding keys behind hashes is a pernicious myth in Bitcoin.  It is based on ignorance about cryptography.  People who make such claims do not know what they are talking about.

The purpose of a public-key cryptosystem is that the public key can be made public.  If a public-key algorithm loses security upon publication of the public key, then the algorithm is broken, and it should never be used for any purpose whatsoever.

Ethereum reuses known public keys.  PGP uses known public keys.  The TLS certificates that authenticate HTTPS in your web browser use known public keys.  It is secure to do this.


In proper usage, yes.  But this is for reasons of privacy, not security.  Re-using addresses makes blockchain analysis so easy that it’s like publishing your bank statements on the Internet, where they can be read anonymously by hackers, scammers, stalkers, robbers, etc.


This is not the reason to avoid address reuse.


Smart question.  The answer:  Revealing the public key causes no meaningful loss of security.


The limiting factor is Pollard’s kangaroos will need to jump around for trillions of years to crack a securely generated key.  Pollard’s kangaroos are “fast” insofar as they are faster than other methods, which would take even longer.

Last year, on this forum, Pollard’s kangaroos cracked a key restricted to a 115-bit keyspace.  Securely generated public keys are generated uniformly at random within a 256-bit keyspace.  And the difference is not linear:  A secure Bitcoin key is not 2.2x (256/115) harder to break than a 115-bit key, but rather, about ten thousand million trillion (10²¹) times harder to break.

My maths here are back-of-the-envelope, but should be approximately correct within a few orders of magnitude; and the numbers here are so astronomically huge that any error makes no practical difference.  If someone wants to quantify this more precisely, that would be interesting.


Thanks for asking your questions courteously and intelligently.

In the same thread whereby I had previously laid on the altar of the Laser-Eyed Catbat Witch the mysterious sacrificial txid 000000000fdf0c619cd8e0d512c7e2c0da5a5808e60f12f1e0d01522d2986a51, the aptly-named cultist cabalism13, who previously topped me up to 1000, has now cursed me to catmification:

I suggest that you should grant “Legendary” rank and special badges to members who get listed here:
https://github.com/jlopp/physical-bitcoin-attacks

Also, if you need funding to get started, perhaps you should request sponsorship from Chainalysis.  (If you don’t work for them already.)

There is hereby a failure of human language usage:  The word “consensus” is overloaded.

In Bitcoin, the word “consensus” has the very specific technical meaning.  It does not refer to an agreement amongst humans, as in colloquial usage.  Rather, it denotes the resolution of a synchronized state in a distributed system.

Compare and contrast other distributed consensus protocols such as Paxos (the Lamport consensus protocol, not the blockchain company).

In Bitcoin, the consensus means that all nodes arrive at the exact same conclusions about the current global state of the blockchain ledger:  The set of valid transactions that exist, the meaning of each of those transactions, and the order of those transactions.  It means that if Alice sends two transactions that attempt to spend the same coin, then every (honest) node in the world automagically agrees on the decision of which of the two transactions is valid, and which is invalid as a double-spend.  It means that if Mallory mines a block that violates consensus rules, all (honest) nodes file the block in /dev/null as if it never existed—regardless of the POW shown in its block header.  Etc...

The Bitcoin ledger is a single global truth.  Mutually untrusting nodes agree on this one truth, with no central authority to call the shots or enforce rules.  The only information available to each node is a bunch of blobs of data that the node receives from anonymous, potentially hostile parties.  And—the whole thing works!  It is so secure that the network can be trusted with a trillions of dollars worth of total value.

That is the meaning of the Nakamoto Consensus.