Gold collapsing. Bitcoin UP.

[theZerg]

I agree with most of your post, though am still wondering about the O(m) for the UTXO.
I'd expect RAM cache doesn't need to be O(m), depending on the patterns in the UTXO set usage that can be predicted?

For example, I'd expect that a RAM cache that scales with O(n) and just keeps the last created UTXOs in memory would probably be a good first order approximation.



Resistance against bigger blocks or resistance against changing the social contract of bigger blocks?

Wouldn't it be O(n+m) anyway? You don't need to keep an entirely separate copy of the UTXO set for every transaction O(nm)

Been saying this for awhile, the larger market of users and companies that have invested significant effort in building tools that directly interact with the mainchain, will not accept being pushed off chain and forced to redevelop everything for off chain solutions.

As we get closer to full blocks the resistance will come from more influential sources than reddit boards that thermos controls. These core devs are about to learn just how powerful they really are.

We need to start a list of people (holders) and companies who want larger blocks. Once that list gets big enough we sit them all down together (or teleconference) with a majority of miners. This way they can all see who each other are. If the group is big enough, it will become obvious to all that we can push larger blocks through.

 

[cypherdoc]

From the article, it already appears BS has thrown mining under the bus. Note the heavy criticism of the length of time it takes to confirm TX's. Only one where a centralized solution can solve: namely their centralized federated server model. Darn right they won't be merge mining these things now as it appears to me they've given up on Bitcoin proper and decentralization.

The hypocrisy of calling themselves "the decentralists".

apparently they realize the Onename model won't work.

Fortunately, I think they are destined to lose lots of money. Just like I've always said that most people investing in crypto will lose money, so will they.

Maybe the market sees BS' announcement as them finally exposing their true intentions clearly enough so that there is now a new chance of their 1MB-dam finally being broken?

All it takes is for one of their billionaire investors, line Schmidt or Hoffman to throw a bunch of money at coin to generate some short term buzz.

 

[awemany]

Wouldn't it be O(n+m) anyway? You don't need to keep an entirely separate copy of the UTXO set for every transaction O(nm)

Yes, indeed. And as m is strictly less than n (only a transaction can create an UTXO), it follows that

O(m+n) <= O(n + n) <= O(2n) = O(n)

with <= denoting set inclusion.

 

[Inca]

From /r/bitcoin in the Coinbase thread..

The blocksize serves 3 purposes currently, namely

1) Decentralization
2) Paying for Hashing Security via fee pressure
3) Anti-spam measure.

All of these are compromised as you increase the blocksize and he has presented 0 solutions to counteract this.

What do you mean 'we', kemosabe? Brian Armstrong and some other companies might need bigger blocks soon, before they run out of runway, but the Bitcoin community has plenty of time.

it would be ok for me. we do not need all this kyc bullshit. mycelium has a build in local-trader, face2face works fine. and localbitcoins also.

So in one thread we have a new /r/bitcoin moderator saying he is has no problem with coinbase failing because KYC is bad. And this plonker saying limiting the blocksize is an anti-spam measure (in the same week hundreds of nodes drop off the network due to mempool bloating). The disconnect between these rabid 'small blockers' and the wants of the community, users and miners is now stark.

TheZerg: I agree. Perhaps it is time for Core to be forked by the major stake holders in the community (miners and businesses vested in future bitcoin growth) with agreement of the miners. In that respect XT has shown the world does not end with a competing reference client. We just need the miners to step up and protect their future income (lots of small transactions is better than few expensive ones and the halving may concentrate minds).

 

[cypherdoc]

At this point, I'm thinking we simply switch on a Bitcoin Unlimited blockchain without any mining approval and see who comes.

 

[bitsko]

It seems likely to be apparent to a wider group of people now, that it is the interests of 9 bitcoin companies and the majority of end-users vs the interests of one bitcoin company, blockstream.

Will this alone be enough to show large pool miners that bitcoin core's consensus system is irreparably broken due to conflict of interest; and for the good of bitcoin's economy, they must move on from core...?

 

