"pseudorandom" isn't any kind of meaningful warning, all (typical) RNGs are pseudorandom. Not providing sufficient entropy to seed the RNG is something altogether different. The only alternative is an expensive HRNG (a separate rackmountable entropy generator, in essence), and even then I seem to remember that this only improves the quality of the entropy seeding (i.e. the RNG still produces pseudorandom numbers). stating more plainly what the security properties of the code really is would help, but I'm not sure it would have made a difference in these recent thefts. Anyone who compiles this code themselves (and I'm pretty sure that's necessary, no organization was building + distributing binaries) is taking a leap into the world of trusting their own judgement in any case. <-- edit i was too lazy to check thoroughly, libbbitcoin did distribute pre-built bx-seed binaries, thanks gmaxwell the quality of the entropy seeding an RNG is so fundamental to secure use of cryptography, and yet truly understanding how and why are immense tasks for any human. so I do sympathize with those who were stolen from, because I'm not happy with my own grasp of the issues. but we may, in the end, have no choice but to do so, i somehow doubt this is the last time that inadequate assessments of cryptography in software will burn people, whether cryptocurrency or otherwise |
|
|
|
e-sim is a step in the right direction for mobile subscriber tokens, i believe the physical SIM card system turned into a rats nest of vendor malware nasties that you weren't always aware of, and even if you were, were not easy to get rid of. an e-sim format could (in principle) be open/free software, and even if it wasn't, it can be analyzed and tamed by those with the skills to do so. so I'm looking forward to using them, although i'm like most everyone else in that i don't have a phone that supports it yet. and also, phone number? who even uses those these day?  |
|
|
|
It amazes me that places like Argentina don't have a huge presence in bitcoin. It isn't as if bitcoin's value as an inflation hedge is hidden.
maybe it's bigger than the available evidence tells us. Breaking argentine capital controls is probably only overlooked for small fish and well-connected fish, yet with a country that has a long term/endemic regime of capital controls, all sorts of people are looking to break those rules somehow. Bitcoin (and other cryptocurrencies) are no doubt the most accessible tools to do so but maybe the problems doing that in argentina are very specific; the Turkish seem to be engaging in cryptocurrency trading completely openly (tourist-area foreign exchanges have huge Bitcoin and Tether logos on the street), and their hyper-inflation is not as acute as in argentina, and only began relatively recently |
|
|
|
If Bitcoin is declared illegal by entire developed world, it will be practically unusable. Sure you could participate in an alternative economy, risk penalties to make some small purchases, but you won't be able to use it for any significant transactions. that's not how it's worked in recent history. The Soviet Union had similarly repressive rules on low-level trade, and the free market was thriving (but just for trustworthy people, naturally) with attitudes like what you're displaying here, people wouldn't trust you, so I understand how you can't imagine it. I spent the Covid-19 lockdowns: - going to cool (illegal) parties
- buying food from farmers and from the backdoors of small independent shops
- crossing borders of "nations" in carefully chosen places (using "off-road" transport of various descriptions
 ) when needed
