Gold collapsing. Bitcoin UP.

[Peter R]

Refutation of Maxwell's Xthin "Attack":

https://bitco.in/forum/threads/xthin-is-robust-to-hash-collisions.1218/

 

[awemany]

@Peter R.: Great. As far as I see, that's about the same argument I gave gmax: Do not blow it out of proportion, miners are not interested in it.

That said, it should be possible to salt the hashes with a per connection salt, which would make that attack impossible to execute.
[doublepost=1465568965][/doublepost]

I got the idea from two places.

The first was from a conversation with @chriswilmer where he hypothesized that perhaps 1 - 2% inflation was a sort of "human constant"--that perhaps it's the most we'll put up without seriously considering abandoning the currency system. For example, currencies with inflations significantly higher than a few percent tend to collapse quickly (on the order of one generation), while currencies with consistent inflation of only a few percent can persist for hundreds of years (e.g., the British Pound or the US dollar).

Maybe it is acceptable simply because it is in the range of what Gold has as inflation, anyways?
Easier-to-use paper money that has the same inflation as Gold is probably acceptable if the alternative is just Gold.
With Bitcoin it isn't like that - and I expect, though cannot prove, that TX fees will pay for the network sufficiently, also in the far future.

@lunar, txns: Yes, that looks like saturation.

 

[Tomothy]

@AdrianX

those buying out Bitmain as a publicly traded company and even Blockstream, if it's indeed getting into mining, can't possibly be wanting to continue to cripple onchain scaling otherwise where do future revenues come from? doubling as centralized LN hubs? massive fee mkt fees? i don't think so, based on all the reasons we've stated here. i think growth of mining fee revenues are highly contingent on increasing the blocksize to facilitate global adoption. that's my opinion.
[doublepost=1465509947][/doublepost]

i'm getting some confusing info behind the scenes. i'm trying to clarify.

Ok, I saw this and my interest perked up immediately. So my understanding is that Avalon and Bitmain are TWO SEPARATE entities. Is this an incorrect assumption? I.e., Avalon was sold, but not bitmain.

I thought as such that maybe Jihan simply facilitated the private sale deal of Avalon? My understanding is that the purchaser is a relatively large company correct?

http://www.coindesk.com/sale-of-bitcoin-company-behind-avalon-mining-chip-awaits-government-approval/

(Saw this article which helps a bit. It still seems that avalon is distinct from bitmain). Maybe there is some sort of existing licensing relationship that bitmain sought to preserve

 

[satoshis_sockpuppet]

@Peter R Thank's for the really good explanations again.

What exactly are the "Compact blocks" by core? Is it related to XThin Blocks or something completely different? Is there some information anywhere for people who don't know too much about Bitcoin in detail (technically)?

 

[sickpig]

@satoshis_sockpuppet

core compact block when running in low bandwidth mode is more ore less like Xthin modulo bloomfilter.

a couple of useful links:

https://bitcoincore.org/en/2016/06/07/compact-blocks-faq/
https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki

 

[freetrader]

@lunar, txns: Yes, that looks like saturation.

Not-so-old analysis (Oct 2015) of average tx sizes showed them approaching 600 bytes:
https://tradeblock.com/blog/analysis-of-bitcoin-transaction-size-trends

