Gold collapsing. Bitcoin UP.

[solex]

Speaking about scaling,
Jeff has done us a favour and made a short bullet-point summary of the face-to-face dev discussions at the conference regarding the block limit. He notes;

- Background (pre-conference, was on public IRC): "net-utxo", calculating
transaction size within block by applying a delta to transaction size based
on the amount of data added, or removed, from the UTXO set. Fee is then
evaluated after the delta is applied. This aligns user incentives with
UTXO resource usage/cost. Original idea by gmaxwell (and others??).

- Many interested or at least willing to accept a "short term bump", a hard
fork to modify block size limit regime to be cost-based via "net-utxo"
rather than a simple static hard limit. 2-4-8 and 17%/year were debated
and seemed "in range" with what might work as a short term bump - net after
applying the new cost metric.

- Hard fork method: Leaning towards "if (timestamp > X)" flag day hard
fork Y months in the future. Set high bit in version, resulting in a
negative number, to more cleanly fork away. "miner advisement" - miners,
as they've done recently, signal non-binding (Bitcoin Core does not examine
the value) engineering readiness for a hard fork via coinbase moniker.
Some fork cancellation method is useful, if unsuccessful after Z time
elapses.

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011031.html

This is encouraging as it finally looks looks like momentum is building for some kind of solution for the 1MB to get implemented in Core.

Using an incentive for maintaining a cleaner UTXO set is a good idea, which has been discussed a lot already. The devs think a "flag day" is best where a future date is set for everyone to upgrade or get left behind. IMHO this creates a risky scenario where the mining is split 50/50. Miner voting is best for a trigger as Gavin and Mike are doing in XT. Core Dev just want to prove a point: "Booyah! The community is telling the miners what to do. Bitcoin really is in the power of the users after all!"
Well. We don't care about proving that point. We just want the technically safest implementation to be done for the hard fork. Anyway, if Core will only upgrade the block limit via a flag day then it is still better than nothing being done.

 

[Zangelbert Bingledack]

@solex

