i think Robert Anton Wilson (fiction author) said that it was possible to ascribe meaning to any random pattern or instance of numbers if:

• one really applies their imagination
• one really wants to believe something irrespective of whether the pattern is meaningful

both types of people are a danger to themselves, and the first type particularly a danger to others


...so I'm gonna say it again: these are arbitrary goldilocks numbers; not too big, not too small, and pulled out of satoshi's... hat

I get the feeling that most of the numbers are chosen somewhat arbitrarily. It's probably not so easy to find numbers that are factors of psychologically pleasing numbers (i.e. 2, 3, 4, 10 etc), so the scheme was some kind of coin-flip compromise between using simple numbers in places where some rule-of-thumb might be helpful (i.e. the exact number of blocks in 4 years at constant difficulty for halvings), and something "ugly" for aspects that are difficult to maintain as whole numbers i.e. the supply cap.

the supply cap is actually a good example to take here: 21 million is in fact a simplification, it's some unwieldy and unmemorable amount *very close* to 21 million, but not 21 million exactly.

really this is classic bike-shedding material: satoshi had to choose something, and it needed to be: 1. arbitrary 2. not too small.
we can even bike shed the question in the OP: the question is wrong, you should be asking why satoshi chose to put the decimal point at 8 positions in either direction. Why was satoshi so obsessed with the number 8?

yeah, that's the "take home" part, i.e. the noticeable effects to the user



are you sure about this? from what I remember, the hash-wrapped version of segwit and the bech32 encoded version (i.e. native) have different sizes as inputs and as outputs when compared to each other, as well as those measurements being different to those of the previous standard (compressed-key P2PKH), and that's also in terms of literal bytes, not just the witness-discounted (i.e. "virtual") bytes.

---

I'd also make a further point:

a bug existed in the design of P2PKH outputs (the old pre-segwit standard) that could cause an exponential blowup in verification time for full nodes


this had already been exploited in reality before segwit: someone sent a transaction on the main bitcoin network that despite being valid caused nodes to verify it very slowly (taking minutes where it would normally take sub-second lengths of time). Increasing the blocksize while not fixing that bug risked an effective DOS vector against the bitcoin node network. AFAIR, even today the bug is fixed only for segwit transactions, not for older utxo types, and so the 4MB max block size is only possible in a block full of segwit inputs. Therefore every utxo without a segregated witness decreases the possible max size of a given block, otherwise a malicious actor could craft 4MB full of the slow-verifying P2PKH tx's to attack the network

it's possible things changed since then, but it's difficult to see how P2PKH could be made safe at bigger blocksizes, as it's already a standard

@achow101 maybe this belongs in dev&tech?

FWIW I intend to look at this again over the weekend, and simply haven't had time up to now. goatpig's review will inevitably be far higher quality than anything I do, what I end up saying won't amount to much more than a simple "thumbs up" (and that's despite goatpig being the author of at least some of the relevant code)

also, I feel must take some responsibility for this thread appearing. it seems I misremembered whether Armory uses libbitcoin or not, and so should have not said anything at all without properly checking. it seems that in production Armory (0.96.5) all RNG seeding is not libbitcoin code, and in fact libbitcoin code isn't used at all in 0.96.5 (or 0.96.x inclusive)

so I hope nobody was in any way alarmed by what I said in the Dev&Tech thread linked in the OP

I was being a moron, bitcoin.conf needs explicit listen=1 also, as I'm setting proxy= in there too

all working, thanks gp

maybe this needs it's own thread, but here goes....

got Armory 0.96.5 db synced in a Debian 10 VM, bitcoind 24.0

bitcoind I compiled myself using the depends build system
armory I also compiled myself standardly

• bitcoin-cli getpeerinfo | grep inbound tells me ArmoryDB isn't connected to bitcoind
• using default 8333 port for inbounds
• dbLog.txt says "RPC connection established" and "Node is ready"
• Armory footer says "Node disconnected"
• Armory dashboard says"Armory is online"

