Bitcoin Forum
June 07, 2024, 07:55:22 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Poll
Question: Mike H. Interview: Convincing or not?
Rather convincing - 15 (31.9%)
Rather not convincing - 32 (68.1%)
Total Voters: 47

Pages: « 1 2 3 4 5 [6] 7 »  All
  Print  
Author Topic: Poll: Mike H. Interview - Convincing or not?  (Read 4904 times)
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3074



View Profile
October 01, 2015, 01:54:04 PM
 #101

You are the one who is bitter. You - like brg444 - are one of those who notoriously attack others ad hominem. Your newest ad hominem attack: "Hearn is a sociopath".


It's not ad hominem when it's:

  • The actual point of an argument
  • True

In other word: an ad hominem is not an ad hominem when I do it. Riiiight.  Roll Eyes

No, it's about whether the value judgement is the subject of a debate or whether it is intended as a subversive or diversive tactic i.e. actually conforming to the actual definition of ad hominem

But there's no need to explain to you, you re-write the book on subversive and diversionary argumentative tactics (literally) all day long (indeed, I'm currently defending myself from your twisted logic approach). 

Vires in numeris
knight22
Legendary
*
Offline Offline

Activity: 1372
Merit: 1000


--------------->¿?


View Profile
October 01, 2015, 01:59:47 PM
 #102

You are the one who is bitter. You - like brg444 - are one of those who notoriously attack others ad hominem. Your newest ad hominem attack: "Hearn is a sociopath".


It's not ad hominem when it's:

  • The actual point of an argument
  • True

In other word: an ad hominem is not an ad hominem when I do it. Riiiight.  Roll Eyes

No, it's about whether the value judgement is the subject of a debate or whether it is intended as a subversive or diversive tactic i.e. actually conforming to the actual definition of ad hominem

But there's no need to explain to you, you re-write the book on subversive and diversionary argumentative tactics (literally) all day long (indeed, I'm currently defending myself from your twisted logic approach). 

You should try to defend yourself with arguments instead of fluffy meaningless post (like above).

Klestin
Hero Member
*****
Offline Offline

Activity: 493
Merit: 500


View Profile
October 01, 2015, 03:09:40 PM
 #103

He's still pushing BIP101 which is probably the worst idea since the invention of software. Gavin and Mike are insane to keep sticking with that concept of doubling the max block size every two years.

Increase max blocksize to 8MB and make the change static, that's the best solution. Then fork again in a few years as/if needed.

If BIP 101 were adopted, we would move to 8MB, then when the first doubling came around, we could "fork again in a few years as/if needed".  If the first doubling were judged OK, we could revisit again in four years,  etc.

The idea that 101 somehow locks us in to the doubling permanently is completely wrong.  If 101 truly sounds like the "worst idea since the invention of software" to you, you've been listening to the shills too much.
coalitionfor8mb
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 01, 2015, 03:25:38 PM
 #104

He's still pushing BIP101 which is probably the worst idea since the invention of software. Gavin and Mike are insane to keep sticking with that concept of doubling the max block size every two years.

Increase max blocksize to 8MB and make the change static, that's the best solution. Then fork again in a few years as/if needed.

If BIP 101 were adopted, we would move to 8MB, then when the first doubling came around, we could "fork again in a few years as/if needed".  If the first doubling were judged OK, we could revisit again in four years,  etc.

The idea that 101 somehow locks us in to the doubling permanently is completely wrong.  If 101 truly sounds like the "worst idea since the invention of software" to you, you've been listening to the shills too much.

The only thing that forces us to come together and consider changing the rules is "static" limit on block size, but only when enough pressure begins building up. With the curve in BIP101 there will never be a distinct point in time that would trigger us to consider deviating from that schedule. The blockchain will slowly but surely be sliding away and eventually get locked up in those large data-centers under the premise of "national security", that's where Bitcoin as we know it would end.

But, as it stands now, even 8MB blocks might be risky at the moment as we may lose significant amounts of full nodes and then decisions of changing the "consensus" rules will be made without the actual users of the network. Economic pressure is a good thing, we should be welcoming it as there is a need to test this aspect of the system and see what other effects come into play and how the whole ecosystem reacts to this.
Klestin
Hero Member
*****
Offline Offline

Activity: 493
Merit: 500


View Profile
October 01, 2015, 03:42:55 PM
 #105

The only thing that forces us to come together and consider changing the rules is "static" limit on block size.