Net-UTXO always seemed like an obvious thing to do. What are the arguments against it? (Why wasn't it done a long time ago?)

 

[solex]

@Zangelbert Bingledack

Greg either thought of the idea or did most to figure out how it should work. He even proposed it as his own preferred solution when Gavin first did his blog posts and the whole !MB debate entered the dev mailing list (May, I think). Anyway, when Gavin tried to engage with Greg so that they could work on it together and get the code done it turned out that Greg was not interested, blanking him. Greg did not want to work on a solution to the 1MB even if it was his own solution.
Net UTXO is a complex solution which requires some hefty math which Gavin admitted he needed help with. So Gavin revised his 20MB down to 8MB plus 40% per annum, coded it up, which has now gone into XT.

I don't need to give you more than 1 guess why Greg wouldn't pursue this solution when it could have been done as a collaborative effort (and therefore likely enough to get Pieter, Wladimir and others to support the final result, which would have pre-empted the /r/bitcoin schism and thermos wouldn't have publicly spat out the pacifier).

 

[molecular]

I just realized that we might be thinking about the problem in the wrong terms.

It's not enough to pay miners to put transactions into blocks. We need to pay them to extend the blockchain.

Unless of course if in order to put transactions into blocks, it was necessary to extend the blockchain.

Otherwise, they could just have a single block that grows in size that just gets replaced by new versions at the same height but with more proof of work.

uhm, I hate to say it, but: this is only true in absence of a block size limit. ;-|

 

[awemany]

Hey @Peter R. so I finally found the time to watch your video. Great talk!
To give a little bit of hopefully constructive feedback: From what I gathered from the discussions at reddit, it seems like people will argue or think along the lines of: 'see, even Peter says that when a single miner exists we have a problem with the fee market'.

I think it is important there to point out that a single miner existing is covered by the 51% attack already, which absolutely must be accepted as a risk when going into Bitcoin. Even though it is clear to me, it does seem that people get stuck on that regularly. IMO, should you redo your talk elsewhere, you should add a sentence like 'and that's a 51% attack which is a fundamental unavoidable risk in Bitcoin anyways'.

(By the way it also seems that a lot of the small blockists seem to project their fear of the always existing 51% attack onto big blocks and, at the same time, want a government for Bitcoin to protect them and keep them safe from this...)

 

[Melbustus]

Unless of course if in order to put transactions into blocks, it was necessary to extend the blockchain.



uhm, I hate to say it, but: this is only true in absence of a block size limit. ;-|

Or incentive-solved via tail emission. :/

@Justus Ranvier - I believe you mentioned this (incentivizing chain-extension in the zero block-reward case) can be solved with new op-codes....can you elaborate?

 

[cypherdoc]

as i've been saying, i thing the USD and $DJI have been starting to move together since March. right now, i see the USD catching down to the $DJI, which is catching up. when they have achieved more alignment, my bet is that they start to move down together. if you'll recall, a similar situation occurred btwn the $DJT and $DJI with the $DJT leading:

 

[cypherdoc]

c'mon Peter_R! you can do it! :

 

[Justus Ranvier]

@Justus Ranvier - I believe you mentioned this (incentivizing chain-extension in the zero block-reward case) can be solved with new op-codes....can you elaborate?

I did earlier in the thread:

Assume an initial condition of a non-zero difficulty, one miner, no block reward, no block size limit, and enough revenue from transaction fees to make mining profitable.

In the course of an hour, the miner will receive enough revenue to pay for 6 blocks worth of proof of work.

However, with transaction fees (as they are currently implemented), there's absolutely no requirement that those six blocks actually extend the chain.

In order to collect that revenue he only needs to extend the chain by one block. He could choose to orphan the other five if he wanted to without immediately impacting his revenue, which means he could profitably engage in double spend attacks.

Of course, he can't do this for very long because his costs are measured in purchasing power terms and this kind of behaviour would reduce the purchasing power of his Bitcoin-denominated revenue (as users abandon his chain for a better-behaving currency), but let's just consider the short term impact.

If any fraction of his revenue can only be obtained by continually extending the block chain, then this represents the minimum profitable double spend. Any transactions below that value (times the number of confirmations) can be considered safe because it will not be profitable for the miner to double spend.

Right now, the block reward is the only form of revenue that can requires the chain to be continually extended to obtain, but there could easily exist other forms. New opcodes that allow users to create transaction fees that can only be claimed at a particular block height would achieve the same thing.

Somebody mentioned that CLTV as this or a similar property, so it may be the case that opcode will be sufficient.

There might be room for other developments in the future, but it's not something that we'll need right away.

 

[cbeast]

What if we create a LN-namecoin type server that utilizes full nodes in a dual role. In order to access the node, you will pay in ASIC-resistant Hashcash (non-transferable) for anti-spam measures, and then pay via a micro-transaction channel or LN fee to use the node service. Nodes can then create their own trusted networks based on proof-of-work. For the purpose of poetic justice, Ethereum (sans Eth) can be used to create the node communication system.

 

[AdrianX]

I'm having trouble parsing this question.

Sorry I have problems spelling I've corrected the question.

 

[AdrianX]

Hey @Peter R. so I finally found the time to watch your video. Great talk!
To give a little bit of hopefully constructive feedback: From what I gathered from the discussions at reddit, it seems like people will argue or think along the lines of: 'see, even Peter says that when a single miner exists we have a problem with the fee market'.

I think it is important there to point out that a single miner existing is covered by the 51% attack already, which absolutely must be accepted as a risk when going into Bitcoin. Even though it is clear to me, it does seem that people get stuck on that regularly. IMO, should you redo your talk elsewhere, you should add a sentence like 'and that's a 51% attack which is a fundamental unavoidable risk in Bitcoin anyways'.

(By the way it also seems that a lot of the small blockists seem to project their fear of the always existing 51% attack onto big blocks and, at the same time, want a government for Bitcoin to protect them and keep them safe from this...)

Justice has already addressed some the concern with the incentive to cooperate even if there was 1 pool.

But competition is the real reason it would never happen that's the reason I dislike BIP100 it's not free market competition.

 

[cypherdoc]

@AdrianX

yes, competition is the reason this edge case will never happen. the fixed supply creates almost infinite competition cuz fiat printing almost infinite. plus, wake me up when China and Russia agree to unify with the US.

 

[cypherdoc]

don't forget that the Dow Theory Bearish Primary Trend Change is still in place. it's valid until it's not and serves as a huge warning of what's to come.

 

[cypherdoc]

can you spot the clue?:

 

[cypherdoc]

It's Fed day

 

[cypherdoc]

you wanna see some real volatility? well, login into your favorite realtime Dow 1min charting program and you'll get your treat in less than 47 min.

this is supposed to be the first time in a decade that the Fed is going to raise rates. high anticipation.

 

[cypherdoc]

Philadelphia Fed Manufacturing Survey "Something Very Wrong"



http://globaleconomicanalysis.blogspot.com/2015/09/philadelphia-fed-manufacturing-survey.html?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+MishsGlobalEconomicTrendAnalysis+(Mish's+Global+Economic+Trend+Analysis)

 

[Peter R]

Hey @Peter R. so I finally found the time to watch your video. Great talk!
To give a little bit of hopefully constructive feedback: From what I gathered from the discussions at reddit, it seems like people will argue or think along the lines of: 'see, even Peter says that when a single miner exists we have a problem with the fee market'.

I think it is important there to point out that a single miner existing is covered by the 51% attack already, which absolutely must be accepted as a risk when going into Bitcoin. Even though it is clear to me, it does seem that people get stuck on that regularly. IMO, should you redo your talk elsewhere, you should add a sentence like 'and that's a 51% attack which is a fundamental unavoidable risk in Bitcoin anyways'.

(By the way it also seems that a lot of the small blockists seem to project their fear of the always existing 51% attack onto big blocks and, at the same time, want a government for Bitcoin to protect them and keep them safe from this...)

Thanks for the feedback, @awemany. I actually had prepared some discussion on this topic...how a lot of the things people worry about (such as all the hash power forming one super pool and killing the fee market) are sort of "51% attacks in disguise." I edited it out due to time constraints.

In hindsight, I should have at least added a sentence to the effect of "if all the hash power forms a single pool then they can do much worse things than spam the Blockchain."

 

[Peter R]

Or incentive-solved via tail emission. :/

Just for clarity, I don't believe anyone has shown conclusively what happens in the limit as R/T --> 0. It is possible that there actually is no problem even with Bitcoin exactly as it already is.