BIP100 updated - By Jeff Garzik and Tom Harding - page 2.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: d5000 on March 17, 2017, 12:17:17 PM

PS: It's funny - in other threads I'm attacked by Core maximalists

I'll attack the ideas and rhetoric of ANYONE who wants to do something dangerous, particularly people who consistently evade answering the difficult and pertinent questions about their dangerous ideas.

You've got nothing but name-calling smears and playground tactics, just like every other dishonest debater haunting Bitcoin

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Quote from: kano on March 16, 2017, 07:32:22 PM

Bitcoin's design is miner control based. Miner consensus.

No. Bitcoin has three power groups:

- Miners (consensus regarding valid transactions)
- Users (economic power)
- Developers (protocol development)

Very simple model:
Miners have the control over the blockchain. But they can't include only the transactions they want in their blocks, because then their mined coins would not be worth anything. Users can refuse to relay blocks from miners if they misbehave, but if they exaggerate then they risk a network split.
Users can't double spend because miners would not include their transactions in their network.
Developers have the control over the protocol. But they cannot do any protocol change they want, because if miners or users don't like them, they can use another client.

Practical example: If BTU forks off and the majority of the economic power stays with Core, then BTU's coins will be worth much less and miners have lost this gambling round. They can then join Core again, but will have lost a lot of money.

PS: It's funny - in other threads I'm attacked by Core maximalists, and here by a BU maximalist Wink

Intermediate positions seem to be the most difficult to sustain in a polarized ecosystem.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: d5000 on March 15, 2017, 06:37:36 PM

Quote from: kano on March 15, 2017, 06:21:31 PM

Quote from: d5000 on March 15, 2017, 05:29:02 PM

hard-coded upper bound limit that is manually moved when the developers conclude that it's safe with average Internet bandwidth at the time of the evaluation, as a worst-case maximum block size limit.

That (in red) is called centralisation.

Interesting. So every restriction in the protocol and its modifications / development is "centralization"?

Would you give all the decision power to miners? I tend to think that is not the majority consensus in the Bitcoin community. I prefer the current system with its (at least rudimentary) checks and balances.

What checks and balances are they?
A system that requires checks and balances by a centralized power that controls those decisions based on monetary gain is not a consensus at all.

Bitcoin's design is miner control based. Miner consensus.
If you don't like that, then go create an altcoin and play with that.

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

Quote from: kano on March 15, 2017, 06:21:31 PM

Quote from: d5000 on March 15, 2017, 05:29:02 PM

hard-coded upper bound limit that is manually moved when the developers conclude that it's safe with average Internet bandwidth at the time of the evaluation, as a worst-case maximum block size limit.

That (in red) is called centralisation.

Interesting. So every restriction in the protocol and its modifications / development is "centralization"?

Would you give all the decision power to miners? I tend to think that is not the majority consensus in the Bitcoin community. I prefer the current system with its (at least rudimentary) checks and balances.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: d5000 on March 15, 2017, 05:29:02 PM

I could live with this proposal if it was combined with Segwit or FlexTrans.

With some other users we have discussed another BIP 100-based proposal. The main difference to this one is that, in addition to the moving block size limit voted by miners, there would be a hard-coded upper bound limit that is manually moved when the developers conclude that it's safe with average Internet bandwidth at the time of the evaluation, as a worst-case maximum block size limit.

That (in red) is called centralisation.

d5000

legendary

Activity: 3906

Merit: 6249

Decentralization Maximalist

I could live with this proposal if it was combined with Segwit or FlexTrans.

With some other users we have discussed another BIP 100-based proposal. The main difference to this one is that, in addition to the moving block size limit voted by miners, there would be a hard-coded upper bound limit that is manually moved when the developers conclude that it's safe with average Internet bandwidth at the time of the evaluation, as a worst-case maximum block size limit.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: bitsolutions on March 14, 2017, 01:53:42 PM

Quote from: kano on March 14, 2017, 09:02:20 AM

The 75% he is referring to is if BIP100 was ALREADY activated.

I don't see any activation threshold, best I can tell is that it's effectively 75% since there isn't anything else.

Garzik's BIP100 uses the standard core=95% activation of the BIP.

