I'm not that much into Linux, so playing with /dev/urandom and so on is not for me.

$ hexdump -vn16 -e'4/4 "%08X" 1 "\n"' /dev/urandom
44393B19866635398D4656494441C7BD

And now the idea: why don't just use Ledger (only!) as seed generator?

Is it anything I've missed?

Wow, I'm surprised people still try to argue on this topic, after revisiting it over 2 months later.

Is there anything new from Wasabi / zkSNACKs, any changes in the software or system architecture? Because in that case, I'd look into it to update my Wasabi blacklisting update - open letter / 24 questions discussion thread. Although I highly doubt that.

And on top of that, there are consensus rules, to accept only valid commitments, and to decide, who can create a new commitment.

Thoughts?

However, a bump in the road I have encountered relates to disabling the Intel Management Engine (IME) on my Supermicro X11SSH-F motherboard using Coreboot.

I see they announced that the cryptography libraries will be available as open source and that they will have all the features of current wallets with a friendly UI.

Some simple features like this may help beginners to avoid losing their investments.

It is an interesting site but there are some weirdness in it too.

For example they are categorizing/naming 0xbb to 0xfe as OP_RETURN_XXX which is a bit misleading. These are undefined OP codes meaning the interpreter fails if it reaches any of these bytes when reading/interpreting/executing the script stream. Even though in action this is performing the same task as OP_RETURN but it is not the same. Being "undefined" means they can be defined at some point. For example in witness version 1 when the interpreter reaches these OP codes it returns as a successful interpretation (since it reached OP_SUCCESS) not the way it treats OP_RETURN (0x6a) which is failing right away even in witness version 1.

We should probably help out and fill in the remaining ones.

Any suggestions?

I bet, he uses Tor or at least paid VPN. I didn't have any problem though. By the way, that's only 1.3 MB, I have no idea how can someone exceed transfer quota.

You, ser, are correct! In the context of Bitcoin, real actual scaling should be defined as, "increasing network throughput, without sacrificing decentralization". - That's probably where the problem is, because different people in BitcoinTalk have different definitions of "scaling". But to many, it merely means increasing the block size.

Dan bagaimana menurut agan?

- Transaksi bitcoin membutuhkan konfirmasi jaringan sekitar 10 menit dan untuk membayaran langsung itu dalah waktu yang sangat lama
- Biaya transaksi yang cenderung mahal untuk pembelian barang dalam jumlah kecil

- Jumlah bitcoin yang beredar tidak terlalu banyak

Zeal hopes to solve issues related to scams and hacks with a wallet that the company said "solves the security problem with advanced security checks and previews for web3 transactions that keep people safe from scams."

The Eloncoin sig campaign continues to prove it hired some of the dumbest posters to ever have accounts on this forum:

The source also mentions the scope of this same-side bias in a betting scenario.
If you bet $1 on the result of a coin toss to get $2 if you predict correctly or lose the $1 if you predict wrong, you would earn an average of $19 after 1000 coin flips. But knowing the starting position of the coin is essential.

Could these findings lower the security of seeds generated from coin tosses, considering that the starting positions of the coins aren't known to a third party?

It's simple. When a miner mines a block, they are the first to have verified that block; it happens during mining to check for the validity of the transactions. When they broadcast their block, the rest of the miners must firstly verify it before mining on top. The bigger the block size, the more time it takes to verify the block, and hence, the more the time the lucky miner gains to continuing mining alone.

And it's not just verification, it's propagation as well.

On one hand, bitcoin remaining to be in this 1 mb size limit ensures that decentralization is taken care of

and that no one has to pay so much fees in the future.

Yes, we sent an identical letter confirming the reserves to the user LoyceV. We also expect ETFbitcoin if he shows interest in this.

we also want to note that icopress and LoyceV were informed in order to permanently delete the signed message after checking and making sure of its legitimacy.

This is a feature, not a bug. You want to compress transactions based on public keys and signatures, while leaving for example Ordinals uncompressed. In this way, regular users could have cheap transactions, while Ordinals users will still pay a lot of satoshis for pushing their data on-chain. Unless they will compress them in some way, but I doubt it. Compressing regular public keys in some aggregated signature is much easier than compressing some arbitrary data pushes.

In general, Ordinals are incompatible with many protocols, for example CoinJoin or cut-through. But it is their problem, not mine. If users want to use protocols, that were not tested enough, it is their choice, and they should pay for their spam, while regular users should have a way to make their transactions cheaper.

We kindly ask the following users to correct their early comments/notes in view of the current state of the service: --snip other user-- @ETFbitcoin