Gold collapsing. Bitcoin UP.

[freetrader]

@Christoph Bergmann :

The small blockist think, a "consensus protocoll" means that there should be a social agreement that nobody changes consens rules.

I don't buy that. There's very smart folks in their camp too. It's just that pretending that some artificial form of consensus is needed is very convenient if it means you keep on raking in those first-mover $$$$$$ and "influence points" while others who are less knowledgeable or too polite are stuck in endless debates about said consensus. They justify this by the unspoken (or not so often spoken) "there's a sucker born every minute".

Cui bono?

 

[cypherdoc]

Under guidance issued by the Australian Taxation Office, bitcoin is not treated as a form of currency. Instead, transactions involving bitcoin are treated as a form of barter.

http://www.computerworld.com.au/article/596377/government-tackle-double-taxation-bitcoin/

 

[Dusty]

With onCPU GPU coming, this bodes well!
Also the iguana parallel sync data is well suited for GPU searching.

Yes, if you have to validate signatures of an entire block you should be able to parallelize most of them and get a great boost using opencl.

But that would be useful mostly once, for the initial sync, but when the client is updated and is receiving x-treme thinblocks most of the signatures are already verified so che gain should be negligible.

 

[jl777]

at 1000 tx per second, we will need to have fully optimized paths everywhere

 

[albin]

look at Liquid. SC's were supposed to be spvp 2wp's for experimentation and backporting of optimizations for Bitcoin. lol. far from it. Blockstream went for the money and now we have a centralized regulated fee paying good 'ol boys club of exchanges. same will probably happen with LN hubs too.

Blockstream: Greasing the slippery-slope since 2014!
[doublepost=1458586038][/doublepost]

That's maybe the "core" of the problem. The small blockist think, a "consensus protocoll" means that there should be a social agreement that nobody changes consens rules. While I / we / big blockers think, that a consens protocoll just means that all peers have to share the same rules.

The overall impression that I tend to get from people with those positions is that they probably have no concept of how consensus emerges organically because of the utility of network effects. Not even just in Satoshi-style cryptocurrency specifically, also in all realms of human activity and even arguably there are probably examples in the natural world of strong analogues.

 

[Roger_Murdock]

theymos: "no problem, we can make the SF % anything we want" (paraphrase):

Sounds to me like he's promoting an attempt to alter the Bitcoin protocol without overwhelming consensus. Reported. I mean, he probably won't ban himself, but it's worth a shot.

 

[AdrianX]

at 1000 tx per second, we will need to have fully optimized paths everywhere

the simplest solution is to plan long term for 1000 tx per second, but right now if we had capacity to just increase to 10 tps that should be a great signal to investors that the network was capable of on chain growth.

Over the next year if we just worked towards allowing blocks grow to a limit of 20 tps we'd be making progress. There is no guarantee bitcoin would grow to fulfill that capacity. The objections to on chain scaling are largely based on inaction until we find a solution to the 1000 tps problem.

Keeping block growth limited to an approximate 3 TPS while a single for profit companies build a solutions for 1000tps is damaging bitcoin and its reputation.

 

[jl777]

I have ideas that can be demonstrated in an altcoin. the issues with high tps are more about where to put all the data than anything else
[doublepost=1458588452][/doublepost]

Sounds to me like he's promoting an attempt to alter the Bitcoin protocol without overwhelming consensus. Reported. I mean, he probably won't ban himself, but it's worth a shot.

softforks appear to be able to make any sort of change, including changing 21 million BTC limit

and softfork doesnt require any overwhelming consensus and as such are much more dangerous than hardforks. At least with a hardfork attack, everyone knows they are being attacked. A softfork attack is like a submarine. By the time you realize it is there, it is too late

 

[cypherdoc]

looks good:

https://github.com/bitpay/bips/blob/master/bip-adaptiveblocksize.mediawiki

 

[jl777]

but wouldnt that bip mean we cant spend years debating changing a #define, every few years?

we might have to spend time debating actually difficult issues to solve...

 

[Tomothy]

Theymos does'nt like it, but I didn't really understand his comments against. Jl777, can you comment to the accuracy of this?

theymos [score hidden] an hour ago*

The major problem with these sorts of adaptive proposals is that they consider only what miners think, but the entire point of the max block size is for non-miner full nodes to constrain miners. See my post here.

Also, even though this sort of adaptive blocksize adjustment should not be done, there are far better adaptive blocksize proposals than this one... For example, this one requires miners to actually create larger blocks to vote for them, which means:

• Miners who want larger blocks may have to make fake transactions, wasting space.
• Miners who want smaller blocks have to throw away fee-paying transactions.

theymos [score hidden] an hour ago

miners already vote on difficulty - if they want a difficulty increase they increase their hashing power, if they want a difficulty decrease they decrease their hashing power.

That is irrelevant to block size.

The more decentralized that mining becomes, the less likely it will be for anyone to game it.

Possibly, but mining is absolutely not decentralized, and no one knows how to make it decentralized.


theymos [score hidden] 58 minutes ago

By including their own transactions, a miner increases their own orphan risk without collecting any additional fees.

This is a flaw in the Bitcoin network which will eventually be fixed. It can't be relied upon. IBLT and weak blocks (on Core's roadmap) will address this. Gavin's headers-first proposal is also an attempt to improve this issue.

Furthermore, I often see people saying, "Miners have an incentive not to create absolutely massive blocks because _____." But it's not enough to show that some incentive exists somewhere -- to convincingly show that loosening the max block size is safe, you need to show that miners (even malicious miners) will never bring the average block size to unsafe levels.

