It can be done, but I presume that the post-softfork nodes will treat the units of the system differently than the pre-softfork nodes. So different, that the post-softfork transactions will not be validated by the pre-softfork. Pre-softfork nodes will receive something like Alice sends 0 coins to Bob (with an extra note indicating that it's a softfork), and in post-softfork nodes, these 0 coins will be accompanied by some signature that spends new, post-softfork coins. In the proposed soft-fork, pre-softfork nodes don't see Alice sending coins to Bob, since they will see each block as *only* containing a coinbase transaction. It will look to them like Bitcoin has become permanently untransactable. What the proposal shows is that the notion of soft-fork is not as clear cut as it seems at first, and is really more of a spectrum, based on how much of the new rules are being verified, or even visible, to old nodes. |
|
|
|
Is allowing RBF cut-through transactions with higher or equal fees in Core a good idea or not?
No; that's not a good idea. If Alice can have tx1 A -> A1 relayed to all mempools for fee f, and then have tx2 A -> A1 -> A2 relayed to all mempools, and so on until txn A -> A1 -> A2 -> ... -> An for the same fee, then this one time fee f was used to generate an arbitrary amount of network traffic, which amounts to a DOS attack. That's why you want replacement txs to have enough fees to cover both the cost of their own relay, as well as the relay of the tx they're replacing. |
|
|
|
Anyway, I wouldn't want to use this little entropy like a search space of "only" 6212 aka 72-ish bits.
72 bits is clearly insufficient when subjected to a simple key derivation function like SHA256. The lack of entropy must be compensated by a corresponding increase in key derivation function complexity. Suppose we consider 112 bits to be bare minimum entropy for SHA256 key derivation. Then 72 bits of entropy requires key derivation to have complexity at least 2^{112-72} = 2^40 ~ 10^12. That could be a thousand billion iterations of SHA256. Or, better yet, a thousand billion iterations of a memory hard function using several GB of memory. It might take several hours, days, or even weeks of computation, but that's what lets you get away with significantly less entropy. |
|
|
|
ZeroSync [1] is implementing a zero knowledge implementation of the Initial Block Download, that roughly speaking would allow you to download only a few dozen KB of data (instead of 100s of GB) to prove that some header and commitment to a UTXO set has a valid history behind it. Verifying recent blocks still requires downloading the UTXO set. [1] https://zerosync.org/ |
|
|
|
pi is the mathematical constant with fixed digits, so any part of it can not be viewed as random because it can be calculated
Pi is believed to be normal in base 10 [1], meaning it contains all finite sequences of digits. In which case your statement is obviously false. An occurrence of some sequence of k digits in pi is only a sign of non-randomness if ithe index at which it occurs can be written in much less than k digits... [1] https://en.wikipedia.org/wiki/Normal_number |
|
|
|
6. Make sure that "n" is different than "p".
7. Validate that if you pick "n" as the starting prime, and go through all steps, you will reach "p".
You didn't explain why you want these properties of 2 curves forming a 2-cycle. Is it just because this is the case for secp256k1, as noted for example (together with other interesting properties) in [1] ? [1] https://hackmd.io/@dJO3Nbl4RTirkR2uDM6eOA/Bk0NvC8Vo |
|
|
|
If you are a block creator, then you have an incentive to create the biggest possible block. Why? Because then, you can pick some simple, deterministic algorithm, and generate terabytes of always valid transactions on-the-fly, then let your miners work on that header, and send mined block to other nodes. Then, you can start producing some next block, on top of what you created, while other block creators will try to validate what you submitted.
You appear to assume that other miners will wait to finish validating your new block before they start mining on top of it. That's not a safe assumption. Many (most?) miners will instead just assume that the new block is valid (expending so much effort on producing an illegal block is stupid and exceedingly rare) and immediately start mining on top with an empty block, while validating in parallel. Once validation completes they can then continue mining with a non-empty block on top. |
|
|
|
In order for Bitcoin to succeed, blocks must be full.
Indeed; when you combine a negligible block subsidy with unlimited throughput, you beget a lack of security. We thus have the following Emission/Throughput/Security trilemma: no coin can have all of the following 3 properties: 1) Capped Supply 2) Unlimited Throughput 3) Long-term Security While BCH gave up 3, Bitcoin decided to give up 2, making it Congested-by-Design. |
|
|
|
Even before I successfully mine a block at height 481,826, can we not say that I am working on a forked version of the main chain?
Working on? Yes, we can say that. Even if you start coding the consensus changes, you're working on the fork. Forked away? That is much less clear. I would say not, since the "away" suggests each has gone its own way. |
|
|
|
The issue will arise if you make a change which breaks with the consensus rules - for example, you start considering some blocks invalid, which the rest of the network still considers valid. At that point you will have forked yourself away from the main network and on to your own personal branch.
You won't have forked away until you produce at least one block with the differing consensus rule. But unless you have a sizeable mining operation, it could take you years to even come up with a block satisfying the current difficulty... The only exception is when your consensus changes include changing the PoW and/or difficulty rules. |
|
|
|
but they still have to take requests and check if the appropriate amount of work has been done. that takes resources just doing that.
You're right that a DDOS attacker can submit bogus PoW proofs at negligible cost and these still need to be verified. The HashX docs make these claims regarding Performance [1] > HashX was designed for fast verification. Generating a hash function from seed takes about 50 μs and a 64-bit nonce can be hashed in under 100 ns (in compiled mode) or in about 1-2 μs (in interpreted mode). Obviously, with hash function generation being about 3 orders of magnitude slower than a SHA256 hash computation, fast verification was not the prime design objective. It was designed for ASIC resistance first, and fast verification second. The EquiX PoW verification makes 8 HashX computations, but they're all from a single generated function, so detecting the bogus PoW takes about 50 μs. Hopefully that's fast enough to deter such attacks. EDIT: apparently TOR already faces about 260 μs overhead in request processing before it can verify the PoW, so there's very little benefit in further reducing this 50 μs. [1] https://github.com/tevador/hashx |
|
|
|
It uses the Equi-X algorithm, which is itself developed from RandomX, which is the ASIC resistant PoW algorithm used by Monero.
To be more precise, we should distinguish between PoW algorithms and the hash functions they use. E.g. when people say Bitcoin's PoW is SHA256, what they mean is that it uses the Hashcash PoW with the SHA256 hash function (iterated twice). Equi-X is the Equihash PoW algorithm using HashX as underlying hash function. The latter is derived from the RandomX hash function used in Monero's Hashcash PoW algorithm. |
|
|
|
Nowadays we have so many different consensus types, like:
- PROOF OF WORK
- PROOF OF STAKE
- DELEGATED PROOF OF STAKE
- PROOF OF CAPACITY
- PROOF OF ELAPSED TIME
- PROOF OF IDENTITY
- PROOF OF AUTHORITY
- PROOF OF ACTIVITY
- BYZANTINE AGREEMENT
And we have these coin distribution methods: - PROOF OF WORK - PROOF OF CAPACITY with the latter hampered by proofs not committing to the transaction history (the miner signs separately for that, and a big enough collusion of recent miners can in fact freely rewrite history). |
|
|
|
or even QC itself to break PoW requirement easily.
While the Hashcash PoW used in bitcoin and most PoW coins is subject to quantum speedup through Grover's algorithm, some non-Hashcash PoW schemes like the memory bound Cuckoo Cycle [1] have no known quantum speedup. [1] https://github.com/tromp/cuckoo |
|
|
|
A simple question really. Regardless of how people feel about Ordinals or Inscriptions, is it possible to ban them or otherwise restrict them without a hard fork?
Yes, you can ban them. By simply banning ALL transactions. Or all transactions with multiple outputs. You cannot ban them without also banning regular standard transactions that they can be made to resemble, since they could embed their data in extra fake output addresses, either P2PK or P2PKH (sacrificing whatever amount is sent there). So in practice, no, you cannot ban them, unless you go to the extreme of banning public addresses [1]. [1] https://bitcointalk.org/index.php?topic=5437464.msg61980991#msg61980991 |
|
|
|
without doing the right analysis if it will lead to the congestion of the BTC network.
Remember that congestion is the end-goal for Bitcoin in a future with insignificant block subsidy, which is only a few decades away. An uncongested blockchain will never raise enough fees to provide decent security and be subject to cheap 51% attacks. So a fee market must develop where people fight for the right to have their transaction processed swiftly. So before long, congestion must be celebrated rather than criticized. It's crucial for Bitcoin's long term future. Or any PoW coin with a capped supply. Which is why I think Bitcoin Cash is doomed long term. It would take an insane amount of low fee (a fraction of a cent) transactions to pay for their security when their subsify effectively runs out. Their current tx volume of ~10k/day provides under $100 in fees. |
|
|
|
Ban ordinals and BRC20 and any other NFT/non-financial data on blockchain.
This is as silly a thing to say as people imploring the government to "ban bitcoin" because they don't like it. Bitcoin is is designed to be ban-proof. You can harass the onramps and off-ramps but you can't stop bitcoin itself in its tracks. Similarly, ordinals are pretty ban-proof. By the time you get a significant fraction of nodes to try filter them out from the mempool, they have already adopted a different encoding scheme bypassing the filter. The more you filter, the more ordinals encoding will become indistinguishable from financial transactions, and the more collateral damage you cause. In the worst case, they will just use fake output addresses for embedding data. That may be a little less efficient but at these fee levels they're willing to pay it obviously doesn't matter much. Not only is there no plausible approach to banning them from the mempool, but doing so wouldn't even suffice. Miners are very keen on processing these transactions which raise overall fee levels. So they'll make it easy to have these transactions routed directly to them. So please stop with the knee-jerk proposals without thinking things through... |
|
|
|
|
Show Posts
