ToominCoin aka "Bitcoin_Classic" #R3KT

[Lauda]

does Core have or plan to have this?

I'd like to see evidence of these features working first. As far as Traffic-shaping is concerned, this is implemented in Core (Reduce upload traffic - in changelog) under another name  (they claim that they "coded it"). This does not even surprise me. I'd like to see real data on Thinblocks, however I do remember maxwell saying somewhere that it is noticeably worse than the relay network from Corralo. So let's see.

This protocol is similar to, but seemingly less efficient than the fast block relay protocol which is already used to relay almost every block on the network. Less efficient because this protocol needs one or more roundtrips, while Matt's protocol does not.
From a bandwidth reduction perspective, this like IBLT and network block coding aren't very interesting: at most they're only a 50% savings (and for edge nodes and wallets, running connections in blocksonly node uses far less bandwidth still, but cutting out gossiping overheads). But the latency improvement can be much larger, which is critical for miners-- and no one else. The fast block relay protocol was developed and deployed at a time when miners were rapidly consolidating towards a single pool due to experiencing high orphaning as miners started producing blocks over 500kb; and I think it can be credited for turning back that trend.

Tensions between Team Unlimited and Classic's Censorship Martyr Brigade are running high.

Try posting something positive on r/btc and you will get downvoted to oblivion (ergo another type of censorship, yet nobody bats an eye).  



 

[Denker]

Mmhhh

[Lauda]

The very Brian Armstrong showing support for a Sybil attack. How lovely. These nodes are completely useless for decentralization.

[VeritasSapere]

does Core have or plan to have this?

I'd like to see evidence of these features working first. As far as Traffic-shaping is concerned, this is implemented in Core (Reduce upload traffic - in changelog) under another name  (they claim that they "coded it").

Traffic shaping was first implemented by XT not Core. Furthermore the traffic shaping feature in Core just cuts off upload at N bytes for those who have metered plans. This is no where near as useful as proper throttling controls which Bitcoin Unlimited has even implemented within a new GUI.

This does not even surprise me. I'd like to see real data on Thinblocks, however I do remember maxwell saying somewhere that it is noticeably worse than the relay network from Corralo. So let's see.

I do no understand how this could be worse then the relay network, since Xthin is a decentralized solution. Furthermore it speeds up block propagation by a factor of at least fifteen. Block propagation times being the main restricting factor for an increased blocksize by small block proponents, you should be able to see how this is a huge breakthrough.

This protocol is similar to, but seemingly less efficient than the fast block relay protocol which is already used to relay almost every block on the network. Less efficient because this protocol needs one or more roundtrips, while Matt's protocol does not.

This is false, Xthin only does one round trip.

From a bandwidth reduction perspective, this like IBLT and network block coding aren't very interesting: at most they're only a 50% savings (and for edge nodes and wallets, running connections in blocksonly node uses far less bandwidth still, but cutting out gossiping overheads).

A fifty percent reduction in bandwidth is huge, does that not then mean we can justifiably at least increase the blocksize by fifty percent then according to your own understanding of the limits of Bitcoin?

But the latency improvement can be much larger, which is critical for miners-- and no one else.

Exactly, the miners being one of the main reasons for not increasing the blocksize, because of fears of mining centralization due to block propagation. This innovation therefore would allow us to increase the blocksize fifteen times, compared to today with the same centralization pressures that we have today with one megabyte blocks.

Tensions between Team Unlimited and Classic's Censorship Martyr Brigade are running high.

Try posting something positive on r/btc and you will get downvoted to oblivion (ergo another type of censorship, yet nobody bats an eye).

It is very revealing that you can not tell the difference between downvoting and real censorship, which has recently gone into full overdrive. Even censoring any mention of Xthin in the r/Bitcoin reddit.

Bitcoin Unlimited has all of the features that the latest Core release has. Except for RBF which the Bitcoin Unlimited community voted not to include in the latest release. Bitcoin Unlimited now has more beneficial features compared to Core. While Core is focusing on building off chain solutions, Bitcoin Unlimited and Bitcoin Classic are focusing on scaling the Bitcoin blockchain directly.

Bitcoin Unlimited and Bitcoin Classic are friends, our implementations are compatible with each other unlike Core. An example of how competing implementations can cooperate.

[Lauda]

Traffic shaping was first implemented by XT not Core. Furthermore the traffic shaping feature in Core just cuts off upload at N bytes for those who have metered plans. This is no where near as useful as proper throttling controls which Bitcoin Unlimited has even implemented within a new GUI.

Not really, no.

I do no understand how this could be worse then the relay network, since Xthin is a decentralized solution.

So is the relay network, it is a protocol. However, I'll let Maxwell answer the other parts if he notices this thread again.

It is very revealing that you can not tell the difference between downvoting and real censorship, which has recently gone into full overdrive. Even censoring any mention of Xthin in the r/Bitcoin reddit.

It is another type of censorship. Your opinion is biased if you only see the tactics deployed by one side.

Bitcoin Unlimited now has more beneficial features compared to Core.

First you proceed to copy paste everything from Core, then you apply a few features of your own and call your implementation 'more beneficial'? What a joke.