Armory is synced (as I say), but up to the block it queried at startup, it clearly reads bitcoin blocks from disk ok, but cannot receive new blocks once synced.

I'm using all the same config files from my old installation, and everything in them seems sensible (Armory isn't exec'ing bitcoind, bitcoin.conf has server=1)

I also tried running ArmoryDB with and without --cookie, hoping to elicit some kind of different error or change in behavior, but it didn't startup properly


is Bitcoin 24.0 the issue? I somehow doubt it. I've also checked to see that the VM isn't missing any dependencies, but it's hard to see what else those could be when networking is up (bitcoind is for sure connecting to the network and is currently at block 803610). building armory and bitcoind completed without any errors (I built them using Debian 10 build-essentials and standard dev packages)

mysterious, n'est pas?

I find this (Tor bridge nodes) a little unconvincing

the only way to keep the IP of the bridge node private is to never tell anyone about it (and so noone will ever use it). it only serves to perpetuate a cat-and-mouse game, where those with malign reasons to discover the IP of bridge nodes are chasing the newest nodes in order to censor them

supposedly there are pluggable transports for Tor that shape the traffic/packets to resemble generic HTTPS website traffic (which is apparently planned for BIP324 connections in Bitcoin, but the details are not yet available). If the relay then runs out of an IP range belonging to a commercial CDN, then connection fingerprinting is no longer possible (i.e. if the Tor relay/exit is on a CDN range, an eavesdropper sees just HTTPS traffic, which **could** be from any of the regular websites that also operate using the same IP range)

but this is "research level" Tor, the standard Tor client won't behave like that without modifying the config

the one exception might be that a (significant minority of) miners could just continue to use the UTXO set to do this, and try to keep their heads above water by refunding each others tx fees in a free transaction

that's pretty far-fetched though, stupid ideas are doomed to die. Ordinals only really worked in the first place because scammy people *believed* that *marks* would be stupid enough to believe in it; as I say, it's more likely that ~95% of people trading ordinals knew it was the latest greater-fool scam

nonono, the randomness only decreases if you say "Alan Turing" into a mirror 3 times with a hand covering one eye (hence summoning the actual eye of providence to the ceremony) and holding the dice you will use in the other

(accept my apologies, i agree that only good jokes belong on the Dev & Tech sub )

i must be blind, of course it does (maybe I ignored everything after the boost:: ns, I have an aversion to boost)


hmmmm...


it's definitely hard to follow this kind of reasoning: because we should all be using dice rolls to seed the RNG, let's make an oblique error message in an obscure part of the repo, to guard against a default operating mode that's catastrophic to users (who apparently received recommendations from Bitcoin Jesus II: The Revenge in "Mastering Bitcoin", an ironic title as it turns out). would an above-average reader of that book even understand the warning message?

why not simply remove ANY insecure mode whatsoever, seeing as the developer was so security conscious? it seems the answer is "demos"

but that's what ostriches do when they're scared right?

a few people upthread were panicky. maybe talking about it actually made you all a little scared, and me, well, not so much?



well, yes

disclaimer: i'm the wrong person to speak about thread safety, not enough experience

...but, the pull request doesn't seem to make any changes that should alter threading behavior, if it does it's incredibly subtle (which I appreciate is often the case with thread-safety bugs)

..surely (yeah, another "...surely...") it's good practice to document the nature of the bug, in the case where it's a subtle thread-safety bug?

---

sounds like I ought to check if Armory's use of libbitcoin could be affected. I didn't create any new Armory wallets since the date (late 2016) of the libbitcoin-system pull request, but possibly others did. Armory previously used Crypto++, which I guess was subject to a little more scrutiny (guessing isn't good enough however, I feel compelled now to check)

some people feel they need to talk to you, so don't give them your number (use a messenger app that doesn't need a phone number instead). this is exactly how I did it: got a new phone and then minimized the people who were given the number...

...which for sure included any delivery drivers, doctors or (lol) government services. these people invariably dislike dealing with me, I'm pretty proud of that too