https://www.reddit.com/r/Bitcoin/comments/4bds66/adaptive_blocksize_proposal_by_bitpay/

 

[VeritasSapere]

Help me out here, looking for a specific word, security through obscurity vs security through ....

The word describes a more distributed, wider adoption base, and it rhymes with obscurity a bit, I have heard it said here before, a catchy phrase and it seemed relevant to my discussion in Bitcointalk.

 

[Peter R]

@VeritasSapere :

"security through ubiquity"?

 

[VeritasSapere]

@Peter R Thank you!

Its crazy sometimes when I start posting on Bitcointalk I just can not get myself to stop, will refrain from posting there for a while again after this round, takes up to much of my time. The small blockists are also very disrespectful and rude, its much nicer in here.

I will focus my energies more on writing for Satoshi's Bitcoin and the project that is being in run in parallel to it. When they tell me to fork off, they should be careful of what they wish for, it makes me feel like doing exactly that.

https://bitcointalk.org/index.php?topic=1330553.msg14264737#msg14264737

 

[cypherdoc]

theymos [score hidden] an hour ago*

The major problem with these sorts of adaptive proposals is that they consider only what miners think, but the entire point of the max block size is for non-miner full nodes to constrain miners. See my post here.

no, see @theZerg's comment ideas on this.

the purpose of the full nodes is not to restrain them esp in terms of blocksize. verify blocks yes, restrain size no.

that is the whole idea behind BU.
[doublepost=1458598850][/doublepost]

Theymos does'nt like it, but I didn't really understand his comments against. Jl777, can you comment to the accuracy of this?

theymos [score hidden] an hour ago*

The major problem with these sorts of adaptive proposals is that they consider only what miners think, but the entire point of the max block size is for non-miner full nodes to constrain miners. See my post here.

Also, even though this sort of adaptive blocksize adjustment should not be done, there are far better adaptive blocksize proposals than this one... For example, this one requires miners to actually create larger blocks to vote for them, which means:

• Miners who want larger blocks may have to make fake transactions, wasting space.
• Miners who want smaller blocks have to throw away fee-paying transactions.

theymos [score hidden] an hour ago

miners already vote on difficulty - if they want a difficulty increase they increase their hashing power, if they want a difficulty decrease they decrease their hashing power.

That is irrelevant to block size.

The more decentralized that mining becomes, the less likely it will be for anyone to game it.

Possibly, but mining is absolutely not decentralized, and no one knows how to make it decentralized.


theymos [score hidden] 58 minutes ago

By including their own transactions, a miner increases their own orphan risk without collecting any additional fees.

This is a flaw in the Bitcoin network which will eventually be fixed. It can't be relied upon. IBLT and weak blocks (on Core's roadmap) will address this. Gavin's headers-first proposal is also an attempt to improve this issue.

Furthermore, I often see people saying, "Miners have an incentive not to create absolutely massive blocks because _____." But it's not enough to show that some incentive exists somewhere -- to convincingly show that loosening the max block size is safe, you need to show that miners (even malicious miners) will never bring the average block size to unsafe levels.

https://www.reddit.com/r/Bitcoin/comments/4bds66/adaptive_blocksize_proposal_by_bitpay/

also, miners could also still orphan all blocks they deem too big. Its an extreme measure, but that makes sure that with a mere threat rogue miners could be force to step in line with the majority of miners-/u/seweso

 

[AdrianX]

to add to the post above, this works well with Gavin's headers first proposal that still requires miners to validate a block within 30 seconds of receiving news of it, failing to do so results in an orphan. this makes the adaptive block size somewhat depended on deployed technology and miners to effectively validate blocks and benefits those who innovate.

It will regulate block size not on the block size limits but on the network's ability to process blocks effectively. As technology improves, if the 30 second limit is never adjusted, that limit will represent more capacity as opposed to the existing block size limit that represents a growth limit.

it's a solution that voids the perverse incentives that Mike H was referring too where miners are working against their self interest for short term gains under the guidance of Blockstream Core.

 

[jl777]

I didnt analyze the details of the adaptive, but clearly if a deterministic adaptive blocksize limit is created, it removes this simplest of levers that the non-miners have to limit the bitcoin network.

So conceptually, any method that increased the blocksize based on recent history would allow the network to grow in capacity as usage grows. Whether this incentivizes evil forces to fill it with spam or not seems a moot point. They do that now and what happens now is everybody's tx is delayed for a long time, versus after the blocksize readjusts it would increase the cost of a spam attack.

If spam is a problem, then that should be addressed separately, but spam to one person is money to another. So there is danger that bitcoin will get used too much unless the txfees also scales along with the increased blocksize.

That way the blocksize adjusts to market forces that are willing to incur the txfee costs. And if that blocksize fills up, it adjust next time around. Just like the diff adjustments. Not sure why the controversy over periodic adjustments.

 

[AdrianX]

@jl777 with the inclusion of Gavin's Headers first there is or will be an overriding limit governor that requires all blocks to be validated within 30 seconds of hearing about it. So while miners can make bigger blocks and manipulate the adaptive block limit they have to meet the condition that all blocks can be validated within 30 seconds.

So there is a limit to how much (free or costly) spam can be included in each block.

 

[johnyj]

What I don't understand is, changing 1 to 2 and double the block size limit is not able to reach consensus after 18 months, while changing thousands of lines and totally change the bitcoin architecture is able to reach consensus in 3 months? There must be something very wrong here, it seems you only need one group of people agree to a solution then it suddenly becomes a consensus

 

[cypherdoc]

it's called Core Dev/Blockstream capture. it couldn't have happened any other way.