[adamstgBit]

Traffic shaping was first implemented by XT not Core. Furthermore the traffic shaping feature in Core just cuts off upload at N bytes for those who have metered plans. This is no where near as useful as proper throttling controls which Bitcoin Unlimited has even implemented within a new GUI.

Not really, no.

Bitcoin Unlimited now has more beneficial features compared to Core.

First you proceed to copy paste everything from Core, then you apply a few features of your own and call your implementation 'more beneficial'? What a joke.

Welcome to open source software dev. no it's not a joke.

[Lauda]

Welcome to open source software dev. no it's not a joke.

I know how the development process goes. However, they can withhold merging these features. They could wait for Core to release an upgrade each time and then merge those changes in addition to their features. Technically they could claim that their implementation is better after each release because of their features (which they think are useful). Very respectful indeed.

[adamstgBit]

Welcome to open source software dev. no it's not a joke.

They can withhold merging their features. They could wait for Core to release an upgrade each time and then merge those changes in addition to their features. Technically they could claim that their implementation is better each time because of their features (which they think are useful).

core can do the same.
If these features really are pointless and not noteworthy then just ignore it
Its feels like an awful waste to dismiss all code from anyone else simply because they're not your friend.
IDK, but i get the feeling Core is very... how do i put it... Hostile? Close minded? fuck idk , this is just the feeling i get when i read these comments from the Core supports...


i see gavin going around helping all, and core hoarding code and pointing fingers at everyone..

[Lauda]

core can do the same.
If these features really are pointless and not noteworthy then just ignore it
Its feels like an awful waste to dismiss all code from anyone else simply because they're not your friend.

No. That's not what I'm saying. All I'm saying is that acting this way is disrespectful towards the people who did most of the work. If the code is good and useful somebody will present it to Core. You've quoted an earlier version of my post, I re-wrote it several times.

i see gavin going around helping all, and core hoarding code and pointing fingers at everyone..

Core hasn't done such a thing. It is the 'forkers' that point fingers whenever something happens (e.g. DDoS).
Update: Corrections.

[VeritasSapere]

Explain to me, how is Bitcoin Unlimited being disrespectful by using the open source code developed by Core while at the same time developing new open source solutions to scaling Bitcoin directly? That makes absolutely no sense to me at all, open source code should be free and open for everyone to use regardless of their reasons. I do not see how this is supposably disrespectful in any way. If anything the entire Bitcoin community should thank Bitcoin Unlimited for these breakthroughs in the same way that I can thank Core for the work they have done.

[Lauda]

Explain to me, how is Bitcoin Unlimited being disrespectful by using the open source code developed by Core while at the same time developing new open source solutions to scaling Bitcoin directly?

You claim implementation superiority without giving adequate amount of credit to the people who did most of the work. This might be just a subjective opinion, you're free to disagree.

If anything the entire Bitcoin community should thank Bitcoin Unlimited for these breakthroughs in the same way that I can thank Core for the work they have done.

No, we shouldn't. If you claim that they're breakthroughs, that doesn't make them such. I'd like to see analysis from a 3rd party first before giving any credit to anyone.

[iCEBREAKER]

P> Announcing BitcoinUnlimited v0.12.0

Xtreme Thinblocks
BUIP010 Reduces real-time block propagation sizes by an average of 15x (i.e. 1MB down to 70KB) returning the network overhead for newly mined blocks to the state it was in June 2012
​
Xpress Validation
BUIP010 Superfast block validation leverages the earlier validation of transactions which are in the mempool so that only previously unseen transactions in a block need full validation.
​
Traffic-shaping
BUIP001 Users can easily configure how much bandwidth should be used for Bitcoin, allowing the BU client to run unobtrusively in a home network.

this seems like good stuff, what's your take on it iCEBREAKER?

does Core have or plan to have this?

Core has bandwidth throttling.  IDK if the other two ideas are in BIPs.

[VeritasSapere]

Explain to me, how is Bitcoin Unlimited being disrespectful by using the open source code developed by Core while at the same time developing new open source solutions to scaling Bitcoin directly?

You claim implementation superiority without giving adequate amount of credit to the people who did most of the work.

It does not matter who did the most work, what matters is what is in the client itself, that determines which implementation should be considered the "best" at any one time. What matters is what is in the code, not the people that are behind it.

What do you mean with not giving adequate credit? That also does not make any sense, it is clear who wrote what code, nothing is being obfuscated and all of the code is properly accredited.

If anything the entire Bitcoin community should thank Bitcoin Unlimited for these breakthroughs in the same way that I can thank Core for the work they have done.

No, we shouldn't. If you claim that they're breakthroughs, that doesn't make them such. I'd like to see analysis from a 3rd party first before giving any credit to anyone.

The testing has already been done, you can check the results for yourself, you could even compile the code yourself and test it, it is relatively easy to do. It almost seems like you are implying intellectual dishonesty on the side of the Bitcoin Unlimited team. Which I could say even borders on being disrespectful, since it does seem like you do not apply these same standards to Core. It is good to be skeptical though, the code is out there for everyone to critique. I am sure that if it was flawed the small blockists camp would not hesitate in letting everyone know that was the case.