History proves you wrong on this one.  We've already changed the block size cap - it used to be unlimited (effectively 20MB due to other restrictions) and it was moved to 1MB as a temporary measure to avoid potential spamming.  

But, as it stands now, even 8MB blocks might be risky at the moment as we may lose significant amounts of full nodes and then decisions of changing the "consensus" rules will be made without the actual users of the network.

Switching to 8MB cap does exactly nothing immediately to the block size.  We currently have a 1MB cap, yet we do not have 1MB blocks.  8MB gives some room to grow, that's all.

Economic pressure is a good thing, we should be welcoming it as there is a need to test this aspect of the system and see what other effects come into play and how the whole ecosystem reacts to this.

Then you should welcome a block size increase.  We already have an open economic system.  If miners want higher fees, they are free to increase their minimums.  If enough of them do, then users will need to pay the fees or live with a slower transaction time.  If/when we hit the cap, we will be entering uncharted territory, and imposing an artificial block on the natural increase of Bitcoin adoption.
coalitionfor8mb
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 01, 2015, 04:16:02 PM
 #106

The only thing that forces us to come together and consider changing the rules is "static" limit on block size.

History proves you wrong on this one.  We've already changed the block size cap - it used to be unlimited (effectively 20MB due to other restrictions) and it was moved to 1MB as a temporary measure to avoid potential spamming.  

In the early stages the system had very little mass and inertia, thus Satoshi could easily tweak a few parameters here and there without everyone being concerned. The 1MB limit was placed 5 years ago, became part of the consensus rules and hasn't been touched since then. Only now we begin talking about it in a serious way.

But, as it stands now, even 8MB blocks might be risky at the moment as we may lose significant amounts of full nodes and then decisions of changing the "consensus" rules will be made without the actual users of the network.

Switching to 8MB cap does exactly nothing immediately to the block size.  We currently have a 1MB cap, yet we do not have 1MB blocks.  8MB gives some room to grow, that's all.

It does. If the current limit is removed before it becomes effective, then the new one doesn't make any sense, we can just as well throw it away. But that would definitely affect network's long-term characteristics (like costs to entry into validation) and make its evolutionary dynamics so much less predictable. If we are to agree on the new limit we must let the current one hold long enough and prove itself in action.

Economic pressure is a good thing, we should be welcoming it as there is a need to test this aspect of the system and see what other effects come into play and how the whole ecosystem reacts to this.
Then you should welcome a block size increase.  We already have an open economic system.  If miners want higher fees, they are free to increase their minimums.  If enough of them do, then users will need to pay the fees or live with a slower transaction time.  If/when we hit the cap, we will be entering uncharted territory, and imposing an artificial block on the natural increase of Bitcoin adoption.

Yes, we haven't gone through this yet. The part of the cycle when the system is operating under the economic pressure is absolutely necessary, as Bitcoin needs to demonstrate that the validation costs can temporarily go down in order for the idea of freely accessible blockchain to be sustainable over the decades to come. If Bitcoin cannot show this, then any even remotely successful crypto-currency would be destined to eventually centralize and lose its original core values.

There must be a force in the economic system which can weight in on the limit and defend it at all costs as it's supposed to represent their interests. We are talking about the Bitcoin users here and we stand united.
Klestin
Hero Member
*****
Offline Offline

Activity: 493
Merit: 500


View Profile
October 01, 2015, 05:38:04 PM
 #107

But, as it stands now, even 8MB blocks might be risky at the moment

Just noticed the disconnect between your message and your username.   Grin
coalitionfor8mb
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 01, 2015, 06:22:38 PM
 #108

But, as it stands now, even 8MB blocks might be risky at the moment

Just noticed the disconnect between your message and your username.   Grin

I appreciate your attention to details for I value that just as well. Smiley

My username suggests the next bandwidth target for the idea of a static limit on block size, but doesn't hint at the time when the adjustment needs to be made. I argued against many other more sophisticated scalability proposals with mathematical rigor, but it was when I found myself defending the future limit against the current one, that I realized the obvious contradiction in my line of thinking.

Finding the appropriate moment in time for the transition would become the most challenging and interesting part of Bitcoin's evolutionary path.
bambou
Sr. Member
****
Offline Offline

Activity: 346
Merit: 250


View Profile
October 02, 2015, 08:23:36 AM
 #109

