Topic: Do you think "iamnotback" really has the" Bitcoin killer"? - page 21. (Read 79971 times)

I think that's the point where you need to stop, and why I think that all of this has not much sense.

I start from the idea that miners have incentives to be on a good backbone network, directly between them, and do not wait for the P2P network to bring a block to them.  In other words, the 10 or 20 big mining pools are on a rather fully meshed, high speed backbone.

I already explained why, because that diminishes their orphan rate, and they are mutually inspired to improve their network links.

If you accept that as a given, then it is impossible to start considering orphan rates that become important due to network and block size problems.  There is of course always a given orphan rate, but that orphan rate must be small.

If your (relative) orphan rate is, say, 1%, it means that your income is multiplied by 0.99.  If your block size doubles, and your relative orphan rate doubles because of that, you multiply it with 0.98.

By the time that "doubling your blocks" starts to be OFFSET by the diminishing of your income because of orphaning, you see that the orphaning rate must be HUGE.  Not 2 or 4%, but 50% or so.  

Well, that is impossible.  Because if you orphan 50% of your blocks on the chain, it means that you even orphan more than 50% of your successful blocks, which means that you don't even reach your other miners over the back bone with the blocks.

If that is true, nobody else can download the block chain.  It is being produced at a rate that is almost saturating a back bone.  So no one with a lesser link can ever download the block chain and keep up to date.  

So by the time that this problem of orphaning blocks because of their size starts influencing the income of miners, the block chain is growing so fast that NOBODY CAN DOWNLOAD IT.

This story is different if miners are random nodes in a P2P network. But they aren't.  They have all interest to invest in strong network links to other miners, exactly because of this orphaning problem.

So in other words, all this theoretical BS over how the orphaning rate offsets the desire for bigger blocks and imposes a natural equilibrium is meaningless, because if ever such an equilibrium would theoretically exist, it occurs for such big blocks that nobody can download the block chain apart from the miners themselves.

Yes, you can say that an "optimum" is reached when the network stops downloading the chain, and nothing works any more.  True, in a certain way

EDIT: I hadn't understood something in your post, but now I see what you are getting at. 

If we consider *really small* fees, then for an extra included transaction, that extra delay on the network will mean an extra probability of the block being orphaned, putting in jeopardy the whole income.  This even happens with small blocks.

Yes, this will simply result in cutting off the very lowest fees of the fee distribution, which will remain for ever in the mem pool.

I don't think that this has much to do with "optimal size" ; it only means that one doesn't include the cheapest transactions below a given fee threshold, because their extra transmission time penalises the whole income while not contributing enough to it.


That said, a market doesn't need to come to "equilibrium".  An erratically chaotic market dynamics can be fun too

@aklan & @dinofelis:

Well, I'm not sure if we are on the same page.

Of course, you can include more transactions and collect more fees by building bigger blocks, but that doesn't solve the fundemental problem that A's fee revenues must be multipled by his blockchain production (fraction of the chain built by A), rather than by his rate of successful blocks (ratio of non-orphaned blocks).

Let me come back to my example of the three miners A, B and C, all with a hashrate of 1/3 and an orphan rate of 0.01.

Now, assume that A and B stick to a block size of 1mb, while C tries to find the block size that maximizes his profits.
C can do so by gradually increasing the block size as long as the higher orphan rate (resulting in a lower production share) is outweighed by the higher fees. As the orphan rate follows an exponential distribution and the marginal fee income tends to decrease, there will be an equilibrium where marginal revenue = marginal costs. Let's assume that C's profits are maximized with an orphan rate 0.2, so that his current blockchain production rate will be 0.288, while that of B and C 0.356 each.

The fundamental problem arises once A and B also start using a variable block size to maximize their profits. By doing so (i.e. by increasing their own block sizes) they will not only decrease their own blockchain production shares due to their higher orphan rates, but at the same time C's blockchain production share will grow and thus destroy his individual market equlibrium. To reach equilibrium again, C will now have to increase his block size once again to collect the same fees as before. So, his optimal orphan rate will be more than 0.2. This, in turn, would place A and B in a disequilibrium, who might then increase their block sizes even more, etc. It will all end up in a doom loop.

It seems that the increasing total block space supply combined with the (probably) finite demand for transactions could make the loop converge at some upper limit. However, this equilibrium would be unstable. When a miner suddenly decreases his block size, all the others would follow suit to reach their individual market equilibrium again. The miners might even end up at an unstable lower equilibrium point