That's nothing to do with the 'regular' block size changes once BIP100 has activated ... if you understand how BIP100 works.

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: bitsolutions on March 14, 2017, 01:53:42 PM

Quote from: kano on March 14, 2017, 09:02:20 AM

The 75% he is referring to is if BIP100 was ALREADY activated.

I don't see any activation threshold, best I can tell is that it's effectively 75% since there isn't anything else.

kano is a born liar with bizarre business relationships, don't waste your time

bitsolutions

sr. member

Activity: 261

Merit: 257

Quote from: kano on March 14, 2017, 09:02:20 AM

The 75% he is referring to is if BIP100 was ALREADY activated.

I don't see any activation threshold, best I can tell is that it's effectively 75% since there isn't anything else.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: bitsolutions on March 14, 2017, 07:37:04 AM

Quote from: Xester on March 14, 2017, 07:27:48 AM

The problem lies on getting a 75% consensus from the miners

75% among just miners is way too low a threshold, you need strong economic support as well which is unlikely to happen at this point(SegWit is really the only proposal at this time with a decent level of support from the economy), and even then you probably want 90% or higher miner support in addition to a very long lead time(6-12 months) for any HF.

At least get your info correct.

The 75% he is referring to is if BIP100 was ALREADY activated.
The 75% is required, once BIP100 is activated, to adjust the block size up or down via coinbase voting, to be in the 1MB to 32MB range, with only a small adjustment each time.

Segwit has no such option, it's a "side effect" block size increase, if you use certain addresses.
So all SegWit does in reference to the block size, is give a new, non-adjustable, 'possible' larger block size.

bitsolutions

sr. member

Activity: 261

Merit: 257

Quote from: Xester on March 14, 2017, 07:27:48 AM

The problem lies on getting a 75% consensus from the miners

75% among just miners is way too low a threshold, you need strong economic support as well which is unlikely to happen at this point(SegWit is really the only proposal at this time with a decent level of support from the economy), and even then you probably want 90% or higher miner support in addition to a very long lead time(6-12 months) for any HF.

Xester

hero member

Activity: 994

Merit: 544

This idea of BIP100 is actually a good one. By using this kind of strategy we would no longer be choosing Segwit or Bitcoin Unlimited but we can solve the mining problems in the natural way. The problem lies on getting a 75% consensus from the miners, there are greedy people who are complicating things so that they can have control over bitcoin production and mining. If we just follow this path then there will be no problems and there is no need to complicate things.

bitsolutions

sr. member

Activity: 261

Merit: 257

Quote from: HostFat on March 13, 2017, 05:32:57 PM

Maybe because Bitcoin Core 0.12 code is known by a very large number of people, so it can have a very good peer review.

Core 0.12 should not be used for mining, there are known DoS vectors that were patched later on.

Keep in mind this isn't the original BIP100 proposal, this is hacked up version that's IMO significantly more risky.

AngryDwarf

sr. member

Activity: 476

Merit: 501

Quote from: -ck on March 13, 2017, 07:45:15 PM

There are many improvements in 0.13 and 0.14 that are totally unrelated to segwit and if segwit never gets activated the segwit code goes untouched, so forking off 0.12 is just leaving us with ancient code.

If segwit does not get activated, then the segwit code should be removed. Sounds like a horrible and potentially dangerous maintenance issue to have unused code lying around.
So then the question is, regarding the non segwit performance improvements in 0.13 and 0.14, is it easier to remove the segwit code, or implement the performance improvements to a pre-segwit version? I suppose only those that are really familiar with the code will know, and it might be a combination of doing both depending on the area of code that needs to be modified.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: AngryDwarf on March 13, 2017, 07:06:14 PM

Quote from: HostFat on March 13, 2017, 05:32:57 PM

Quote from: -ck on March 13, 2017, 05:19:53 PM

For core version 0.12... why?

Maybe because Bitcoin Core 0.12 code is known by a very large number of people, so it can have a very good peer review.

That's one good reason for using bitcoin core 0.12 code as a base for development ideas. The other is the fact that segwit has not been activated and may never be.