[cypherdoc]

@bitsko

It seems likely to be apparent to a wider group of people now, that it is the interests of 9 bitcoin companies and the majority of end-users vs the interests of one bitcoin company, blockstream.

let me repeat what i said above; where is the innovation here that is supposed to be backported to Bitcoin proper?

answer: there is none.

this is solely a money making scheme and a co-opting of Bitcoin proper that will hurt mining revenues in the long run and thus hurt security for all of us. there will be no settlement layer.

all Bitcoin hodlers might as well be forced to move their cold storage coins to one of these centralized SC's

miners; wake up.

 

[rocks]

Private sidechains was the obvious business model, just wish It didn't come at the expense of Cockblocking the stream of work on blocksize and 0conf.

The thing that is absurd about all of this is, even if you assume LN takes off why does Blockstream think they will be the one's running the private chain.

Since everything is open source anyone can run the same LNs, the winners will be those that already have a business model as a payment processor and tons of users. Coinbase and Bitpay are the logical choice today, but I'm sure larger banks will step in as well. The blockstream team have no hope IMHO of competing with these firms, they're simply developing open source code for other firms to use (if LN is successful which I don't believe it will be)

 

[cypherdoc]

heads up. $DJT about to generate another short term sell signal after having formed a daily swing high yesterday. that's another non confirmation of the $DJI advance:

 

[Inca]

During a discussion with 10001010010 regarding blocksize caps and transaction spam I posted this..

|It is strange that you make an assertion that goes against logic and intuition without providing evidence or reasoning...
The lower the blocksize the easier it is to temporarily exceed the meagre TPS the network currently supports. This results in a growing backlog in the mempool during a spam attack which apparently crashed 1000 nodes. (Losing 1000 nodes as a result of hardware limitations is fine according to Todd, but losing a few nodes globally as a result of slightly increased node bandwidth requirements is evil centralisation!!)
If we assume 120,000 transactions a day currently that is approximately 1.4 tps. This leaves roughly 2 tps leeway. An attacker can fill remaining blocks to exceed the roughly 3.3 tps network capacity at 1mb by flooding the network with transactions each paying 0.0002 fee for a cost of .11 btc per block or 16.4btc a day.
If the block size were 8mb then the attacker would have to expend ((7 * 1024)+572 * 0.0002 = 1.54 btc a block, 222.9 btc a day) considerably more. Or at 20mb ((19 * 1024)+572*0.0002 = 4 btc a block, 576 btc a day) even more.
Keep up the BS.

|Yes it does - as my simple worked through calculation demonstrates.
No, your calculations do not. I can't tell if you're trolling or an idiot at this point, but with 1MB/block you are capped at 100KB/minute. It costs an incredible amount of money to spam the blockchain with 2MB/minute because you have to manage to produce 2 blocks per minute in order to do so, which requires 20x the network hashrate that was available at last difficulty. This eventually becomes exponentially more difficult because if you produce a block every 30 seconds, the difficulty will adjust and multiply by 20, meaning you will now have to use 400 times the hashrate to produce at that rate. With 20MB blocks you just need to prouce blocks to spam the blockchain at 2MB/minute, or not even that, just create a bunch of transactions with fees for miners.
In short, spamming 2MB/minute on a 1MB/block blockchain costs as much as multiplying the network hashrate by 20. (a few hundred million dollars)
Spamming 2MB/minute on a 20MB blockchain only costs ~$10,000/day if miners include the tx at a normal-high feerate.
|mempool will bloat up with a backlog of transactions.
Why do you keep talking about the mempool. My comment wasn't that mempool spamming attacks are made less of a concern due to the cap, it was that blockchain spamming attacks are made less of a concern due to the cap: there is a blocksize limit so spamming the blockchain isn't a very good attack vector.
Perhaps the issue stems from the fact that you don't know that the mempool isn't the blockchain?
Either way, you've miscalculated, misdirected and misunderstood so much that there is no point in discussing this further with you.

Is he correct with this analysis?

 

[Zangelbert Bingledack]

Consider this applied to the Core devs and /r/Bitcoin moderators.

 

[awemany]

@Inca:

He seems to be intentionally misleading which makes me more and more believe he's an intelligent, paid troll.

You are clearly talking about bandwidth needed, and you are absolutely correct: There is nothing preventing the network being spammed with lots of (non-confirming) transactions. During one of the last stress tests, I remember the network sustained some >400txn/s!

He's, however, relatively consistently talking about 'spamming the blockchain', which is a different beast.

Watch out!

Of course, the actual block chain cannot grow with more than 100kB/minute if you are limited to just 1MB blocks every ten minutes average.

However, that is not the figure of interest, unless you are interested about storage needed (which has been deemed to be not a major deal right now even by most BS guys).

Regarding bandwidth, your estimate is absolutely the correct one: The network's bandwidth, the figure that the stream blockers are saying is so limited, actually exceeds some 400txn/s between at least a major fraction of the network (as all major parts of the network stayed alive during that stress test).

Because transactions can be send across the network regardless of the block size limit.

Deep down, I always knew about this but the constant stream of psyops wore me down, too. It took me a while to realize this again when the stress test that showed this behavior happened!

So, honestly, I expect you to tell him he's wrong and then he'll just pull over to the position of him being concerned about storage all along or some similar bullstream/blockshit.

EDIT: And note also that transactions take the very same paths through the network that blocks do. So the network bandwidth figure of >400 txn/s should be a very good approximation of the available bandwidth with efficient block propagation, and probably way above the upper bound of what miners would consider to propagate due to economic (orphaning) limits with the current, inefficient propagation scheme, anyways.

 

[AdrianX]

@bitsko



let me repeat what i said above; where is the innovation here that is supposed to be backported to Bitcoin proper?

answer: there is none.

this is solely a money making scheme and a co-opting of Bitcoin proper that will hurt mining revenues in the long run and thus hurt security for all of us. there will be no settlement layer.

all Bitcoin hodlers might as well be forced to move their cold storage coins to one of these centralized SC's

miners; wake up.

Federated Sidechains have a place, an exchange is a great application. They come with risk too, even systematic failure risk.

I am not opposed to them in general. It's the conflict of interest that is putting Bitcoin at risk that's a problem.

It's the Core developers insisting centralized development is healthy.

It's the same group of Core developers modifying Bitcoin or projecting their solutions into the reference client that is endangering Bitcoin.

I'd like to see federated sidechains operating 100% independent of Bitcoin. Users must just be aware their actions can be audited, they are putting trust in a system that has a different security model. And that FSC incentives don't guarantee security like in Bitcoin.

 

[awemany]

@Inca: Oh, BTW, do you have a link to that conversation? (In case it is public)

 

[cypherdoc]

@Inca:

He seems to be intentionally misleading which makes me more and more believe he's an intelligent, paid troll.

You are clearly talking about bandwidth needed, and you are absolutely correct: There is nothing preventing the network being spammed with lots of (non-confirming) transactions. During one of the last stress tests, I remember the network sustained some >400txn/s!

He's, however, relatively consistently talking about 'spamming the blockchain', which is a different beast.

Watch out!

Of course, the actual block chain cannot grow with more than 100kB/minute if you are limited to just 1MB blocks every ten minutes average.

However, that is not the figure of interest, unless you are interested about storage needed (which has been deemed to be not a major deal right now even by most BS guys).

Regarding bandwidth, your estimate is absolutely the correct one: The network's bandwidth, the figure that the stream blockers are saying is so limited, actually exceeds some 400txn/s between at least a major fraction of the network (as all major parts of the network stayed alive during that stress test).

Because transactions can be send across the network regardless of the block size limit.

Deep down, I always knew about this but the constant stream of psyops wore me down, too. It took me a while to realize this again when the stress test that showed this behavior happened!

So, honestly, I expect you to tell him he's wrong and then he'll just pull over to the position of him being concerned about storage all along or some similar bullstream/blockshit.

during this last stress test, the worst one imo, i posted my vps full node bandwidth at a mere pitifully used rate of just 6%. that's nothing.

 

[AdrianX]

The thing that is absurd about all of this is, even if you assume LN takes off why does Blockstream think they will be the one's running the private chain.

Since everything is open source anyone can run the same LNs, the winners will be those that already have a business model as a payment processor and tons of users. Coinbase and Bitpay are the logical choice today, but I'm sure larger banks will step in as well. The blockstream team have no hope IMHO of competing with these firms, they're simply developing open source code for other firms to use (if LN is successful which I don't believe it will be)

You're overlooking the conflict of internet, the competitive advantage that having access to modify (influence) the source of the reference Bitcoin implementation gives you.

Otherwise you're spot on.

 

[cypherdoc]

Federated Sidechains have a place, an exchange is a great application. They come with risk too, even systematic failure risk.

I am not opposed to them in general. It's the conflict of interest that is putting Bitcoin at risk that's a problem.

It's the Core developers insisting centralized development is healthy.

It's the same group of Core developers modifying Bitcoin or projecting their solutions into the reference client that is endangering Bitcoin.

I'd like to see federated sidechains operating 100% independent of Bitcoin. Users must just be aware their actions can be audited, they are putting trust in a system that has a different security model. And that FSC incentives don't guarantee security like in Bitcoin.

you're right Adrian.

i need to not care so much (as long as the federated server model doesn't require some sort of change to the code which i'm not confident BS won't try to slip in to make the model work better). SCs and LN should fail on their own accord.

i guess i'm just worked up b/c all this does is postpone what's really needed; bigger blocks. Adam himself has stated publicly that he wouldn't have to be defending himself so much if only they had time to get LN & SC's up and running so as to deflect the block size debate.

so maybe it means we just stay here around 250 for another few years until we all figure out that the blockchain is where all tx's should take place according to Satoshi's Original Vision. to me, that's a waste of time.

and incredibly bad for mining.

 

[Inca]

@Inca: Oh, BTW, do you have a link to that conversation? (In case it is public)

 

[AdrianX]

...as long as the federated server model doesn't require some sort of change to the code which i'm not confident BS won't try to slip in to make the model work better...

That's a huge concern it's in my view worse than most think.

Blockchain Core developers feel that changing Bitcoin is fair game so long as you don't change the rules that make valid transactions and valid blocks.

Going so far as offering miners added revenue if they run their modified version of Bitcoin. They call it a harmless soft fork needed for sidechains with merged mining, but in reality it's a change to the software that runs Bitcoin and it's an attack on the incentive system that protects Bitcoin.

It offers miners an incentive to move transaction out of the blockchain and onto other chains.

Soft forks are fine when you look at how Mike runs Lighthouse on the Bitcoin protocol, but when you need it included in the speck (reference client to run) it's border line abuse. In reality Blockstream Core developers want to implement code without network conscious. At least that's what's advertised with it only requires a soft fork.

I'm OK with that so long as we are free to choose.

 

[Zangelbert Bingledack]

@AdrianX

If bribing miners turns out to be a viable strategy, that just underscores the reality that investors are the ones really in control. The popular illusion that some other party holds the steering wheel is resulting in a grand waste of time, money, and talent.

EDIT: By this I don't mean that bribery is form of investment, but that the illusion that miners (or devs) control Bitcoin is a costly one. Bribery of miners may gain miner approval for a proposal, but not necessarily investor approval. Such bribery could be harmful short term, though profitable for special interests (Blockstream?) over the same time span, but it would only incense investors to support a fork (i.e., during fork arbitrage on exchanges) that removes the cancer, killing the rent seekers in the process. The party you have to bribe is ultimately the long-term investors, and trying to bribe them is pointless as they - by definition - don't make a habit of eating their seed corn.

Woe to those who would seek to co-op Bitcoin for personal gain. (Not a threat, but a prediction echoing cypherdoc's "most people will lose money in this space.")