But, as it stands now, even 8MB blocks might be risky at the moment

Just noticed the disconnect between your message and your username.   Grin

I appreciate your attention to details for I value that just as well. Smiley

My username suggests the next bandwidth target for the idea of a static limit on block size, but doesn't hint at the time when the adjustment needs to be made. I argued against many other more sophisticated scalability proposals with mathematical rigor, but it was when I found myself defending the future limit against the current one, that I realized the obvious contradiction in my line of thinking.

Finding the appropriate moment in time for the transition would become the most challenging and interesting part of Bitcoin's evolutionary path.

8mb block outta thin future extrapolations is as dumb as any other blocksize BIP proposal.

Besides, scaling is not a matter of blocksize so how about people let it go?

1MB Blocksize purposely prevent spam, and it is working just fine.

Its time the delusional reddit wanabees face the reality as such fork wont happen any time soon.

Economic majority wins.

Hearn, Gavin and their little noobs army out.

Non inultus premor
poeEDgar
Sr. Member
****
Offline Offline

Activity: 299
Merit: 250



View Profile
October 02, 2015, 08:47:57 AM
 #110

But, as it stands now, even 8MB blocks might be risky at the moment

Just noticed the disconnect between your message and your username.   Grin

I appreciate your attention to details for I value that just as well. Smiley

My username suggests the next bandwidth target for the idea of a static limit on block size, but doesn't hint at the time when the adjustment needs to be made. I argued against many other more sophisticated scalability proposals with mathematical rigor, but it was when I found myself defending the future limit against the current one, that I realized the obvious contradiction in my line of thinking.

Finding the appropriate moment in time for the transition would become the most challenging and interesting part of Bitcoin's evolutionary path.

8mb block outta thin future extrapolations is as dumb as any other blocksize BIP proposal.

Besides, scaling is not a matter of blocksize so how about people let it go?

1MB Blocksize purposely prevent spam, and it is working just fine.

Its time the delusional reddit wanabees face the reality as such fork wont happen any time soon.

Economic majority wins.

Hearn, Gavin and their little noobs army out.

Well, suppose that bitcoin is, in fact, growing and being adopted as we speak. While I'm obviously not too bothered by the idea of a fee market, I still think a fee market is less desirable than no fee market. So, if we have already maximized efficiency/minimized spam (we have not), I think addressing throughput directly is the next logical answer.

So, to the extent that we can increase the block size limit without foregoing or jeopardizing key tenets of bitcoin (consensus, decentralization, network security), I think we should do that. But that necessarily entails a very conservative approach where we can achieve testable conditions (i.e. roughly in line with actual demand).

8MB, exponential scaling = straight up reckless.

Quote from: Gavin Andresen
I woulda thunk you were old enough to be confident that technology DOES improve. In fits and starts, but over the long term it definitely gets better.
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3074



View Profile
October 02, 2015, 09:11:07 AM
 #111

But, as it stands now, even 8MB blocks might be risky at the moment

Just noticed the disconnect between your message and your username.   Grin

I appreciate your attention to details for I value that just as well. Smiley

My username suggests the next bandwidth target for the idea of a static limit on block size, but doesn't hint at the time when the adjustment needs to be made. I argued against many other more sophisticated scalability proposals with mathematical rigor, but it was when I found myself defending the future limit against the current one, that I realized the obvious contradiction in my line of thinking.

Finding the appropriate moment in time for the transition would become the most challenging and interesting part of Bitcoin's evolutionary path.

8mb block outta thin future extrapolations is as dumb as any other blocksize BIP proposal.

Besides, scaling is not a matter of blocksize so how about people let it go?

If it resolved a sudden spike in Bitcoin userbase (i.e. larger than x8), something like "8 and 8 only" wouldn't be such a terrible compromise to me, but I'd far prefer the beginning of at least some of the non-blocksize scaling solutions before any sudden aberrations in the transaction rate ever happen. Hope it transpires that way, a userbase spike right here in October 2015 would just reignite this timewasting nonsense all over again.

Vires in numeris
coalitionfor8mb
Newbie
*
Offline Offline

Activity: 42
Merit: 0


View Profile
October 02, 2015, 02:25:01 PM
Last edit: October 02, 2015, 05:26:58 PM by coalitionfor8mb
 #112

8mb block outta thin future extrapolations is as dumb as any other blocksize BIP proposal.
...
1MB Blocksize purposely prevent spam, and it is working just fine.