As far as I can see, no stable market equilibrium can be reached by all miners at the same time. For mining market has the peculiarity that whenever a miner increases its own supply, the supply of all the other will decrease. In contrast to regular markets where the players only compete to meet the demand, Bitcoin miners also compete to increase their own supply at the cost of their competitors since total block production remains capped even with unlimited block size.

Readers please click this quote to see if he replied over there. No need to put that discussion in this thread:

You have stated that, yes. That was my assertion. My point is that this is outcome is not affected by the cap on maxblocksize.


Justification of this assertion would require explaining away the almost linear annual doubling of the average block size, up until the saturation point.

There is no outcome that is outside a majority-collusion environment. I explained that unbounded block size cannot reach an equilibrium outside a majority-collusion environment. You said you must have missed it and I explained you did miss it.

You are conflating that the fact that the equilibrium is reached inside majority-collusion with your thought that I haven't stated what occurs outside of majority-collusion. But I have stated what happens, which it is always devolves to majority-collusion.


Conflation is conflation. (Meaning you apparently entirely missed the relevance of the point)

I'm trying to be respectful, but please don't waste my time. You see I have too many messages to reply to.


Everyone was incentivized by the fact that once the 1MB limit was reached, then the destruction of Bitcoin would ensue as is currently happening with the battle between the miner and codester cartels.

It was the 1MB protocol limit that provided the barrier that everyone had to try to swim far from. Also miners had an incentive to get minimum level of fees and they didn't yet have enough centralization to extract higher fees. And the decentralized miners at that time before ASICs also had an incentive to keep spam low since as I explained to @dinofelis today that it wasn't a fully connected mesh so propagation time was a bigger deal than he realized. Also the decentralization at that time when people were still mining on GPUs, meant there was more of an altruistically driven Nash equilibrium than now.

That not at all like the cut throat, big money economics situation now. As @dinofelis pointed out, the only altruism (and internal discord) from miners now is probably all faked to make us think there isn't a cartel.

Yes, a new bug was discovered by someone desirous of performing a DoS attack upon BU. This bug was exploited by such attackers to cause a number of nodes to crash. While a temporary inconvenience, we welcome this assistance in hardening the BU system before flag day.


Well, not exactly. I mean, if your definition of 'closed source' is delayed release of the source, I guess so. While I was not part of the decision process, it seemed to be predicated on the fact that immediate release would reveal the precise nature of the vulnerability to additional attackers. It was done to create a window for the patch to propagate.

Whether or not that was the proper course of action is something that can be debated. Indeed, it is still being debated within the BU community. But your characterization of 'they've gone closed source' is beyond the pale.

Yeah I think the music buisness need to do the switch with uber and p2p, with all the thousand of starving artists who will never get signed anywhere, and even the one who are signed not sure they are very happy with it, but they are locked and cant go to the toilet without asking their producer, the people to convince are more their producer for the one who are produced, and the economy is not really Blooming in this sector for a moment I can say with fair amount of confidence many are looking for new solution markets and income. And the music industry is not that good with internet since the beginning. And no producer for an artist it's the dream

Need to think also about good back office to have stats & méta infos, and good way to remunerate participants, node owner, artist, developpers.

For the language, I have mostly the low level part on the git, with the module system, the dynamic tree with reference pointer, http/rpc server, and most C runtime, and the vector lib for the raytracing. Then the modules method can be called from a js application with http/json/rpc.

For the high level part to make application, i dont have much theory I would go for something very basics who can call module function and handle Event with json like data type, and in the spirit akin to BASIC with simple one line statement easy to evaluate, charm is really the kind of things im looking to have good OOP encapsulation in module with an interface.

Js as far as i know is weak for defining good object sur typing and interface, but if I understand well, your idea is to have a source language with good sur typing and interface définition, and transpiling to js to have équivalent code.

But for me i would still rather stick to a kernel in pure C, that can expose module interface to js/html5 app, and having the node/server side in C rather than node.js. Much better for performance, memory use, and portability. The only thing it really miss now is a good html templating system to generate html5/js page based on input data. For this im not sure if the best is to have browser side generated html like angular js, or something that can generate preformated html from the node, or using xslt which can be done by both server & browser. Or something entierely different to define UI and Event handling and rpc call in html5/js.

That would do in sort to have part of application in C modules with the framework, and part of application on js/html5 who can call those modules. But having another source language to transpile this part of the app with the UI and modules interface, why not.

But all the part with binary data crypto & transcoding in js  

So you seem to be acknowledging that I am correct above...


There was minimum advised fee and there were pools doing anti-spam such as I think I've read that Luke Jr's pool rejected dust transactions.