Topic: Not Bitcoin XT - page 5. (Read 21883 times)

You got 10 Cute Points there, but surely you know what I meant? 

Blockstream's invariant message for the last two months has been "it is not necessary to increase bitcoin's block size limit because the LN will accomodate any future traffic increase."  Except that the LN will be centralized and dependent on trusted third parties; users will have to submit to AML/KYC, their coins will be locked in the system for months, ad their payments can be easily traced and blocked. Oh, and, while bitcoin exists and sort of works, the LN is very unlikely to do either thing...

I know. Do you support the concept in principle? As I said, it addresses your scenario under which the 8 MB fork is 8 times more resilient to attack.

So you are in favor of raising the block size to 8MB, me too. It seems the most logical way to me.

If you want compressed blocks then for offchain transaction, maybe XAPO, Coinbase or Bitpay, will figure out a secure offchain BTC transfer.

The problem with XT is , that its a standalone chain, with mining and so forth, so it can fork bitcoin.

An offchain like  XAPO, Coinbase or Bitpay, is centralized, but requires no mining, so small transactions can be performed that way.


ex.  One friend sends 1 BTC to another friend, while both having Coinbase accounts, so it just transfers from 1 account to another. If the 2nd friend wants to withdraw the bitcoin, then he can, but for pointless back and forth TX, the offchain is enough.

There are many attacks possible. Some work better against the majority node and others work better if a node is in the minority.
The advantage of 8MB blocks vs. 1 MB blocks is spamming them cost 8 times more.
When the costs move from $1,000s to $10,000 or $100,000 per day, the number of possible attackers is reduced many orders of magnitude and the time they could support the attack diminished.

Just moving fees from 1/1000th of $ to 1/100th of $ or 1/10th of $ change the completely the economy and feasibility of the attack.

But someone telling just "there are a variety of attack that could" is just telling nothing.

And, anyway, antifragile is just "what do not kill me make me stronger". Let spell out these attack vectors so they can be neutralized.

I do not know of any dynamic block resizing client with consensus from the miners.
When there is some code compiled and running feel free to tell us.

Unfortunately, you're asking me to resolve an incongruity that I did not state.

I said:

8 MB vs dynamic block resizing

I did not say:

8 MB vs 1MB


If you would like to understand, please re-read the post I was replying to more carefully. I would only end up regurgitating it more or less verbatim anyway, so everything you need is there. Ask if you have specific questions regarding the details, once you have a handle on what I am actually arguing. Please don't ask me questions again before that point.

Ok but if they raise the size then it wont, i was talking about that possibility, how it would affect the price.


I dont understand why is the 8 MB block size such a big issue?

Why would big attacks happen at 8MB but not at 1MB , they are just 2 arbitrary numbers with no significance ?    I don't get it, please explain.

Transactions wouldn't be going through, and the queue would get longer and longer. People would start going elsewhere to make payments, because the Bitcoin network would be taking too long for their transactions to confirm.

yes, and since it is based on a free choice, it is hard to understand the reasons to destroy an available backup.

even harder to see so much morons, trying to censor informations just to prevent consensus, probably driven
by the conviction they have to think for others.

This is where a good dynamic scheme, implemented in Core to the XT fork schedule, could provide a solution.

Your scenario would play out oppositely, the 8 MB chain could end up overwhelmed with all sorts of attacks, while the dynamically sized chain would scale above 8 MB to handle it.

In fact not.

If the network split in half the hashpower over the two branches,  the confirmation times double for both.
The transactions would be the same (apart for the new coins mined) on both chains.
The problem would be for the 1MB, because if the mean blocksize was 500KB before the fork, it now would be > 1 MB after. For both.
Larger the mean block size before the fork, worse the effect on the 1MB branch.

Now, one chain would be able to confirm all transactions anyway. The other would not.
Immediately there would be a backlog of transactions in the 1MB branch but not in the 8 MB branch.
This would last about 4 weeks before resetting the difficulty.

I assume, due to uncertainty, exchanges and payment processors would not process any coin not present in both branches.
So you would have miners starving for 2 or more weeks at least or until one brach die out and all are mining on the surviving branch.

The asymmetry would force payment processors and exchanges to rely more and more to the 8 MB branch, because it confirm valid transactions faster.
Not only, they would need to pay less fees for transactions on the fastest and more on the slower (I assume they would be forced, for compatibility, to try to spend the same amount on both).

If a SPAM attack (or "stress test") happened at the time, the 1 MB chain will choke under an enormous backlog and increasing fee to have a transaction confirmed in a short time.
Effectively, an attacker could have a large transaction (to itself) confirmed in the 8MB branch but not in the 1MB branch (use a really small or no fee at all). Then send out a large quantity of transactions on the 1MB branch (they would be invalid in the 8MB branch and dropped immediately) clogging the 1MB nodes and forcing 1MB users to pay more to have their transactions confirmed faster.

This scenario explain the reasons waiting to implement the BIP 101 or any other increase of the blocksize or any WORKING method to increase the transactions volume will end making a stronger case for implementing the BIP 101 or some other increase.
As the mean block size increase approaching 800 KB,  payment processors and exchanges will increasingly pressure miners to support a block increase and will reduce their requirements to support the winning branch. They could start pricing the coins from blocks supporting BIP 101 (or whatever) differently than the default blocks.

The whining conspiracy fudsters and sidecoiners need new arguments, because there is choice now:

"This XT patch is literally and only BIP101 integrated in Core. It already exist and you are free to run it as we speak."
https://bitcointalksearch.org/topic/m.12216801

Thanks for this, you found a combination of words I've been looking for.


Some people believe the last stage of Access-Verify-Amplify is "better left to the so called power user."   

Yep, for a short time 20% (peaked at ~30%) of all XT nodes were really PseudoNodes.  These nodes were controlled by one person, who has since switched them off.  See the link for more details.

Why would the price drop if the blockssize increases (or even if it becomes full).

A high velocity of money (tons of transactions) is indicative of high demand for money, thus the price increase is correlated with the transaction volume.

Bitcoin`s price has no way but to rise longterm.

Wait, i can't follow you now, 20% of the XT nodes aren't real or are from the same pc? in this case XT is full of people on despair....

If we reach the point with Bitcoin Core where we have small blocks that are all full, the price of bitcoin is also going to drop. At least XT has an actual, working solution for moving forward.

This XT crap will go away and die.  It's already dead (or, thanks to NotXT, in a Schroedinger superposition of dead-alive) but hasn't stopped moving yet.  Enjoy the lulz this zombie fork provides while it lasts.  We'll look back and laugh at the XT Menace, someday.   

CRYddit knows that, he's just ATM too butthurt to concede such a fair (and obvious) point of fact.   

Currently at least ~20% of XT nodes are PseudoNodes.