Bitcoin Forum
June 16, 2024, 06:02:51 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 442 »
1  Bitcoin / Development & Technical Discussion / Re: Why 21m Bitcoin and 100m Satoshi? on: August 20, 2023, 06:29:14 PM
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
2  Bitcoin / Development & Technical Discussion / Re: Why 21m Bitcoin and 100m Satoshi? on: August 20, 2023, 03:05:19 PM
The real question is: why 210,000 blocks between halvings? That's the choice that lead to a total of 21 million Bitcoins. Why not a round number of blocks? Say 100,000? Or 314,159 blocks? I guess the reason was to get 4 years between halvings. If that's correct, Satoshi chose 10 minutes between blocks, he chose 50 Bitcoin per block, and he choose to have halvings every 4 years. The 210,000 blocks and 21 million Bitcoin just resulted from this.

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? Cheesy Cheesy
3  Bitcoin / Bitcoin Technical Support / Re: What are segwit's benefits and overall goals? on: August 20, 2023, 11:46:00 AM
In short,
1. Lower transaction fee.
2. Higher block size limit, assuming there are SegWit transaction on the block.

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


Fee Reduction: By optimizing the way transaction data is stored in blocks, SegWit transactions can require less space, resulting in potentially lower transaction fees.

Inaccurate information. SegWit transaction doesn't always have lower size (in bytes unit), lower tx fee is achieved since witness data is calculated differently.

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?
4  Bitcoin / Armory / Re: libbitcoin vulnerability and armory on: August 18, 2023, 01:41:45 PM
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
5  Bitcoin / Armory / Re: Armory stuck in offline mode... on: August 18, 2023, 01:23:45 PM
I was being a moron, bitcoin.conf needs explicit listen=1 also, as I'm setting proxy= in there too

all working, thanks gp
6  Bitcoin / Armory / Re: Armory stuck in offline mode... on: August 17, 2023, 12:18:41 PM
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 Undecided


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?
7  Bitcoin / Development & Technical Discussion / Re: Full Node VPN+Tor on: August 17, 2023, 10:24:08 AM
But if I use just Tor, then my ISP knows that I'm using Tor
Not necessarily, because you can use bridges. These are Tor relays that aren't publicly known

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
8  Bitcoin / Development & Technical Discussion / Re: NFTs in the Bitcoin blockchain - Ordinal Theory on: August 17, 2023, 10:11:38 AM
Not much further down the road, though.  We're already pretty close by the looks of it.  If this stuff has to exist, it should arguably do so in the most optimised way.  That's what this protocol appears to offer.  The silly-picture-selling crowd just need to utilise it.

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
9  Bitcoin / Development & Technical Discussion / Re: If you used "bx seed" you probably already lost your bitcoins, but if... on: August 17, 2023, 09:56:28 AM
Will their randomness be decreased if you speak their name? lol.

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 Cheesy

(accept my apologies, i agree that only good jokes belong on the Dev & Tech sub Smiley)
10  Bitcoin / Development & Technical Discussion / Re: If you used "bx seed" you probably already lost your bitcoins, but if... on: August 15, 2023, 09:40:52 PM
...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)
It does, it makes the random number generator thread specific. See the code after "// Maintain thread static state space."

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

I don't use github anymore but someone pinged me there, I loaded it-- only to see voskuil shitting on me: https://github.com/libbitcoin/libbitcoin-explorer/issues/728#issuecomment-1677195708  yet another reason to not use that site!

hmmmm...

Quote
This is the reason people roll dice. Trusting the OS is unsecurable.

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" Undecided
11  Bitcoin / Development & Technical Discussion / Re: NFTs in the Bitcoin blockchain - Ordinal Theory on: August 15, 2023, 09:27:12 PM
so the best way to deal with it is - not talking about it? Hahaha. It's like the ostrich's head in the sand.

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?


What's ironic is there's actually no solution.

well, yes
12  Bitcoin / Development & Technical Discussion / Re: If you used "bx seed" you probably already lost your bitcoins, but if... on: August 13, 2023, 04:16:09 PM
the flawed rng was in libbitcoin-system, used all over the place the supposed thread safety bug that motivated the change was observed in P2P networking

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)
13  Bitcoin / Bitcoin Discussion / Re: Buy e-sim with bitcoin on: August 13, 2023, 12:26:07 PM
I'm not too fond of those apps either, but I simply don't have too many choices if I want to communicate with people who mostly use those apps.

[snip]

As for having a phone number, I obviously live in a country where it is almost necessary, whether it is to deliver a package (the delivery person always makes a call before delivery) or to receive notifications from a government service or even from your doctor.

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 Wink
14  Bitcoin / Development & Technical Discussion / Re: If you used "bx seed" you probably already lost your bitcoins, but if... on: August 13, 2023, 12:17:02 PM
I think there are good odds that for any platform where the code can actually be built that function just read randomness from the OS, but you're right that it isn't guaranteed.

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


It's also likely bad for the non-cryptographic usage in libbitcoin. An attacker can observe some of the choices made by the software you can recover the RNG state then use it to predict the random choices that were used and will be used, which likely results in DOS vulnerabilities.

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?
15  Bitcoin / Development & Technical Discussion / Re: NFTs in the Bitcoin blockchain - Ordinal Theory on: August 13, 2023, 11:54:39 AM
It has come back a bit recently but I think the worst of it is over. That's the thing about degens: they get bored quickly and move on from one things to the next. After Ordinals/BRC-20, it was Doginals/DRC-20, then Ethscriptions (bring it full circle, writing NFTs in ETH tx data rather than via smart contracts, lol).

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
16  Bitcoin / Development & Technical Discussion / Re: NFTs in the Bitcoin blockchain - Ordinal Theory on: August 12, 2023, 03:40:09 PM
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?
17  Bitcoin / Development & Technical Discussion / Re: If you used "bx seed" you probably already lost your bitcoins, but if... on: August 12, 2023, 03:18:54 PM
They clearly did a bad job explaining that this command is not intended for real-world usage.

i defer to gmaxwells point on this: what non-real-world usage is there for a woefully insecure wallet seed utility?
18  Bitcoin / Development & Technical Discussion / Re: If you used "bx seed" you probably already lost your bitcoins, but if... on: August 12, 2023, 02:37:01 PM
The change happened without notice in an unreviewed PR that claimed to make the random number generation "thread safe and optimal".  The change could have easily renamed seed to "insecureseed" and/or restricted it to 32-bits of output, but it didn't.

yet the author insists there is no flaw and its working as intended is confusing to say the least (especially since he knew 32-bits could be searched quickly).

And we've still yet to see an explanation for this the fact that the authors development activity stopped entirely months ago on the very day the first exploitation appear to have happened and how that possibility squares with the denial that there was a problem in libbitcoin explorer at all.

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
19  Bitcoin / Development & Technical Discussion / Re: Full Node VPN+Tor on: August 10, 2023, 08:15:24 PM
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.
20  Bitcoin / Bitcoin Discussion / Re: Buy e-sim with bitcoin on: August 10, 2023, 07:54:35 PM
popular applications such as [snip]

i'm quite proud to be using unpopular message applications Cheesy


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
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 442 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!