So lets say someone spots a good opportunity for a code optimisation that does not affect the existing protocol of nodes. It can peer reviewed by more people. It can be integrated into other nodes such as core/classic/xt/bu easier by the developers who understand the differences from that code base.

That doesn't make sense for the former reason; the latter (integration with other codebases forked off earlier) does. There are many improvements in 0.13 and 0.14 that are totally unrelated to segwit and if segwit never gets activated the segwit code goes untouched, so forking off 0.12 is just leaving us with ancient code. The problem is everyone's rushing to get on top of each other with new proposals and choosing the shortest cuts possible. Oh well stick around long enough and *someone* will probably create a BIP100 for current core...

AngryDwarf

sr. member

Activity: 476

Merit: 501

Quote from: HostFat on March 13, 2017, 05:32:57 PM

Quote from: -ck on March 13, 2017, 05:19:53 PM

For core version 0.12... why?

Maybe because Bitcoin Core 0.12 code is known by a very large number of people, so it can have a very good peer review.

That's one good reason for using bitcoin core 0.12 code as a base for development ideas. The other is the fact that segwit has not been activated and may never be.

So lets say someone spots a good opportunity for a code optimisation that does not affect the existing protocol of nodes. It can peer reviewed by more people. It can be integrated into other nodes such as core/classic/xt/bu easier by the developers who understand the differences from that code base.

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Carlton Banks on March 13, 2017, 06:07:09 PM

Quote from: kano on March 13, 2017, 06:02:41 PM

If core put a pure BIP100 vote option in a release, I'd expect it would happen.

If that's what you're expecting, you're wrong on both counts

And you know you're wrong, don't you

LOL you removed the relevant text

To be expected - your trolling fails.

Quote from: kano on March 13, 2017, 06:02:41 PM

...
If core put a pure BIP100 vote option in a release, I'd expect it would happen.
BIP100 did reach 70% before with coinbase comments ... until everyone realised that core had no intention of implementing it.

franky1

legendary

Activity: 4410

Merit: 4766

Quote from: kano on March 13, 2017, 06:02:41 PM

Quote from: Carlton Banks on March 13, 2017, 05:11:07 PM

why are you jackals trying to promote 2 different "Democratic" blocksize proposals at once (this and BU)

is it because user support for BU is so low, despite how many BU nodes you have spread out over so many hosting services

Yeah people shouldn't be allowed to promote more than one thing ... and it should only be segwit Tongue

/sarcasm

If core put a pure BIP100 vote option in a release, I'd expect it would happen.
BIP100 did reach 70% before with coinbase comments ... until everyone realised that core had no intention of implementing it.

any dynamic is acceptable to BU, and with for instance. the 5% every 2week max growth. it will take a few years before affecting xt.. so the only one it does affect at activation is core.
(funnily enough a few people have manually taken core and already put in a 2mb+ in their limits to cover any network change and they all run fine on the network)

all core need to do is actually give in and add just the few minimal changes. or be a**hats and orphan&ban the majority if they want to dig their heels in and oppose it.(creating their own altcoin)

i would actually prefer core to have some extra RPC commands or a GUI options tab where users can while LIVE. change settings.
that way users are now slaves to devs digging their heels in by refusing to change something

Carlton Banks

legendary

Activity: 3430

Merit: 3080

Quote from: kano on March 13, 2017, 06:02:41 PM

If core put a pure BIP100 vote option in a release, I'd expect it would happen.

If that's what you're expecting, you're wrong on both counts

And you know you're wrong, don't you

kano

legendary

Activity: 4592

Merit: 1851

Linux since 1997 RedHat 4

Quote from: Carlton Banks on March 13, 2017, 05:11:07 PM

why are you jackals trying to promote 2 different "Democratic" blocksize proposals at once (this and BU)

is it because user support for BU is so low, despite how many BU nodes you have spread out over so many hosting services

Yeah people shouldn't be allowed to promote more than one thing ... and it should only be segwit Tongue

/sarcasm

If core put a pure BIP100 vote option in a release, I'd expect it would happen.
BIP100 did reach 70% before with coinbase comments ... until everyone realised that core had no intention of implementing it.

Topic: BIP100 updated - By Jeff Garzik and Tom Harding - page 2. (Read 3169 times)