my guess is you were wearing 5 masks, swimming goggles and kleenex boxes on your hands and feet (Howard Hughes style  ) and a hula-hoop suspended over your shoulders to enforce "safe-distancing" good luck with your "safe" choices, but i'm gonna stick with living dangerously |
|
|
|
|
from the perspective of a highly "westernized" finance infested economy, I understand your position
but that represents only one portion of the world, and it's shrinking in influence and dominance
the rest of the world is still made up of alot of small independent businesses, and they didn't forget the cultural reasons that those places remain that way. Look at India or Nigeria, huge economies where tough crackdowns on real decentralized capitalism led to total failure for those "governors" who tried. These cultures all know the escape routes, and aren't afraid to use them.
and that trend is only spreading, as people are being forced into it, ever closer to the literal borders of the western over-financialized system (Turkish lira is failing faster and faster these days, and Ankara and Istanbul are full of open cryptocurrency trade). the so-called PIIGS countries of europe will be the powderkeg imo, as the prevailing attitude there is to take what they want of the financialized overly-controlled stuff, and leave the parts they don't like.
so I think your focus on the "on/off ramp" argument is flawed, and really I said it in my other reply: real people know they have real stuff to trade, and won't trade it for money that is too dysfunctional. Period.
|
|
|
|
is it not detailed in the nostr protocol documents?  edit: sorry, I can't read I imagine they've used the exact same method that Bitcoin uses, which means you could do some copy-pasta funny business directly from the appropriate section of Bitcoin Core's code, providing you're either writing C++ or that the pertaining portion of the code is valid C, in which case you could use C instead (not much consolation seeing as writing good C is arguably even harder than writing good C++) AFAIR, BIP 340's use of schnorr sigs over the secp256k curve was previously not something anyone else had done (at least in publicly available code, I believe schnorr signatures were still patented in the early days of Bitcoin, and so segwit v1 was one of the first widespread uses of schnorr sigs after the patent expired). with that in mind, there's probably no better place to go than BIP340 and it's implementation in the Bitcoin Core codebase |
|
|
|
Assuming you would want to exchange crypto/fiat at some point - you're still at the mercy of the regulators and whether or not they allow crypto/fiat exchange.
but that's the crux of decentralized currency's raison d'etre, is it not? unless it becomes impossible to simply give central bank currency to other people without even the slightest risk of the transaction being delayed and/or reversed, exchanging said currencies for Bitcoin (or whatever else) will always be possible, whether the so-called authorities like it or not in a world where that becomes truly impossible (at least in practical terms, and we're for sure getting closer to it), the actual currency itself loses it's status as well as it's value, because it is not a meaningful means of exchange any more (which is far more serious than simply losing relative value to other tokens for trading). It ceases to become proper money in the most fundamental sense, and it will hence be rejected by those who should apparently be subjected to it one way or another, the instrument with the best money properties will win out. |
|
|
|
bitcoin mining rig under a volcanic renewable energy source in El-Savador, bitcoin is environmentally friendly.
disagree (not sure if this is the linked article verbatim, didn't check) this is yet another (and there are soooo many ) example of IPCC driven corporate drivel. most renewable energy products destroy or disrupt pretty large natural habitats and the (former) ecosystem that depended on it. Hydro dams are perhaps the worst, and I was surprised to see recently that experts on desert ecology claim that solar farms ravage the extensive underground system of plant roots that represents a significant part of the livable portion of that type of habitat (who knew?). but this is a case-by-case thing if ever there was, perhaps volcanoes don't house much wildlife to speak of (after the revelations about the desert though, I wouldn't be surprised if that's wrong) I understand that going back to the stone age is the only realistic way to genuinely protect wildlife from human encroachment. But please, let's call it like it is: renewable energy projects invariably fuck the natural world up, and so the proven false arguments about anthropogenic climate change are in fact hiding the reality that industrial landscapes (which renewable energy plants are) are being extended even further into nature in the name of preserving or protecting it. quelle surprise: UN agency tells extraordinarily humongous lies that destroy the very thing they claim to seek preservation of, and generate further money (for their friends) and power (for themselves) in the process. |
|
|
|
Well, if it is not legal to use Bitcoin in Morocco as a payment option, then he broke the law. The butthurt women on the other hand, should have gone to prison too, because she accepted Bitcoin as a legal tender for the Ferrari.  is there anyone else you'd like to send to prison today, your Honor the Justice Kakmakr? the real crime is actually being committed by the legislators: there is no ethical reason to punish people for freely partaking in business with one another, and so it should not be punishable to begin with why any Bitcoiner would have such an obsequious mindset is beyond my reckoning |
|
|
|
Then: This can take a few seconds to complete. hmmm, one ought to be careful doing that. these node-in-a-box systems could have a bitcoin service that's configured to recognize when bitcoind dies and restart it ASAP. the user might see the bitcoind process successfully go down, confidently sends poweroff, and meanwhile bitcoind is restarting (or even fully started) before the machine completes poweroff. bitcoin is more resilient to being unexpectedly killed than it used to be, but there are still no guarantees against corrupted data (which means resyncing the whole chain in the worst case). although I'm not sure what linux does to kill processes on poweroff, if it's standard kill [pid] (as you've written above) then it would actually do the right thing and wait for bitcoind to finish correctly before poweroff completes ( kill sends SIGTERM by default, which is at least one of the signals bitcoind catches to do an orderly shutdown) so check what the OS actually does, and preferably use the in-house command for shutting bitcoind down before poweroffand yes, definitely never just turn the computer off at the wall, you're asking for problems that way |
|
|
|
Headers first, which are handled across multiple threads. Each valid header (where the PoW checks out) is queued to be written by whatever thread checked it, so blocks often end up out of order on disk past the last height milestone (process is single threaded up until then), which was around 420k? Core discontinued that milestone ever since, AFAIK.
ahhh, that's it. I wonder how that might change if the assumevalid milestone is ditched for the pure p2p-based algorithm that went into 24.0? i've not yet looked at any of it, but as things are, for sure this is a pitfall/footgun for Armory users migrating databases to different machines (users will often be shorter on disk space than planned during these types of task, and if the data requirements stopped growing then either Bitcoin died or if we're lucky, some ZKP scheme ate the blockchain finally) LMDB is a plain <key, value> store, unlike SQL databases it doesn't have a concept of tables and records, so it's preferable to split the keys via some prefix scheme. Therefor all keys end up with an extra prefix byte at the I/O layer. ah, that's pretty simple, good to know but it was certainly not 0xFFFF (which is 4 bytes anyway, no?)
2 hexits per byte. Each hexit encodes a 16 bit value: 0-9, A-F (I use hexit cause I've seen that once a long time ago and found the naming elegant, I don't think anybody else does =D) better a snappy name than some of this overwrought computer science terminology imo. I always liked "nibble" (which is half a byte IIRC) and yes, 0xFF is obviously 8 bits, I blame old age Comments live in the wallet. Address comments are keyed by address, tx comments are keyed by tx hash. Tx comments are resolved at each ArmoryQt load, by checking for tx hashes in the ledger. As long as your DB works, the wallet will find its comments. phew, thank satoshi for that (well, i suppose that was Alan's work, etotheipi is up amongst the bitcoin deities these days) I've added a feature to export/import meta data in the new wallet format. It carries out address chain length and comments among other things. Thinking of adding a checkbox in the "Send" dialog to carry the structure along an unsigned tx blob to backup the meta data in the offline wallet. This would persist all that stuff in a saner fashion, though none of that data will be covered by paper backups. that sounds pretty neat, so you could lose the watch-only copy somehow, and still have wallet metadata backup coverage in the offline wallet. But it wouldn't work on my current system, as I have it set up so that the user partition is a non-persistent LVM snapshot, the OS ditches the snapshot upon closing the VM. Alan was thinking of a system to share meta data. It was to be an online store where you key your data by some hash that is only known to you. The idea here was to synchronize multiple signers over multisig (something like passing the unsigned tx around between a phone and a PC). Maybe something like that could work to persist wallet meta data, by encrypting it to some private key in the wallet. However there's an issue of authenticity: anyone can encrypt data to your private key. The scheme would need some more thinking to keep the data private. Something to mull over.
just signing the encrypted data as part of the protocol seems like a ready solution? and why would it matter, once someone else encrypts data using a public key of yours, what could they possibly do with that? they can prove the data encrypts to that value, but it's common knowledge that this is how keypair cryptography works for decades. what am I missing? The whole Qubes thing still eludes me tbh. I don't know how you put up with it. VFIO over kvm is all I can stomach in terms of virtualization, though I've got some chops with docker now and I plan to make ArmoryDB fully dockerizable at some point.
right, docker is the quick and easy way (using native kernel cleverness from cgroups or namespaces), although there's some kind of closed source wrinkle to it all that escapes me, maybe that's outmoded though. Qubes was always like pulling teeth, but it's made for one thing only: overly cautious security. and so it fits Bitcoin usage well (especially for old timers like me with a stash to defend). using Qubes for anything else is not fun, although it's improved over the years (maybe even next release it will play video using the GPU over IOMMU, in just 1 VM across the whole OS!! atm playing video induces the CPU fan to push so hard that the computer levitates a little) |
|
|
|
If the underlying block data structure was to change past a certain block, swapping in an old clean DB state would eventually lead to an error where the offsets on record mismatch the blocks on disk. aha, that may well be it. I didn't have juggling space for Armory's very own bitcoin blocks folder, and so re-synced the bitcoin blocks from an older copy that was ~18 months behind the blocks dir that Armory databases were synced against. And of course, the layout of blocks isn't deterministic (because of orphan blocks, or something else also?), and Armory database cannot understand the 18 months that was freshly synced (every block before that was from the same blocks dir I've been using with Armory for perhaps 10 years) Unless it starts with 0xFFFF, it's not a zero conf. I'm referring the data logged here: -ERROR - 18:10:17: (lmdb_wrapper.cpp:2087) (scrubbed_but_valid_hexdata) yeah definitely not 0xFFFF. I looked at the code in lmdb_wrapper.cpp, it seems that the first byte is some kind of fixed header? that was consistent for each data lines (obviously a different kind of problem if not ), but it was certainly not 0xFFFF (which is 4 bytes anyway, no?) regardless, the (scrubbed_but_valid_hexdata) bytes 1-4 were not 0xFFFF either At any rate, you're likely in for a rebuild & rescan. crap. how can I transfer the transaction comments across from the old db to the rebuilt one? you're going to say "write a small lmdb parser that does it manually", right? It's hard to tell without a log. I've fixed a few of these bugs on the way to 0.97. Those were not minor changes, I don't think it's reasonable to try and cherry-pick them back into 0.96 for a cheap fix.
still enthusiastic about this, but getting Qubes 4.1 into shape was more challenging than expected, plus I have more excuses  this effort was a part of getting my basic working machine ready to switch permanently, so hopefully I'll start trying out 0.97 again |
|
|
|
maybe during the time it takes to complete the legal proceedings, the seller might change their minds because BTC started to appreciate again? would suck if she already gave all the BTC to the Moroccan legal system and they refused to give it back, but of course, only for her. I would consider that outcome true justice, for the crime of avaricious ignorance. |
|
|
|
Try deleting "zeroconf" in your db folder, that will wipe the mempool.
sadly, no dice. the .armory/databases/zeroconf file is regenerated (size 16384 bytes), and the same volley of "BLKDATA DB does not have the requested ZC tx" messages occurs |
|
|
|
I assume you're left hanging with no transactions showing in the lobby?
right, there were no unconfirmeds waiting when I last shut Armory down edit: the transactions window does show and scrolls etc. strange behavior is that the 2 most recent transactions can handle 'View Details', but all others produce this: Traceback (most recent call last):
File "/usr/share/bin/../lib/armory/ArmoryQt.py", line 3387, in showContextMenuLedger
self.showLedgerTx()
File "/usr/share/bin/../lib/armory/ArmoryQt.py", line 3345, in showLedgerTx
cppTx = TheBDM.bdv().getTxByHash(txHashBin)
File "/usr/share/lib/armory/CppBlockUtils.py", line 2824, in getTxByHash
return _CppBlockUtils.BlockDataViewer_getTxByHash(self, txHash)
<class 'CppBlockUtils.DbErrorMsg'>: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7961a5215930> >
(ERROR) Traceback (most recent call last):
File "/usr/share/bin/../lib/armory/ArmoryQt.py", line 3387, in showContextMenuLedger
self.showLedgerTx()
File "/usr/share/bin/../lib/armory/ArmoryQt.py", line 3345, in showLedgerTx
cppTx = TheBDM.bdv().getTxByHash(txHashBin)
File "/usr/share/lib/armory/CppBlockUtils.py", line 2824, in getTxByHash
return _CppBlockUtils.BlockDataViewer_getTxByHash(self, txHash)
DbErrorMsg: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7961a5237420> >
Traceback (most recent call last):
File "/usr/share/bin/../lib/armory/ArmoryQt.py", line 3387, in showContextMenuLedger
self.showLedgerTx()
File "/usr/share/bin/../lib/armory/ArmoryQt.py", line 3345, in showLedgerTx
cppTx = TheBDM.bdv().getTxByHash(txHashBin)
File "/usr/share/lib/armory/CppBlockUtils.py", line 2824, in getTxByHash
return _CppBlockUtils.BlockDataViewer_getTxByHash(self, txHash)
<class 'CppBlockUtils.DbErrorMsg'>: <CppBlockUtils.DbErrorMsg; proxy of <Swig Object of type 'DbErrorMsg *' at 0x7961a5237420> > sorry didn't quite read what you said Try deleting "zeroconf" in your db folder, that will wipe the mempool.
I took a look at that file before the OP, and thought it strange that it was 2500Kb, but then considered that I don't really know what it's purpose is, despite the name. a different vm is busy using the external disk I'm using for bitcoin network data, but I'll try this in a short while and report back
aside, this highlights a bug I knew existed but worked around using known-good backups of the .armory/databases dir: occasionally (don't know why), the transaction scan refuses to progress beyond the top block from the previous run of Armory (at which point the known-good backups gets brought in). as we were not yet at the RC stage for 0.97, I thought the bug may fix itself during the run-up to that stage. seeing as that's (0.97 RC) not yet on the cards, I figured i'd bring it up now anyway |
|
|
|
I tried getting Armory 96.5 working on my Qubes 4.1 machine (4.0 is really not supported any more), and all was well until this last part compiling was really the same as 94-96.x, using debian 10/buster toolchain, no issues dbLog.txt: -INFO - 18:09:08: (BlockUtils.cpp:915) blkfile dir: /home/user/.bitcoin/blocks
-INFO - 18:09:08: (BlockUtils.cpp:916) lmdb dir: /home/user/.armory/databases
-INFO - 18:09:08: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 18:09:08: (BDM_Server.h:263) Listening on port 63221
-INFO - 18:09:08: (nodeRPC.cpp:57) RPC connection established
-INFO - 18:09:08: (BlockDataManagerConfig.cpp:919) waiting on node sync: 99.9997%
-INFO - 18:09:08: (nodeRPC.cpp:425) Node is ready
-INFO - 18:09:08: (BlockUtils.cpp:1108) Executing: doInitialSyncOnLoad
-INFO - 18:09:08: (BDM_Server.cpp:1121) registered bdv: 4a80c146a3552190f2b4
-INFO - 18:09:08: (DatabaseBuilder.cpp:199) Reading headers from db
-INFO - 18:09:25: (DatabaseBuilder.cpp:238) Found 723305 headers in db
-INFO - 18:09:33: (DatabaseBuilder.cpp:64) Rewinding 100 blocks
-INFO - 18:09:33: (DatabaseBuilder.cpp:71) updating HEADERS db
-INFO - 18:09:33: (DatabaseBuilder.cpp:493) Found next block after skipping 1660080bytes
...
-INFO - 18:09:35: (DatabaseBuilder.cpp:281) parsed block file #3599
-INFO - 17:53:09: (DatabaseBuilder.cpp:281) parsed block file #3600
-INFO - 17:53:11: (Blockchain.cpp:248) Organizing chain
-INFO - 17:53:18: (Blockchain.cpp:370) Organized chain in 6s
-INFO - 17:53:24: (DatabaseBuilder.cpp:76) updated HEADERS db in 908s
-INFO - 17:53:25: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 17:53:25: (DatabaseBuilder.cpp:1231) verifying txfilters integrity
-INFO - 17:54:06: (DatabaseBuilder.cpp:1314) done checking txfilters
-INFO - 17:54:07: (DatabaseBuilder.cpp:134) scanning new blocks from #723305 to #790065
...
-INFO - 18:06:46: (BlockchainScanner.cpp:852) scanned from block #789756 to #790065
-INFO - 18:06:46: (BlockchainScanner.cpp:214) scanned transaction history in 759s
-INFO - 18:06:47: (BlockchainScanner.cpp:1789) resolving txhashes
-INFO - 18:06:47: (BlockchainScanner.cpp:1848) 0 blocks hit by tx filters
-INFO - 18:06:47: (BlockchainScanner.cpp:1937) found 0 missing hashes
-INFO - 18:06:47: (BlockchainScanner.cpp:1982) Resolved missing hashes in 0s
-INFO - 18:06:47: (lmdb_wrapper.cpp:388) Opening databases...
-INFO - 18:06:47: (DatabaseBuilder.cpp:186) scanned new blocks in 760s
-INFO - 18:06:47: (DatabaseBuilder.cpp:190) init db in 1726s
-INFO - 18:06:47: (BDM_supportClasses.cpp:1891) Enabling zero-conf tracking
-INFO - 18:06:53: (BlockchainScanner.cpp:857) scanned block #790066
-ERROR - 18:10:17: (lmdb_wrapper.cpp:2086) BLKDATA DB does not have the requested ZC tx
-ERROR - 18:10:17: (lmdb_wrapper.cpp:2087) (scrubbed_but_valid_hexdata)
-WARN - 18:10:17: (LedgerEntry.cpp:334) failed to get tx for ledger parsing subsequently, ArmoryDB only seems to perform "Wallet Properties" callbacks, most everything else produces errors in the qt log the ERROR line from lmdb_wrapper.cpp repeats dozens of times. And the gui reports "node offline" |
|
|
|
It is clear that the SEC are sharpening their teeth on the smaller operators and that they will expand their "agenda" to larger operations soon. There are gears that are being set in motion in the US government to clamp down on Bitcoin, so miners will be the easy targets for the government.
seems to like the game theory built in to bitcoin's design will work as intended though the more that people try to consolidate mining into bigger and bigger organizations, the more likely that those big companies will get targeted by the gangsters from the legislature. this simply creates more incentive for decentralized mining, in all shapes and forms. That's the alternative side to the ordinals screeching that I've not heard mentioned much: fees outperformed the block subsidy quite consistently, and I think it's reasonable these days to say that we no longer have immature markets for both fees and BTC itself. in some super-censored mining scenario, large numbers of small miners can risk ignoring the diktats (whatever they may be) that the big miners cannot. smaller miners would be more profitable, and uncensored mining simultaneously reinforces their own ability to spend their unsanctioned block rewards. It's perfectly, beautifully balanced, and it was designed that way right from the start
@ the aforementioned gangsters (desperately) trying to control this network: you've had nearly 15 years now. we're still waiting for some kind of faintly credible response |
|
|
|
I mention Grin's technology because it's very poor choice to store data. that's also true of Bitcoin, but it's not stopping people using it to store data. unless the mining pools themselves devised this concept (or other similar schemes in the future), and are operating as a cartel (i.e. refunding one anothers tx fees from data storage transactions), then people will simply run out of money to sustain these things. And even if the mining pools were doing such a thing, quitting after some critical amount of time is necessary to avoid suspicion. so it will always burn itself out one way or another. |
|
|
|
Bitcoin need to perform hardfork to adopt technology/protocol used by GRIN coin.
if Grin is better, just use it. I expect the experts are right on this one though: there will always be ways to embed arbitrary data into cryptocurrency transactions, so finding the some "best" way to mitigate it is the true answer |
|
|
|
There were technical reasons for the design decisions in BIP 342. As Andrew says in his post [ 0 ]:
"If we ban "useless data" then it would be easy for would-be data storers
to instead embed their data inside "useful" data such as dummy
signatures or public keys. Doing so would incur a ~2x cost to them, but
if 2x is enough to disincentivize storage, then there's no need to have
this discussion because they will will be forced to stop due to fee
market competition anyway. (And if not, it means there is little demand
for Bitcoin blockspace, so what's the problem with paying miners to fill
it with data that validators don't even need to perform real computation
on?).
But if we were to ban "useful" data, for example, saying that a witness
can't have more than 20 signatures in it, then we are into the same
problem we had pre-Taproot: that it is effectively impossible construct
signing policies in a general and composeable way, because any software
that does so will need to account for multiple independent limits. We
deliberately replaced such limits with "you need to pay 50 weight for
each signature" to makes this sort of analysis tractable." you've mixed it up, achow101 posted that |
|
|
|
|
Show Posts
