Topic: Gold collapsing. Bitcoin UP. - page 39. (Read 2032247 times)

You know that you can do this now, right?  And always could.

The code is open source, you can (of course) just change it and compile.

Yes, that was confusing in hindsight.  We're just proposing a new way to think about it. 

it was the term "layer" that made me question.  when i hear "transport layer" i start thinking technical like TCP/IP, SSL/TLS, http, https, etc.  

so nothing technical, just layered "concepts".

Sure.  

Why do we have a consensus layer in the first place?  It is a way for us to agree on what transactions are valid and what transactions are invalid.  For example, we all agree that Alice shouldn't be able to move Bob's coins without a valid signature, and that Bob shouldn't be able to create coins out of thin air.  The consensus layer is about obvious stuff like that.  In order for Bitcoin to function as sound money, we need to agree on "black-or-white" rules like this that define which transactions are valid and which are invalid.

Notice that the paragraph above discusses valid and invalid transactions.  No where did I say anything about blocks.  That's because we only really care about transactions in the first place!  In fact, how can a block be invalid just because it includes one too many valid transactions?  

Satoshi added the 1 MB limit as an anti-spam measure to deal with certain limitations of Bitcoin's transport layer--not as a new rule for what constitutes a valid transaction.  We should thus think of every block that is exclusively composed of valid transactions as itself valid.  The size of the block alone should not make it invalid.  Instead, if a block is too big, think of it as likely to be orphaned (a "gray" rule) rather than as invalid (a black-or-white rule).  Perhaps above a certain block size, we're even 100% sure that a block will be orphaned; still we should view it as a valid block!  It will be orphaned because the transport layer was insufficient to transport it across the network--not because there was anything invalid about it.

Voting with the node number is not a democracy game or even a stake game. Take the example of a change that I never would support, adjusting the total coins. Even if I was outnumbered 100 to 1, I would not accept that change in my node, and the chain would fork. So churning up lots of nodes does not give someone unrestrained power. I don't know how to name such a method of decision making, but it is perfect for the problem at hand. "Fork restrained majority decision" may be.

First I am not afraid of cartels in the free market (laws against market actor collusion is rather a statist notion of fear of markets, in reality it is the regulator who is the monopolist intruding with undue force and destroying the market), and second, I don't think a miner will act to waste bandwith, if that were the case, we would already have seen it, since unrestrained block size has been the situation for the first 6 years.

i never did quite get this part.  can you explain?

I'm not sure a sybil attack is the way to look at it, with this new proposal.  What is there to sybil attack?  Every node operator independently selects the max block size that he is willing to validate.  The effective block size limit is equal to the largest block that has successfully been included in the longest proof-of-work chain.  Any miner can attempt to increase the limit, simply by publishing a slightly larger block than has ever been published before.  They can assess the probability that their block will be mined upon (rather than orphaned) by any number of methods.  If they try to publish too large a block, then it will likely be orphaned.

As sickpig suggested, it would be a recognition that the block size limit is not part of the consensus layer, but rather part of the transport layer.

it identifies as a Satoshi client but it is an XT version of it.  Bitnodes allows you to look at the details of your node to see if it's XT.

Alan is quite right about that.  forget POS voting.

i also disagree with you about the Sybil attacks by spinning up full nodes.  first off, it's not a trivial expense even today to run a full node, so there is a cost to trying to manipulate the system.  and you'd have to run them for "longish" periods of time before you'd get miners to react with bigger blocks.  and, as larger blocks come into being, those full node costs will rise making the attack even more expensive.  and really, for what point?  it's always been possible to spin up nodes but no one's bothered to do it.  as more users enter the system, honest merchants will start spinning up their full nodes in numbers that should make Sybil attacks very difficult.  finally, while running this attack, they are actually helping the network validate and relay tx's and decentralize it.  i'd think there are better ways to attack the network.

Your Auroracoin false equivalence does not stand. An irrational pump & dump does not compare in any way to a collector's item.

I think Bitcoins are absolutely a unique collectible. I hate to "call up" authority but its own creator was well aware of that:




This typical "cryptocurrency is infinite" reply seems shortsighted and IMO shows a misunderstanding of Bitcoin's origin of value.

If we were to derive the latter from "ecosystem usage" as you represent it : transactions on the blockchain, then we should argue Bitcoin is a pretty low value network since the velocity of transactions on the network is, frankly, very low. Have a quick look at the top 500 (you can even go up to 20,000) on the website here http://bitcoinrichlist.com/top500?page=40. A very short glance should make it very clear that most bitcoins rarely move on the blockchain.

In other words, very little people actually use Bitcoin for exchanges of goods and services traded on the blockchain. Therefore, I believe, the "utility" value in your feedback loop is incorrect. The actual primary use case of Bitcoin is for people to store wealth by exchanging fiat currency for bitcoins or, in the case of miners, work/energy. This is exactly how a collectible comes into existence. An organic process where an "unforgeably costly commodity repeatedly adds value by enabling beneficial wealth transfers." (1) Beneficial wealth transfer, in our case, is not transfer of goods or services, but an exit from the fiat system and/or also a speculative move.

By creating value that way, its market prices increases which encourages miners to put more energy into creating them therefore increasing their rarity by making them harder to forge. This increasing price and growing rarity attracts more collectors and on it goes. This is what the feedback loop looks like to me. The current rarity of Bitcoin may very well be a product of its first-mover advantage but it is pointless to dismiss it in the present. That is why Bitcoin should not be thrown into the same bucket as other crypto.