The observed "ceiling" of 225,000 tx/day in @lunar's graph works out to an average of 1562.5 tx/block (at expected 144 blocks/day), which works out to an average of 640 bytes/tx if 1MB blocks were all completely full, which they're not always, but close enough (let's be generous and assume up to 10% of spare capacity). So from the average tx sizes matching up nicely, this does look very much like saturation.

 

[Zangelbert Bingledack]

@jonny1000

I believe what you are saying about miners is essentially correct. A majority of miners alone cannot change the rules for block validation. However, per @albin's point the miners follow the market's desire, or at least will if they can ascertain it.

Due to mining specialization, miners may not be be able to get a good read on the market, which validates your concerns about miners forking in error.

It does not validate your concerns about a populist attack, though, because you are thinking about it incorrectly. It is not the social contract or immutability of Bitcoin that protects from a populist attack; it is the ability to fork away (we - the minority - must fork away during a populist attack, because we'd have to change the PoW and tx format otherwise the populist miners could mess with our chain).

To be worried about a populist movement being able to "change Bitcoin" is illogical; you can always keep Bitcoin as it is or as you want it (except PoW and tx format). The question is whether it will retain market value and how much. The beautiful answer is that it will retain market value commensurate with how well it functions as sound money. (In the case of a persistent split, it will retain value commensurate with how much better it functions as sound money than the other fork. So if 2MB is better than 1MB, the 1MB side won't retain much value long term, if any, despite it being a sound-money ledger.)

Sure, a populist fork with big inflation or central banker control may temporarily be more valuable, but that won't stop the original-monetary-rules version of Bitcoin from retaining sizable value; in fact just about everyone who values it now will continue to, and the upside remains gold's gigantic market cap (at least).

For matters like blocksize, the same applies: if the change helps Bitcoin remain the sound-money ledger of civilization, it will be embraced by sound-money investors, and if not it won't. If you personally find a change likely to be value-reducing and the market does not, you are always free to continue with that version of Bitcoin, again even if it is temporarily priced lower than the more popular version. If you are right, long term you will be vindicated and make tremendous amounts of extra money (on top of Bitcoin's appreciation).

TL;DR: Thanks to open source, Bitcoin can always be kept as one wants, and any change can be completely avoided (except the necessary PoW/tx-format changes); it's only a matter of what the price of your favored version will be on the timescale you care about.

Since you want much bigger blocks, too, and you support Bitcoin remaining sound money as well, you have nothing to worry about from a populist attack. Extreme consensus is not needed to prevent change, since you can always prevent it if you want. What you cannot control is market price.

What we therefore need is not elevated consensus standards for changes, but the capability for miners to read the market so that they don't make a change that will damage the market price by going against stakeholder wishes and requiring sudden action to fix.

 

[Peter R]

@Peter R Thank's for the really good explanations again.

What exactly are the "Compact blocks" by core? Is it related to XThin Blocks or something completely different? Is there some information anywhere for people who don't know too much about Bitcoin in detail (technically)?

I'll add a bit more detail to the information that @sickpig provided:

"Compact Blocks" as defined by BIP152 is actually two products: a product similar to BU's Xthin that uses Bitcoin's standard inv/getdata method and a product similar to BU's eXpedited that sends thin blocks without first asking if the node wants it. It appears that @Peter Tschipper's excellent work on Xthin is what motivated Core to move forward on this.

1. Compact Blocks (low bandwidth) is Core's answer to Xthin

In my opinion, Xthin is superior because it does not rely on mempool synching to attain 1.5 round-trip block transmissions. Xthin requires fewer round trips on average, which will be increasingly the case at larger block sizes.

2. Compact Blocks (high bandwidth) is Core's answer to eXpedited

It is too soon to tell but it appears that these will be quite similar.

What is interesting, is that Xthin and Compact Blocks (low-BW) are similar enough that they could be considered subsets of a single protocol. Setting salting=false, bloomfilter=true gives you Xthin; setting salting=true, bloomfilter=false gives you Compact Blocks.

I am trying to advocate that we work together to create a single protocol that supports both. If it turns out that the Bloom filter is more useful than Core thinks, then it will get used. If it turns out that salting is more useful than Unlimited thinks, then it will get used.

Let's just give the market options and let nodes pick what is right for them. Ideally, I'd like to see us move away from this protocol monoculture and towards a future where (for example) multiple different block relay methods are used, thereby making the network more robust to disruption of any particular method.

 

[cypherdoc]

Yeah, i don't think the info I've gotten behind the scenes is accurate, unless I misunderstood.

Ok, I saw this and my interest perked up immediately. So my understanding is that Avalon and Bitmain are TWO SEPARATE entities. Is this an incorrect assumption? I.e., Avalon was sold, but not bitmain.

I thought as such that maybe Jihan simply facilitated the private sale deal of Avalon? My understanding is that the purchaser is a relatively large company correct?

http://www.coindesk.com/sale-of-bitcoin-company-behind-avalon-mining-chip-awaits-government-approval/

(Saw this article which helps a bit. It still seems that avalon is distinct from bitmain). Maybe there is some sort of existing licensing relationship that bitmain sought to preserve

 

[jonny1000]

The main thing that jumps out at me with this guy's tired line here is that it has this air of autism about it, where the only thing that exists is how things inside the system work mechanically, and that nobody outside the system reacting to what's going on makes a difference.

Thanks for your comment, I find it ironic becuase I had always thought assuming that the 51% Nakamoto consensus idea could solve the governance problem could be charectirsed as a bit "autistic". Realising that Nakamoto consensus only really works for solving the double spend problem and assosiated contentions, rather than solving general issues in governance or politics is an important part of maturity, in your Bitcoin understanding.

Of course you are right, my comment did focus on the "mechanics" and of course determining consensus on the rules is also a human/market phenomenon. Therefore we need to look at the situtation from a number of angles. I was merely pointing out that conducting a hardfork is "mechincally" different from situtauions where Nakamoto consensus works. There are other ways of looking at it, however my point is sufficient to prove your claim that Nakamoto consensus can determine a hardfrok in the same way as it can resolve a double spend, is false.
[doublepost=1465633264][/doublepost]

A majority of miners alone cannot change the rules for block validation

Mechanically, a majority of miners alone can add a new rule for block validation (softfork), but they cannot eliminate an exisitng rule (hardfork). I think it is important to seperate if you think this is desirable and whether you think this is true, these are two different things. When you think through how miners could try to hardfork, your realise it is a very difficult process for mechincal reasons, therefore the "human"/political/market support needs to be very strong, to overcome the mechanical barriers. Any significant political/market weaknesses will ensure the status quo will preval. With the Core nodecount now at c85% and Core miner support at 95%, I hope you will begin to take my comments more seriously and slowly start to adjust your view.

For me the thought process is as follows. I reconginsed the above was true and then decided these features made Bitcoin desirable. I appreciate that many of you here do not have this view, you have not realised how mechically different and difficult it is to do a hardfork. You also think this is a negative characteristic. All I ask is you please stop confusing whether this is true and whether this is desirable.

Lets recongise this is true, end plans to hardfork without strong consensus and then hardfork to 2MB with strong consensus.

 

[sickpig]

this reddit user is giving hard time to Gregory "twisting words" Maxwell

 

[freetrader]

@jonny1000 :

end plans to hardfork without strong consensus

I realize you're being very civil here in your attempts to persuade us, but if you come here to propose a hardfork to 2MB with any sort of consensus, you have to show that Core is actually capable of that.

Right now, hard forking seems to be quite controversial in the Core camp, and we know what Adam Back says about controversial hard forks - they CANNOT happen.

I heartily recommend a re-read of /u/ytdm's post from a while back on the subject:

https://np.reddit.com/r/btc/comments/46052e/adam_back_greg_maxwell_are_experts_in_mathematics/

 

[tynwald]

Thanks for your comment, I find it ironic becuase I had always thought assuming that the 51% Nakamoto consensus idea could solve the governance problem could be charectirsed as a bit "autistic". Realising that Nakamoto consensus only really works for solving the double spend problem and assosiated contentions, rather than solving general issues in governance or politics is an important part of maturity, in your Bitcoin understanding.
...
Lets recongise this is true, end plans to hardfork without strong consensus and then hardfork to 2MB with strong consensus.

Perhaps the education process is for you to undergo i.e. there is no such thing as "Strong Consensus" in Bitcoin code or Bitcoin white paper or any relevant technical standard or any open source working methodology. It's a political construct used only to advance your agenda and the interests of Core developers and Blockstream investors.

Recognize the bias (or ignorance?) in your own thinking first, then discussion here might create more value for you.

 

[jonny1000]

you have to show that Core is actually capable of that.

Well Core is capable of it, but there is no guarrentee. All I can promise you is I will change my position from opposing the HF to supporting it. If you demand a guarentee it will not happen, you have to let go, end the pressure and allow consenus to form in a calm process. Do you guys not get it by now, we could have had 2MB over a year ago if it was put forward in a way without pressure. We will not allow a HF to come about by force, pressure or threats.

It's a political construct used only to advance your agenda and the interests of Core developers and Blockstream investors.

But I had this view before Core on Blockstream existed. Please stop assuming bad faith, which is counterproductive.

there is no such thing as "Strong Consensus"

What about the current CSV softfork? In the last 24 hours 98% of blocks flaged support for it. 98% miner support is a good proxy for strong consensus, which clearly is exisiting right now.

Example of strong consensus

The 98% number, circled in blue, is an example of strong consensus. In contrast the 2% number, circled in red, is not an example of strong consensus, but instead represents an insignificant minority.

Source: https://www.blocktrail.com/BTC

 

[sickpig]

All, @cypherdoc

do you remember how one of the main selling post it about SegWit was to make SVP client fraud proof aware?

guess what, according to Peter Todd it's not true:

 

[freetrader]

Well Core is capable of it, but there is no guarrentee. All I can promise you is I will change my position from opposing the HF to supporting it. If you demand a guarentee it will not happen, you have to let go, end the pressure and allow consenus to form in a calm process.

You must think I'm asking the impossible. I'm not actually asking for any guarantee, just an elimination of the vague concept you call 'strong consensus' and its replacement with an objective process that anyone can understand and that can reflect the wider community. Your view and mine would only be a drop in that ocean.

But right now what I see in Core is a technocracy that seems to be making up rules as it goes along, with a strong element of corporate influence through Blockstream and its investors. To believe that all corporate interests would necessarily act in the best interests of Bitcoin is a large leap of faith.

In the end, it's a free world and I'm not here to make demands of Core/BS. This would be (mis)placing trust in authority, and anti-thetical to the credo of Bitcoin as I see it.

Reading Satoshi's whitepaper I fundamentally grasped hard-forking as a vital defensive mechanism, to allow Bitcoin to shake off miners and developers who do not live up to the market's expectations.

Core has never actually shown itself capable of a hard fork, in fact it has doubled down against them, vilifying them and any who proposed them. My minimum standard to prove themselves capable of it would be for them to release publicly and on time the HF code, honoring the terms of their deal in HK.
This would be a public release of their software, tested and ready to be deployed by the miners and anyone supporting an increase in the blocksize cap, and not including other agenda items that were not publicly agreed. Will this ever happen?

We will not allow a HF to come about by force, pressure or threats.

Excellent, now get this: Bitcoin is a permissionless system.

I will not force, pressure or threaten anyone into running my hard fork code. Participation will be entirely voluntary.
I will also not attack any part of the legacy Bitcoin network, nor condone any form of attack on it.
Hard forking an open source project is not in itself an attack by any stretch of the imagination.
Those who attack computer networks are already within the ambit of the law, will be exposed and where possible, made to face criminal charges.

This might enhance your calm:

https://fieryspinningsword.com/2015/08/25/how-i-learned-to-stop-worrying-and-love-the-fork/

Take Meni's advice, he's undoubtedly a smart guy:

[...] having two networks coexist side-by-side is a real possibility, that it is not the end of the world, and that we should spend more energy on preparing for this contingency.

As others here have pointed out, whichever ideological side you choose to position yourself on, there's money to be made from this, if you believe in the free market as I do, and an existential lesson (proof of anti-fragility) about Bitcoin to be learned.

 

[Dusty]

The 98% number, circled in blue, is an example of strong consensus. In contrast the 2% number, circled in red, is not an example of strong consensus, but instead represents an insignificant minority.

We know that the few miners run Kore code and so this is expected.
This is not a "strong consensus". This is "strong consensus of miners", and this does not tell anything about the whole Bitcoin community (that includes nodes, merchants and users).

The thing is that if Kore would raise the block size to 2mb in a new "official" bitcoin clien we would have a strong consensus even for that, and the whole community would be reunite again, because, as the miners have already stated, they are willing to hard fork to raise the block size.

 

[yrral86]

Nakamoto himself suggested raising blocksize with a simple height trigger. This would result in either 51+% support and a lasting fork, or a failure to fork. Sounds like Nakamoto himself believed 51% was sufficient for a hard fork.

The "stronger" your consensus requirement, the easier it is to break. 90% consensus -> 10% can prevent it. 95% -> 5% can prevent it. When it comes to economic systems, the fear isn't tyranny of the majority, it is tyranny of the minority. "Strong consensus" grants control to a small minority. Decentralized control necessitates simple majority consensus.

 

[BldSwtTrs]

Historically, when three consecutive weekly candles closed over upper BB, we went to the moon.

 

[cypherdoc]

Well Core is capable of it, but there is no guarrentee. All I can promise you is I will change my position from opposing the HF to supporting it. If you demand a guarentee it will not happen, you have to let go, end the pressure and allow consenus to form in a calm process. Do you guys not get it by now, we could have had 2MB over a year ago if it was put forward in a way without pressure. We will not allow a HF to come about by force, pressure or threats.



But I had this view before Core on Blockstream existed. Please stop assuming bad faith, which is counterproductive.


What about the current CSV softfork? In the last 24 hours 98% of blocks flaged support for it. 98% miner support is a good proxy for strong consensus, which clearly is exisiting right now.

Example of strong consensus

The 98% number, circled in blue, is an example of strong consensus. In contrast the 2% number, circled in red, is not an example of strong consensus, but instead represents an insignificant minority.

Source: https://www.blocktrail.com/BTC

You have a lot to learn about Bitcoin. SF, HF are all kore concepts kore gang created to retain control. You have consistently ignored my arguments about host you and your dipshits have interfered in the signaling process to attack all those who have expressed disagreement with your uneducated diktats. You are full of contradictions and refuse to do what's best for Bitcoin.
[doublepost=1465647452][/doublepost]Quite interesting

All, @cypherdoc

do you remember how one of the main selling post it about SegWit was to make SVP client fraud proof aware?

guess what, according to Peter Todd it's not true:

Thats