I'm glad that you're supporting the current 1MB limit to stay long enough, so do I.

The 8MB number comes from the idea that changes in the consensus rules need to be rare and discreet, otherwise the internal competition in the system would tear the whole idea of consensus apart fairly quickly. From that perspective the limit needs to be high enough for us not to bother changing it again for a long period of time and at the same time be able to counter potential external competition in this space. But because the new limit is so high compared to the current one we need to be careful with the appropriate timing for the change to take effect.

Well, suppose that bitcoin is, in fact, growing and being adopted as we speak. While I'm obviously not too bothered by the idea of a fee market, I still think a fee market is less desirable than no fee market. So, if we have already maximized efficiency/minimized spam (we have not), I think addressing throughput directly is the next logical answer.

So, to the extent that we can increase the block size limit without foregoing or jeopardizing key tenets of bitcoin (consensus, decentralization, network security), I think we should do that. But that necessarily entails a very conservative approach where we can achieve testable conditions (i.e. roughly in line with actual demand).

8MB, exponential scaling = straight up reckless.

8MB is indeed more of a throughput suggestion than anything else. There are concerns about super-linearity property of block verification time (meaning that single 8MB block might take longer to verify than 8x1MB blocks), so those need to be taken into account when the actual solution is going to be implemented.

Fee market is another interesting aspect of the system as the competition is supposed to prevent the economic pressure from building up too high, but the network effect and the costs to switch should work in favor of keeping each particular system pressurized. In the idealistic scenario that I keep in mind a few healthy coins representing the core values of the original idea might work as cylinders in the combustion engine, where each system is pressurized to the max at different moments in time and decides to raise its bandwidth target before the pressure leaves to another one. We will see how much of that actually manifests.
btcusury
Sr. Member
****
Offline Offline

Activity: 433
Merit: 260


View Profile
October 02, 2015, 04:49:45 PM
 #113

He's still pushing BIP101 which is probably the worst idea since the invention of software. Gavin and Mike are insane to keep sticking with that concept of doubling the max block size every two years.

Increase max blocksize to 8MB and make the change static, that's the best solution. Then fork again in a few years as/if needed.

The limit should be lift off completely. The network has its own limitations and doesn't need an artificial one at all.

Wait are you saying that the blocksize should have no limit? It seems to me that you don't understand how this thing works at all. Are you aware of all the massive exploits the system could be exposed to if that was the case?

To put a more clear analogy, it was as if you went to a regular everyday car's motor and lifted the max revolutions to limitless. You know what's going to happen once you get past what the actual motor can deal with. This is the case with Bitcoin, thats why a blocksize limit exists at all.

Don't concern yourself with him. He lives in bizarro world and desires a corporate takeover of Bitcoin

Yeah, despite his signature exposing the debt-based central banking mega-scam! Isn't that highly... peculiar? The retarded arguments of some of these bizarro posters is flabbergasting, their motivations hard to imagine...


Does Mike Hearn act like he trying to weaken Bitcoin on purpose or does he do it naturally?

THIS is the big question. This is what we want to figure out. Assuming motives is equally as silly as assuming that the most advanced malicious and sophisticated attackers are sitting idly by while decentralization undoes their millennia-old process of consolidation of centralized power structures.

FACT: There were hundreds of thousands of unnecessary deaths by December 2020 due to the censorship of all effective treatments (most notably ivermectin) in order to obtain EUA for experimental GT spike protein injections despite spike bioweaponization patents going back about a decade, and the manufacturers have 100% legal immunity despite long criminal histories.
Carlton Banks
Legendary
*
Offline Offline

Activity: 3430
Merit: 3074



View Profile
October 02, 2015, 05:22:10 PM
 #114

Does Mike Hearn act like he trying to weaken Bitcoin on purpose or does he do it naturally?

THIS is the big question. This is what we want to figure out. Assuming motives is equally as silly as assuming that the most advanced malicious and sophisticated attackers are sitting idly by while decentralization undoes their millennia-old process of consolidation of centralized power structures.


I don't think there's anything wrong with the latter assumption. Evidence suggests that the incumbents you are referring to almost certainly gamed the decentralisation trend as a scenario at least 20 years ago, if not further back. 

Vires in numeris
MicroGuy
Legendary
*
Offline Offline

Activity: 2506
Merit: 1030


Twitter @realmicroguy