Don't get me wrong, Bitcoin will eventually evolve into a much larger network where an increasing amount of goods and services will be traded for them but I expect this "utility" to remain marginal until Bitcoin grows its collector base by a couple order of magnitudes and ultimately peak when Bitcoin is used as a unit of account.

For all these reason I believe my conclusion still stand and no, 1MB will not cripple this feedback loop.

(1) http://szabo.best.vwh.net/shell.html#Attributes of Collectibles

the optimal solution is looking more and more like 101 to me. I think the sybil attack is a good reason keep nodes from forking to the wrong block size.   

thanks,

I'm ruining XT too but an older stable version that still identifies as Satoshi client.

I'm waiting for 11.0 or the bigger block stable version.

that's not the pt. 

the full nodes should and will care only about what tx volume they have the capability or desire to validate.  for me, despite not getting paid, i will want to max out those validation capabilities to whatever i'm willing to pay (donate) to the network, which is much higher than it is being used today.  i want Bitcoin to grow in size and price so i'm going to donate to my hearts content trying to make that happen.   the Cripplecoiners will say that is no way to run a full node but i'll bet there are thousands of guys like me who are willing to do this for the prospect of taking the price to the next 10x level.  there is nothing wrong with wanting a higher price b/c a much higher price is essential to Bitcoin's overall success and ability to move large scale tx's as we've argued about before.  it has to be able to allow large tx's in the $millions to fund purchases of real estate, yachts, planes or bigger items so as not to perturb the overall exchange price, unlike what we have today. 

as more users come onboard, merchants will have the incentive, not to mention fiduciary responsibility to run full nodes.  that's a good thing.

but if someone designs a full node fee mkt, i won't be complaining either.

hey solex you seem to have a good take on BIP100, i started formulating my thoughts when NEY Liberty was pushing it over BIP 101
i would like your opinion on the idea that miners can maintain a cartel by voting?

From what I understand PIP100 gives the power to miners to set the block size (all be it with a vote?)

That's all good and well knowing miners should set there own block size, so on the service BIP100 seems fine.

Miners also dont pay the cost for large blocks, the nodes do, and as Peter_R has illustrated mathematically, Satoshi's original design optimizes block size based on market demand, while leaving nodes with ultimate control, (and removing the need for nodes or developers to manage block size)  

So the issue I see with BIP100 is if the majority of Miners collude to form a cartel to set the limit they can set it too low to suite the cartel's preferences, the difference between BIP 100 and BIP 101 to me, is that BIP100 miners cant leave the carrell and mine bigger blocks if there is a market for it, in the case with BIP100 the cartel needs to vote.

Whereas with BIP101 Miners can form a cartel but if it becomes more profitable to mine larger blocks they can break from the cartel without having to get a majority vote.

the innate incentive that limits the ability for cartels to form is important, BIP 100 is a change to an innate incentive in Bitcoin.  

Playing devils advocate here and creating a worse case scenario, imagine the optimal market equilibrium for block size and transaction cost resulted in the demand for a 16MB block, a majority of miners could form a voting cartel, and set a limit at 8MB, there would be no reason to do this in a free market because they would loose revenue, but in a controlled market for transaction fees where Sidechains exist, it becomes possible to manipulate the block size to undermine competition, a simple way to do it would be to limit your completion's revenue by limiting block size, if you were uncompetitive in block propagation that would give you an unfair advantage. In the case with SideChains the cartel could supplement revenue by being paid to Merge Mining side-chains that other miners dont have assess too.

giving the power to set block size to the miners by vote of the majority seems to me will ultimately tend towards centralization, where in BIP101 this power is vested in the market and incentives that govern it. More important, it's not a change to Satosis design which seems to have the incentive balance just right.  

0.11A is the testing version of the actual bigger block software, i think.

i'm running 0.10.2 which is the stable version but doesn't have the bigger blocks enabled.

both versions mine Core as usual, as you'd expect.

I think you guys are on to something here.  Could you have an option in the dropdown to choose a dynamic limit that is 1 standard deviation above a 30 day moving average (or use data points of the previous 4320 blocks, which is about 1 month, to calculate variance), or something similar?  That way the user could set his limit to stay within a reasonable upper range without restricting usage.

another reason Cripplecoiner's want to see 0 hard forks is they have invested or are investing in systems that could be obsoleted very easily with small tweaks to the code. I suspect if someone like Gavin who isent invested in there company can come in and make a change without there permission its very threatening to there future which may even depend on bugs in the code that cant be fixed for legacy reasons.

I like the principle of the idea, however the idea of voting by non-miners is subject to Sybil attack - someone spinning up many fake nodes to skew the results. There have been posts on the mailing list about various voting schemes.

Going one better than simple user voting is proof-of-stake voting:

Proof-of-stake voting could be combined with miner voting (like BIP-100) to get a balance between mining power and investors/holders.
https://www.mail-archive.com/[email protected]/msg02323.html
A drop down box, which would need supporting on the many wallet providers, then allows people to vote depending upon their coin balance. A non-vote is a "vote" for no change.

Except, the problem with proof-of-stake voting is summarized by Alan Reiner (Armory developer) in the responses to this proposal:

Nodes have the power to do that, even a right given they host the data, however they dont have the the market knowledge to know what it should be, the power to set the block size must come from the incentive schema designed as designed by Satosi to work.  I cant imagine it would work out well at all, probably better than limiting the block size but not my much.