[Lauda]

What matters is what is in the client itself, that determines which implementation should be considered the "best" at any one time.

I've described what I'd consider dishonest tactics of 'achieving this'. Let's see if BU will do this in the future.

All of the code is properly accredited.

Where?

It almost seems like you are implying intellectual dishonesty on the side of the Bitcoin Unlimited team. Which I could say even borders on being disrespectful, since it does seem like you do not apply these same standards to Core. It is good to be skeptical though, the code is out there for everyone to critique. I am sure that if it was flawed the small blockists camp would not hesitate in letting everyone know that is the case.

This team is not very experienced (nothing special there). I'm not implying dishonesty, I want a 3rd party review. It's as simple as that.
However, this is all off-topic here. This thread is about Classic, not BU.

[watashi-kokoto]

This classic rebellion is completely pointless. The core team haven't failed at all. They are delivering and will deliver.

It's time to engineer and deploy SegWit. I'm confident it can be developed and deployed correctly. If that fails, and developers mismanage this, then it's turn for the haters to express their concerns and assemble their own team.

[VeritasSapere]

This classic rebellion is completely pointless. The core team haven't failed at all. They are delivering and will deliver.

It's time to engineer and deploy SegWit. I'm confident it can be developed and deployed correctly. If that fails, and developers mismanage this, then it's turn for the haters to express their concerns and assemble their own team.

As far as I understand Core presently lacks the support they said they needed from the miners in order to implement segwit. I believe Core said they needed ninety five percent consensus for segwit, they have no where near that amount, especially considering that F2pool recently withdrew their support from the Core roadmap. For now segwit is dead in the water throwing the entire roadmap of Core into question.

Here is the Bitcoin Classic roadmap by the way, which I consider a much more sensible roadmap for Bitcoin:

https://github.com/bitcoinclassic/documentation/blob/master/roadmap/roadmap2016.md

[adamstgBit]

This classic rebellion is completely pointless. The core team haven't failed at all. They are delivering and will deliver.

It's time to engineer and deploy SegWit. I'm confident it can be developed and deployed correctly. If that fails, and developers mismanage this, then it's turn for the haters to express their concerns and assemble their own team.

if we could get 3 highly qualified teams all competing to get there new features pulled into "Bitcoin" without anyone of them having the power to actually pull in the new features themselves, that would be ideal.
I don't like the idea of a monopoly on what gets added to bitcoin and what doesn't.
it was necessary at the beginning ( there was only one team )
but if we can break away from that, that would be great.

[adamstgBit]

This classic rebellion is completely pointless. The core team haven't failed at all. They are delivering and will deliver.

It's time to engineer and deploy SegWit. I'm confident it can be developed and deployed correctly. If that fails, and developers mismanage this, then it's turn for the haters to express their concerns and assemble their own team.

if we could get 3 highly qualified teams all competing to get there new features pulled into "Bitcoin" without anyone of them having the power to actually pull in the new features themselves, that would be ideal.
I don't like the idea of a monopoly on what gets added to bitcoin and what doesn't.
it was necessary at the beginning ( there was only one team )
but if we can break away from that, that would be great.

wasn't there a BIP made to allow this kind of thing to happen?

miners would be allowed to express their willingness to accept whatever new features are on the table? once >90% of minners had flaged a feature as acceptable it would get activated.

[VeritasSapere]

This classic rebellion is completely pointless. The core team haven't failed at all. They are delivering and will deliver.

It's time to engineer and deploy SegWit. I'm confident it can be developed and deployed correctly. If that fails, and developers mismanage this, then it's turn for the haters to express their concerns and assemble their own team.

if we could get 3 highly qualified teams all competing to get there new features pulled into "Bitcoin" without anyone of them having the power to actually pull in the new features themselves.
I don't like the idea of a monopoly on what gets added to bitcoin and what doesn't.
it was necessary at the beginning ( there was only one team )
but if we can break away from that, that would be great.

I entirely agree. I think that the success of the decentralized governance of Bitcoin depends on us having multiple implementations for us to choose from. All open source projects are essentially types of dictatorships, the only way for this to become free is to distribute and decentralized development. The client people choose to run should reflect the peoples freedom of choice, this is how the governance of Bitcoin should work. This idea of having a monopoly on development which only a few people are in charge off and even have veto power over is completely antithetical to the very ethos of Bitcoin itself.

wasn't there a BIP made to allow this kind of thing to happen?

miners would be allowed to express their willingness to accept whatever new features are on the table? once >90% of minners had flaged a feature as acceptable it would get activated.

Core seems to have rejected this idea of the miners voting, therefore Core defines consensus instead of proof of work. I do fundamentally disagree with this of course. The miners should be the ones with the vote, it was even described this way within the Bitcoin whitepaper.

They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them.  Any needed rules and incentives can be enforced with this consensus mechanism.

[watashi-kokoto]

I don't like the idea of a monopoly on what gets added to bitcoin and what doesn't.

Fine. You may like other network, Paypal maybe, or Doge? Where charismatic leaders or users respectively decide what gets added.

In a cryptocurrency, miners always have the final say in what gets added and what not.