the bad odds are that people are good at re-inventing bad ideas by dint of hubristic assumption that they're being imaginative/original. you can bet someone will go for security<-->obscurity simply because they have some exotic or old platform that they believe somehow protects them from attacks, and use it to generate seeds and/or sign txs offline etc. I realize this is many layers of (now anachronistic) hypotheticals in the case of bx-seed though, but these things bear repeating every so often



hmmm, but wasn't the low-entropy seeding limited to the bx-seed codebase, or has a similar problem been found in the libbitcoin dev toolkit?

my apologies to everyone if I didn't make this point sufficiently clear upthread...


...but I'm gonna make it here again.

this whole phenomenon is based on the NEWNEWNEW scam, most "altcoin" stuff is, and we all know it already. in fact, most people trading newly issued stuff are actually engaging in a scammy blinking contest: probably most players in the market activity know they're playing the "hold my bag" game

and then it all starts again next week with the "new" NEWNEWNEW: same game, "!!new and exciting tech!!" **yawn**


and the major irony for me is the same as it was with most of these Bitcoin protocol/relay policy/ecosystem debates; it's possible to make the whole thing worse than it really is, simply by talking about it more than it deserves

given that the information about Ordinal tokens/NFTs is available publicly somewhere, do we have a BTC value for how much this has cost?

I say this because it might help to put this all in perspective. If someone out there is losing money to the tune of > 1BTC on this nonsense thus far, I think we can safely say they will not continue to do so for long.

I didn't read the whole thread, do we know some kind of net figure for BRC-20 and it's fellow apparitions?

i defer to gmaxwells point on this: what non-real-world usage is there for a woefully insecure wallet seed utility?

these statements are rather damning taken altogether. the library author was at best absurdly negligent (that's absurdly), and I say that given that he seems to be otherwise intelligent, as well as just a little arrogant when talking live (which I experienced once). whatever the excuse, it would be difficult to trust someone like that (but i expect he will melt away into the background somewhere/somehow and it will never trouble his reputation as a developer)

---

looking at the diff in the pull request, my (non-expert) opinion is that the original code was also pretty dubious for securely seeding an RNG (src/utility/random.cpp:39-41). depending on the output of std::random_device is clearly implementation/platform specific, wouldn't it have been much more sensible to at least use some cross-platform library function to collect additional entropy? (even simply openssl, surely?). trusting the hardware and the c++ lib implementation on every possible platform (past, present + future...) seems to border on reckless to me, in my (as i say) non-expert opinion

and that's without considering the actual (uncommented) change to cast the current system time (!) to an unsigned 32-bit integer as the return type for the function providing the entropy seeding data. I'm 100% confident that you don't need to be an expert to see that this is staggeringly unprofessional, rock-bottom basic tutorials for generating entropy describe exactly this sort of practice as badbadbad


in fact, ISTM it's not even necessary to search the entire 32-bit number space?! surely it's possible to feed unix-timestamps since the 2016 date/time when the PR was merged into some common c++ mersenne_twister implementations to find every seed generated with the insecure code. either way, it's very surprising that it's taken 7 years for anyone to notice

small heads up:

BIP324 is proceeding apace. looks like we could see it as early as bitcoin core version 27.0, if not 28.0 (so ~ next summer or later).

that means bitcoin nodes can encrypt the data sent over (but not authenticate) their network connections with one another, for anyone wanting the tl;dr. This is a step toward one day obviating the need for VPN or Tor with Bitcoin clients, but is not sufficient on its own. It still improves privacy whether using VPN/Tor or not.

i'm quite proud to be using unpopular message applications


I got my new phone a few years back, and I haven't given the actual telephone number to more than about 10 people IIRC. and very few actually use that number out of those who have it, almost all messaging/calls happen over internet-based comms for me. e-SIMs with no phone number seem to be a (belated) recognition of how meaningless the telephone system is these days, a few changes to my lifestyle and I think I could ditch telephones altogether