View Profile WWW
October 02, 2015, 05:48:48 PM
 #115

Does Mike Hearn act like he trying to weaken Bitcoin on purpose or does he do it naturally?

THIS is the big question. This is what we want to figure out. Assuming motives is equally as silly as assuming that the most advanced malicious and sophisticated attackers are sitting idly by while decentralization undoes their millennia-old process of consolidation of centralized power structures.


Hearn and Gavin are clearly trying to implement a solution that would mimic a 'Satoshi solution' if he were active/present. But they are wrong.

Satoshi wouldn't auto-double the block limit every 2 years simply because we cannot predict the future that far in advance. Scaling the block limit is not a long-term (decades long) solution. Instead, he would increase the block limit to some arbitrary even number (probably eight), make it static and large enough to buy some years. Then he'd fork again down the road if network demand dictated and as additional solutions presented.

However, with the current regulatory squeeze and with businesses becoming frustrated over the core team's inaction, if we wait just a little longer, it won't be necessary to scale because network growth will enter a reversal/dying phase.
poeEDgar
Sr. Member
****
Offline Offline

Activity: 299
Merit: 250



View Profile
October 02, 2015, 05:53:58 PM
 #116

However, with the current regulatory squeeze and with businesses becoming frustrated over the core team's inaction, if we wait just a little longer, it won't be necessary to scale because network growth will enter a reversal/dying phase.

Why are people so worried about Bitpay and Circle being frustrated? Hell, Bitpay has got much bigger fish to fry than the block size debate. The blocks aren't full -- now bitcoin will die because the limit hasn't been increased?

Come on, now.... Roll Eyes

Quote from: Gavin Andresen
I woulda thunk you were old enough to be confident that technology DOES improve. In fits and starts, but over the long term it definitely gets better.
Velkro
Legendary
*
Offline Offline

Activity: 2296
Merit: 1014



View Profile
October 02, 2015, 05:59:57 PM
 #117

Dont like this persona, he didn't convience me.
He made enough evil things to bitcoin community, so no more him plz.
dothebeats
Legendary
*
Offline Offline

Activity: 3668
Merit: 1353


View Profile
October 02, 2015, 06:02:34 PM
 #118

But changing the block size to 8MB and doubling it every year is nuts for me, aside from the fact that Hearn and Gavin keep on pushing BIP 101 in our asses. I'm not convinced, though there are some points that interests me in that certain interview.
tvbcof
Legendary
*
Offline Offline

Activity: 4592
Merit: 1276


View Profile
October 02, 2015, 06:10:33 PM
 #119

But, as it stands now, even 8MB blocks might be risky at the moment

Just noticed the disconnect between your message and your username.   Grin

I appreciate your attention to details for I value that just as well. Smiley

My username suggests the next bandwidth target for the idea of a static limit on block size, but doesn't hint at the time when the adjustment needs to be made. I argued against many other more sophisticated scalability proposals with mathematical rigor, but it was when I found myself defending the future limit against the current one, that I realized the obvious contradiction in my line of thinking.

Finding the appropriate moment in time for the transition would become the most challenging and interesting part of Bitcoin's evolutionary path.

I'm probably one of the most rabid '1MBers' around and have been for years.  Ironically, I have no real problem with going to 8MB.  I only want to make sure that it happens AFTER a workable scaling mechanism to support 'every frappuccino purchase worldwide' has been fielded and proven.  Since way back in 2011, 'subordinate chains' has been what I see as the best solution in terms of achievability.

It became clear to me many years ago just on simple math that even at 1MB, jump-starting a full verifying node would be most practical by transferring physical media.  As long as the block size remains such that the blockchain can be passed along on a single and affordable consumer-grade storage device, I'm mostly happy.

If certain critical functions of 'native Bitcoin' can be effectively 'carried along' by those operating a purpose-oriented sidechain (for instance) then the pools of potential infrastructure support for native Bitcoin could be greatly expanded.  That is another metric I use in deciding what scale is acceptable and what scale is to onerous.


sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
October 02, 2015, 06:36:04 PM
 #120

 Ironically, I have no real problem with going to 8MB.  I only want to make sure that it happens AFTER a workable scaling mechanism to support 'every frappuccino purchase worldwide' has been fielded and proven.



That's probably exactly what Blockstream wants too.  With of course, their business interests cemented and future profits ensured.

Pages: « 1 2 3 4 5 [6] 7 »  All
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!