Bitcoin Forum
November 18, 2024, 06:57:39 PM *
News: Check out the artwork 1Dq created to commemorate this forum's 15th anniversary
 
   Home   Help Search Login Register More  
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 »  All
  Print  
Author Topic: SegWit losing Bitcoin Unlimited winning -> Moon soon  (Read 13507 times)
iamnotback
Sr. Member
****
Offline Offline

Activity: 336
Merit: 265



View Profile
March 21, 2017, 07:31:18 AM
 #121

If you wanted to upend Core, then you should have more competent people who would have advised you that unbounded block size doesn't have an equilibrium.

If you have successfully demonstrated  that unbounded block size cannot reach an equilibrium outside a majority-collusion environment, I have missed it.

Yes you missed it. I have already explained the math for why there is no relationship between an average orphan rate and a cost per byte (which is a necessary prerequisite for a supply curve as explained by @Peter R's paper). In other words, if we model that every miner has the same orphan rate, then there is no level of block size which is more or less favorable to the miner, because difficulty adjusts to the same level for all the miners. In other words, the wasted hashrate of the orphan rate is paid for by income from the block because all miners have the same costs (@Peter R's model inherently presumes that hashrate and propagation delay are uniformly distributed).

It is only when we model relativistic orphan rate (which @Peter R's paper doesn't even consider) that we will see any relative profit levels and able to model orphan rate as a cost. @Peter R should have realized this, but he apparently didn't quite realize that his model was meaningless although he did mention some of these issues that perplexed him in his concluding remarks.

Once we do model differing orphan rates for different miners, then the optimal strategies for mining come into play. And if you work out the game theory of that, you realize that collusion and centralization are the only possible outcome.

...(if you don't understand why then you need to study the original selfish mining paper and the followup on optimal mining strategies)....

Also I received a reply in private from one of the people I asked to peer review the issue:

Quote from: anonymous expert
I watched Peter R. video. You're right to point out that his arguments are undermined by
1) propagation delays not having much impact until blocks are really huge, at which point running full nodes will be very hard and the system is hopelessly centralized.
2) these delays do not even matter when using trusted headers-first.



If your argument is that there is no equilibrium in a majority-collusion environment, then your fear is as valid for today's Bitcoin than it is under unbounded blocksize. Nakamoto consensus is -- as far as we know -- dependent upon 'a majority of honest [miners]'.

You are making a similar error as those two others did upthread. A 51% (or even 33% selfish mining) attack is not a change in protocol. In other words, in BTC the miners can't make huge blocks, because it violates the protocol limit of 1MB.

And as a practical matter, Bitcoin operated just fine for multiple halvings with no practical bound on blocksize.

There was minimum advised fee and there were pools doing anti-spam such as I think I've read that Luke Jr's pool rejected dust transactions. I haven't studied that period of time in great detail, so perhaps someone else would be better qualified to discuss that with you.
iamnotback
Sr. Member
****
Offline Offline

Activity: 336
Merit: 265



View Profile
March 21, 2017, 08:46:07 AM
Last edit: March 21, 2017, 09:06:07 AM by iamnotback
 #122

To all Bitcoin Unlimited supporters, I am not against larger blocks. I haven't been following all the detailed developments, so the following might contain some errors.

My thought is reformulate your protocol to have some where between 2 - 8MB block size limit increasing with the Nielsen Law of bandwidth increase (slower exponential growth than Moore's law). Also you must adopt some of the bug fixes in SegWit, such as the new opcode which fixes malleability and enables Lightning Networks.

But do not adopt all the rest of the complexity of SegWit, including do not adopt the ability to softfork version changes as that hands too much power to Core.

Go do that, then maybe you can win. Because likely users will end up choosing to support your protocol because their transactions are not being delayed. But you need to build confidence in your competence to lead.

You can possibly win, if you get competent people working with you.

But you need to rein in these talking heads who are not sufficiently competent, i.e. Wu and Ver. They can talk when they cite competent developers. Those guys need to understand the limits of their role and competencies.

You are apparently competing against banksters who are funding the Core developers (paying their large salaries and incentives). Perhaps that may explain why you ostensibly can't attract the most competent developers?

I am not against what you want in terms of fixing the block size problem. I am just being pragmatic. Find a confidence building and realistic way to win. I don't like being on the losing side.

I highly advise that you all back down from your current ultimatum and reformulate and get the token holders on your side before you proceed. You really need a more capable leader than Wu or Ver. But don't enlist me, because I am too busy on my own "shitcoin" project and I am not interested in investing my effort in Satoshi's PoW. It is good to have those guys on your side, but not as the outspoken de facto leaders, because they have by now proven they are rash, irrational, and somewhat technologically incompetent.
spiderbrain
Legendary
*
Offline Offline

Activity: 889
Merit: 1013



View Profile
March 21, 2017, 10:14:25 AM
 #123

To all Bitcoin Unlimited supporters, I am not against larger blocks. I haven't been following all the detailed developments, so the following might contain some errors.

My thought is reformulate your protocol to have some where between 2 - 8MB block size limit increasing with the Nielsen Law of bandwidth increase (slower exponential growth than Moore's law). Also you must adopt some of the bug fixes in SegWit, such as the new opcode which fixes malleability and enables Lightning Networks.

But do not adopt all the rest of the complexity of SegWit, including do not adopt the ability to softfork version changes as that hands too much power to Core.

Go do that, then maybe you can win. Because likely users will end up choosing to support your protocol because their transactions are not being delayed. But you need to build confidence in your competence to lead.

You can possibly win, if you get competent people working with you.

But you need to rein in these talking heads who are not sufficiently competent, i.e. Wu and Ver. They can talk when they cite competent developers. Those guys need to understand the limits of their role and competencies.

You are apparently competing against banksters who are funding the Core developers (paying their large salaries and incentives). Perhaps that may explain why you ostensibly can't attract the most competent developers?

I am not against what you want in terms of fixing the block size problem. I am just being pragmatic. Find a confidence building and realistic way to win. I don't like being on the losing side.

I highly advise that you all back down from your current ultimatum and reformulate and get the token holders on your side before you proceed. You really need a more capable leader than Wu or Ver. But don't enlist me, because I am too busy on my own "shitcoin" project and I am not interested in investing my effort in Satoshi's PoW. It is good to have those guys on your side, but not as the outspoken de facto leaders, because they have by now proven they are rash, irrational, and somewhat technologically incompetent.

Great words, sir.

Miz4r
Legendary
*
Offline Offline

Activity: 1246
Merit: 1000


View Profile
March 21, 2017, 03:19:05 PM
 #124

Although I do not agree with the sentiment against Core (I think Greg Maxwell and most others are very reasonable people who truly care about censorship resistance and monetary freedom), the points 'iamnotback' raises about the technical and game theoretic incompetency of BU and their supporters are correct in my opinion. BU can't win in their current state, even if they get a large majority hashrate behind them. I used to be critical of Core and supported Bitcoin XT for a short while, but that was because I didn't understand Core's position and reasons for not supporting a larger blocksize limit and they weren't exactly communicating much with the community at that time. This has changed and I understand their reasons a lot better now, and so they have earned my support back. My opinion on the whole blocksize issue also blinded me from looking critically at XT, and this is a bias I do not wish to repeat with BU or other alternative implementations. I don't like entrenched positions and opinions, I prefer an unbiased and open look without assuming bad faith upon the other one. I see both sides assuming bad faith here and it saddens me. We should be more united as a community, even if we have individual disagreements about the way forward. Ditching Core is not the solution, we can't throw away the best developers in the field because of unfounded conspiracy theories or because of censorship on reddit. We should adopt SegWit as soon as possible and then work together forward towards Lightning and a HF with wide support from the entire community.

If this is not possible, then just fork already so we can move on with SegWit and no longer have to listen to these endless debates that are going nowhere. I'm sure BU supporters have their own forum somewhere where they can discuss their stuff.

Bitcoin = Gold on steroids
Vaccinus
Sr. Member
****
Offline Offline

Activity: 406
Merit: 250



View Profile
March 21, 2017, 04:35:48 PM
 #125

i do not agree the difference is only 10% based on the chart, they are there, just more number of percentage for BU because a pool decided to test the new chain, antpool is not fully going with BU yet, don't be deceived, until it pass 50-60% i'm not worried about a hard fork for good reason

jbreher
Legendary
*
Offline Offline

Activity: 3052
Merit: 1665


lose: unfind ... loose: untight


View Profile
March 21, 2017, 05:31:59 PM
 #126

Hey Shelby - I'll circle back to your previous post after this (that one requires more thought). First, I need to say that I don't 'speak for BU'. I'm just a guy that thinks their vision is correct. Most intelligent BU discussion does not happen on the more core-centric venues. I'm just trying to dispel a lot of the falsehoods told here about BU and the intent of its proponents.

To all Bitcoin Unlimited supporters, I am not against larger blocks.

Good. That's a starting point for a dialogue.

Quote
My thought is reformulate your protocol to have some where between 2 - 8MB block size limit increasing with the Nielsen Law of bandwidth increase (slower exponential growth than Moore's law).

But BU has a block limit. The difference here is that it is adjusted in an ongoing manner by a community process. If 2 or 8MB is the proper value at one point in time, then that will be the limit. If we go with some other fixed value, we'll just be fighting this battle again in no time, with all the wasted friction, animosity, and market turmoil that it entails.

I realize there are skeptics that scoff at the emergent consensus idea, but there is science behind this concept. Granted, its application to this field is novel. At least as surfaced in this manner. But in the end, each party has the ability to change the blocksize they'll accept anyhow, by a localized change to source and recompiling. We are just making it easier for the user to make this change on the fly.

From my perspective, no. You are not going to convince me to abandon the scalable blocksize vision. With the caveat that I'm still thinking about your previous post.

I detect no deviation in the BU community at large from this principle either. Especially as -- after over a year of hard effort -- the tide seems to be turning in our direction.

Quote
Also you must adopt some of the bug fixes in SegWit, such as the new opcode which fixes malleability and enables Lightning Networks.

By and large, there is no effort against adoption of segwit (the targeted feature in isolation - not the bundle of cruft which is The SegWit Omnibus Changeset) within the BU community. We recognize that malleability is something that is worthy of addressing. However, it is really a tertiary concern. For all the heat and light, I have yet to be shown that malleability has actually caused any systemic failure. Or significant value loss. The restriction of ~250,000 transactions per day, on the other hand, is a systemic problem that needs fixing RFN.

So yes, let us fix malleability. Once we are past this tps barrier. If my read of the BU community is correct, segwit (likely without the centrally-planned magic number signature discount) is a contender for this fix. There is a conversation comparing and contrasting with (e.g.) FlexTrans that first needs to happen though.

Quote
But do not adopt all the rest of the complexity of SegWit, including do not adopt the ability to softfork version changes as that hands too much power to Core.

Agreed. Note that the feature of which you speak is _not_ the actual segwit feature, but what I refer to above as part of 'the bundle of cruft which is The SegWit Omnibus Changeset'. I don't believe that the majority of the BU community supports this either.

Quote
Go do that, then maybe you can win. Because likely users will end up choosing to support your protocol because their transactions are not being delayed. But you need to build confidence in your competence to lead.

You can possibly win, if you get competent people working with you.

You are apparently competing against banksters who are funding the Core developers (paying their large salaries and incentives). Perhaps that may explain why you ostensibly can't attract the most competent developers?

(I've taken the liberty reorder a couple of your paragraphs)

For the most part, the BU community realizes that our dev workforce is not comparable to core's. We have no illusions on this point. The fact that the most significant core devs are highly paid is likely a factor, but probably not the only factor. Personally, I think a very large factor is that devs naturally want to work on the market-leading implementation of a given idea. Up until recently, that has unambiguously meant core. However, from my perspective, there has been a recent swing in the thought-space towards BU. If indeed BU can wrest the market share title, I would expect a commensurate movement of devs from core to BU. Of course there will be attrition, but we don't need many to double or quadruple our dev bandwidth.

(One other factor would be untruths repeated far and wide about features, capabilities, and even motivations of BU - some intentional and some merely repetition of falsehoods. But getting into shouting matches over this would be unproductive)

Yes, there have been bugs. Fortunately, none have caused persistent or systemic issues. And likely, more will be found. (Of course, more will likely be found within core as well). But a mediocre implementation of the right design is infinitely more valuable than a nearly-perfect implementation of the wrong design. For the former will asymptotically approach the ideal, while the latter will always be targeting off in the wrong direction. We expect BU will be that goodness.

Quote
But you need to rein in these talking heads who are not sufficiently competent, i.e. Wu and Ver. They can talk when they cite competent developers. Those guys need to understand the limits of their role and competencies.

Look. This narrative really ought to stop. Neither Ver nor Wu have any official relation to the BU community. Are they visible BU community members speaking their minds? Yes - but only in their personal capacities. The idea that they are somehow official thought leaders in the BU community is merely a false redditism. Neither of them were responsible for brainstorming nor initiating BU, and neither of them participate regularly in discussions in the primary BU venue.

Quote
I am not against what you want in terms of fixing the block size problem. I am just being pragmatic. Find a confidence building and realistic way to win. I don't like being on the losing side.

I highly advise that you all back down from your current ultimatum and reformulate and get the token holders on your side before you proceed.

Backing down is unlikely at this point. I'm certainly not.

The majority of Bitcoiners are likely unsure or ambivalent of a choice between core and BU. There is a hard core minority and a hard BU minority. I don't know the proportions, but BU seems ascendant at this moment.

No discussion of sentiment would be complete without mention of the intentional manipulation of the dialogue. While this has recently lifted to a large degree, it is undeniable that the discussion in this and other venues has been steered to marginalize BU. Accordingly, many BU supporters have left these controlled venues for others. As a consequence, core supporters -- whether out of ignorance or out of malice -- have had free reign to poison the discussion by parroting untruths re: BU. This has two consequences: 1) the actual number of BU supporters is likely larger than you perceive; and 2) this number is likely to grow as misconceptions are corrected.

Quote
You really need a more capable leader than Wu or Ver. But don't enlist me, because I am too busy on my own "shitcoin" project and I am not interested in investing my effort in Satoshi's PoW. It is good to have those guys on your side, but not as the outspoken de facto leaders, because they have by now proven they are rash, irrational, and somewhat technologically incompetent.

Again. Neither Ver nor Wu are in any way central to the BU project. They are merely passionate supporters much like myself. They just have bigger megaphones than I due to their stature in other Bitcoin areas.

And yes - I would like to see you devote more time to your alt. While I am skeptical, not having seen your paper -- and despite our occasional inability to see eye-to-eye in the past -- I respect your intellect. Someone will make the next breakthrough in cryptocurrencies. It might be you? I have no way to judge currently, but I would not find it inconceivable.

Anyone with a campaign ad in their signature -- for an organization with which they are not otherwise affiliated -- is automatically deducted credibility points.

I've been convicted of heresy. Convicted by a mere known extortionist. Read my Trust for details.
krile
Hero Member
*****
Offline Offline

Activity: 746
Merit: 500



View Profile
March 21, 2017, 07:17:49 PM
 #127

The biggest problem in all this is that both solutions are somewhat shitty in their feature set.

Why are we at a point where only two solutions exist? The good thing about signaling is you could signal multiple options, within one "dev camp"/bitcoin client.

Core should give more options for example:
- SegWit + no block increase
- SegWit + block increase to 2MB
- NO SegWit + increase to 2MB
- xxx some other option

That way the network would decide and the Core team would not damage their reputation by "forcing" SegWit as the only option.

I still consider Core the most competent of taking care of the code, but I can't get my head around this, why not provide an alternative option to signal...

The problem with only two solutions is that one usually gets picked, even if both are bad.

(I am not counting the 8MB solution as an option since its just lazy and too extreme Smiley )

Edit: I read through the whole thread, good reading Smiley

infofront
Legendary
*
Offline Offline

Activity: 2660
Merit: 2866


Shitcoin Minimalist


View Profile
March 21, 2017, 07:31:37 PM
 #128

The biggest problem in all this is that both solutions are somewhat shitty in their feature set.

Why are we at a point where only two solutions exist? The good thing about signaling is you could signal multiple options, within one "dev camp"/bitcoin client.

Core should give more options for example:
- SegWit + no block increase
- SegWit + block increase to 2MB
- NO SegWit + increase to 2MB
- xxx some other option

That way the network would decide and the Core team would not damage their reputation by "forcing" SegWit as the only option.

I still consider Core the most competent of taking care of the code, but I can't get my head around this, why not provide an alternative option to signal...

The problem with only two solutions is that one usually gets picked, even if both are bad.

(I am not counting the 8MB solution as an option since its just lazy and too extreme Smiley )

Edit: I read through the whole thread, good reading Smiley

That's perhaps the biggest problem many people have with Core. It's their way or the highway. There have been lots of meetings, conventions, and dialogues of all sorts where they pretended to negotiate. It soon became clear that the negotiations were just stalling tactics, and they haven't given an inch to anyone, nor did they ever intend to.

I agree that they're probably the most competent code caretakers, but they're absolutely terrible at management and community relations.
krile
Hero Member
*****
Offline Offline

Activity: 746
Merit: 500



View Profile
March 21, 2017, 07:51:03 PM
 #129

The biggest problem in all this is that both solutions are somewhat shitty in their feature set.

Why are we at a point where only two solutions exist? The good thing about signaling is you could signal multiple options, within one "dev camp"/bitcoin client.

Core should give more options for example:
- SegWit + no block increase
- SegWit + block increase to 2MB
- NO SegWit + increase to 2MB
- xxx some other option

That way the network would decide and the Core team would not damage their reputation by "forcing" SegWit as the only option.

I still consider Core the most competent of taking care of the code, but I can't get my head around this, why not provide an alternative option to signal...

The problem with only two solutions is that one usually gets picked, even if both are bad.

(I am not counting the 8MB solution as an option since its just lazy and too extreme Smiley )

Edit: I read through the whole thread, good reading Smiley

That's perhaps the biggest problem many people have with Core. It's their way or the highway. There have been lots of meetings, conventions, and dialogues of all sorts where they pretended to negotiate. It soon became clear that the negotiations were just stalling tactics, and they haven't given an inch to anyone, nor did they ever intend to.

I agree that they're probably the most competent code caretakers, but they're absolutely terrible at management and community relations.

Seems there is another option missing in all this.

A good idea right now would be for some competent developer(s) to fork the core code (leave everything as it is) and insert another signaling option (2MB blocks for example or whatever). And keep it up to date with the core branch for any security patches not related to the scaling stuff. And still call the version BitcoinCore, just with SegWit + "xy signaling option(s)".

If the change gets voted on, core can still continue maintaining the code.

One of the reasons I dislike BU as much as I do, is not so much the actual block size implementation solution, but more about the rest of the stuff that might be buggy in the BU client.

The network needs more (reasonable - not so extreme - small step change - well maintained client) choices.

Miz4r
Legendary
*
Offline Offline

Activity: 1246
Merit: 1000


View Profile
March 21, 2017, 07:59:04 PM
 #130

Problem is Core is a diverse bunch of people without leadership, that is kinda what it means to be decentralized. They code and review and test, but they don't have someone pulling the strings or someone who can speak for the entire team. I'm sure other options have been reviewed within their team, but SegWit was found to be the best option for the moment as the other options would all require a hard fork and that would take more time to properly prepare for. Also at this point I don't think we'll be able to find a wide consensus for SegWit + 2MB hard fork, which is what some seem to prefer here. As SegWit already provides 2MB blocks, would the extra 2MB really be worth the trouble to do a hard fork for? I believe Core would like to prepare a much better hard fork later on to increase the blocksize limit together with other things that are on the hard fork wishlist. But I don't know, maybe you should try asking them if you're curious? Like nicely? The answer may be more technical than my explanation above though.

Bitcoin = Gold on steroids
krile
Hero Member
*****
Offline Offline

Activity: 746
Merit: 500



View Profile
March 21, 2017, 08:08:13 PM
 #131

A good idea right now would be for some competent developer(s) to fork the core code (leave everything as it is) and insert another signaling option (2MB blocks for example or whatever). And keep it up to date with the core branch for any security patches not related to the scaling stuff. And still call the version BitcoinCore, just with SegWit + "xy signaling option(s)".

Well I found one: https://bitcoinec.info/ Smiley

iamnotback
Sr. Member
****
Offline Offline

Activity: 336
Merit: 265



View Profile
March 21, 2017, 08:35:35 PM
Last edit: March 21, 2017, 08:52:25 PM by iamnotback
 #132

This is very rushed because it is 4am, I haven't slept yet, and I have a serious health issue. Thus this may not be carefully worded nor well thought out...

But BU has a block limit. The difference here is that it is adjusted in an ongoing manner by a community process.

It is controlled by hashrate voting per your FAQ. Look I don't want to get into another long debate, but BU does not have a protocol limit on block size and the optimal mining strategies will come into play by secret selfish mining colluding hashrate (driven by economic opportunity cost of not colluding), which afaics your models don't fully take into account.

I realize there are skeptics that scoff at the emergent consensus idea, but there is science behind this concept.

Your researchers are ostensibly not well peer reviewed. I already I think demonstrated that upthread. I don't have time to peer review Andrew Stone's whitepaper also, because you are not paying me and from my perspective, I have more important work to do.

From my perspective, no. You are not going to convince me to abandon the scalable blocksize vision. With the caveat that I'm still thinking about your previous post.

I detect no deviation in the BU community at large from this principle either. Especially as -- after over a year of hard effort -- the tide seems to be turning in our direction.

Unfortunately Satoshi's design is fundamentally centralized and there is nothing you nor Core can do to fix that. That is why your idealistic vision has to be myopic, otherwise you'd give up. I gave up already and let Core have the centralization and started to work on a replacement. Analogous to I wish Trump would give up already on the dysfunctional protectionism and let China eat the dying Industrial Age.

It seems y'all think you are going to achieve some decentralization, but IMO you're deceiving yourself... but to paraphrase Satoshi's rebuff of Daniel Larimer, "I don't have time to convince you...".

Not trying to be condescending though and respectfully I apologize I can't put enough effort into this to engage on every last detail needed to make you depressed and give up.  Tongue

I tried to suggest a K.I.S.S. compromise as reasonable middle-of-the-road scaling interim measure for the next few years while we prepare a suitable replacement for Bitcoin. But my perspective (which drives my priorities for Bitcoin, see below) is way too far out-of-the-box, so I don't bother to try to convince anyone right now about vaporware. Just do what ever you want. I am hedged.

On the protocol side, bitcoin got just more decentralized with the fight between classic, Core and BU, because it wasn't and there was leadership, but there isn't much any more, which is good.

The ability of miners to 51% attack the protocol is not decentralization. To paraphase Benjamin Franklin in our context, those who would trade a huge loss of decentralization in the functioning of the protocol for a tiny morsel of decentralization attacking the protocol immutability, deserve neither decentralization nor protocol adaptability.

The root problem is that Satoshi's design isn't sufficiently adaptable without centralized control.



We recognize that malleability is something that is worthy of addressing. However, it is really a tertiary concern. For all the heat and light, I have yet to be shown that malleability has actually caused any systemic failure. Or significant value loss. The restriction of ~250,000 transactions per day, on the other hand, is a systemic problem that needs fixing RFN.

So yes, let us fix malleability. Once we are past this tps barrier. If my read of the BU community is correct, segwit (likely without the centrally-planned magic number signature discount) is a contender for this fix. There is a conversation comparing and contrasting with (e.g.) FlexTrans that first needs to happen though.

Lightning Networks isn't a priority, even if for the confidence building value of at least deluding ourselves into thinking instant transactions are coming soon?

Ethereum is preparing to launch a beta of a LN clone Raiden. Python code.  Undecided

(I don't have enough time to study that code)

I suspect LN will lead to centralization and bad things, but is there really any other option within the current design?

Of course there will be attrition, but we don't need many to double or quadruple our dev bandwidth.

My priority need from Bitcoin right now is for it to not blowup while the experimentation to find real solutions is ongoing in the altcoin arena. Ditto I guess for most of the SegWit Takeover Omnibus thing...(a simple blocksize increase would have been sufficient and Core is probably lying!)

For me you are treating Bitcoin like an altcoin. I say you go make your own BTU fork which is what you are really doing.

You can't just say you will gradually build up competency to be BTC. In that case, you are an altcoin.

IMHO, you really can't have it both ways. But you can try and find out the hard way.  Wink

Look. This narrative really ought to stop. Neither Ver nor Wu have any official relation to the BU community.

Reality is that as long as your have de facto spokesman that make your fork look like another RogerCoin (e.g. Dash), then many in the community are going to view the affiliation that way.

You can reprimand me, but IMO it doesn't rectify what I believe to be the confidence problem. Fooling n00bs via simplistic incorrect technical summaries is altcoin marketing strategy.

Sorry not trying to be a pita, so I'll try to STFU now.
iamnotback
Sr. Member
****
Offline Offline

Activity: 336
Merit: 265



View Profile
March 21, 2017, 08:55:20 PM
Last edit: March 21, 2017, 09:09:39 PM by iamnotback
 #133

Problem is Core is a diverse bunch of people without leadership, that is kinda what it means to be decentralized. They code and review and test, but they don't have someone pulling the strings or someone who can speak for the entire team. I'm sure other options have been reviewed within their team, but SegWit was found to be the best option for the moment as the other options would all require a hard fork and that would take more time to properly prepare for. Also at this point I don't think we'll be able to find a wide consensus for SegWit + 2MB hard fork, which is what some seem to prefer here. As SegWit already provides 2MB blocks, would the extra 2MB really be worth the trouble to do a hard fork for? I believe Core would like to prepare a much better hard fork later on to increase the blocksize limit together with other things that are on the hard fork wishlist. But I don't know, maybe you should try asking them if you're curious? Like nicely? The answer may be more technical than my explanation above though.

I intuitively expect Core masterfully justified the necessity of their takeover (as funded by the banksters). The influential leaders can influence the flock of followers.

But I don't have time to go argue that. But I bet you I could.  Wink

So now both BU and Core hate me. Perfect.  Tongue

I also expect you have factions who are fighting to have the control over the centralization inherent in PoW. I expect there are powerful entities behind BU (and Core) that the useful idiots aren't aware of it.

I am not saying this because of being in love with conspiracy theory. It is because I know as a technical fact that PoW can't be decentralized. So I expect it to be factions fighting over the control.

And so now all you hate me. Sorry. Nevertheless I continue to think Bitcoin is important and must be protected for as long as we can. But I also accept the Invisible Hand is in control.
Killerpotleaf
Sr. Member
****
Offline Offline

Activity: 812
Merit: 250


A Blockchain Mobile Operator With Token Rewards


View Profile
March 21, 2017, 09:16:07 PM
 #134

the war debate continues to escalate, since on one is an a position of absolute power. the power struggle is complex and very real due to bitcoin's decentralized nature.

meanwhile...
"Satoshi's design is fundamentally centralized"

lol.

              ███
             █████
            ███████
           █████████
          ███████████
         █████████████
        ███████ ███████
       ███████   ███████
      ███████     ███████
     ███████       ███████
    ███████         ███████
   ███████           ███████
  ███████             ███████
 █████████████████████████████
███████████████████████████████
.
M!RACLE TELE
BRINGING MAGIC
TO THE TELECOM INDUSTRY

██
██
██
██
██
██
██
██
██
██
40% Biweekly Rewards
▬▬▬   Calls at €0.2   ▬▬▬
Traffic from €0.01 worldwide

██
██
██
██
██
██
██
██
██
██
      ██         ██     
        ▀▌     ▐▀       
       ▄██▄▄▄▄▄██▄      
     ▄█████████████     
   ▄█████████████████▄   
  ██████▄██████▄██████  
 ▐█████████████████████▌
  ██████▀███████▀██████ 
  █████   █████   █████  
  █████████████████████  
  █████████████████    
    ███████████████    
 ▀██▄ ████████████  ▄██▀
      ▀██▀   ▀██▀   
       ▄█       █▄
ANN
Lightpaper
Bounty
Facebook
Twitter
Telegram
Killerpotleaf
Sr. Member
****
Offline Offline

Activity: 812
Merit: 250


A Blockchain Mobile Operator With Token Rewards


View Profile
March 21, 2017, 09:18:17 PM
 #135

iamnotback
do let us know when your vaporware is ready to go, its always fascinating to learn about a new type of crypto

              ███
             █████
            ███████
           █████████
          ███████████
         █████████████
        ███████ ███████
       ███████   ███████
      ███████     ███████
     ███████       ███████
    ███████         ███████
   ███████           ███████
  ███████             ███████
 █████████████████████████████
███████████████████████████████
.
M!RACLE TELE
BRINGING MAGIC
TO THE TELECOM INDUSTRY

██
██
██
██
██
██
██
██
██
██
40% Biweekly Rewards
▬▬▬   Calls at €0.2   ▬▬▬
Traffic from €0.01 worldwide

██
██
██
██
██
██
██
██
██
██
      ██         ██     
        ▀▌     ▐▀       
       ▄██▄▄▄▄▄██▄      
     ▄█████████████     
   ▄█████████████████▄   
  ██████▄██████▄██████  
 ▐█████████████████████▌
  ██████▀███████▀██████ 
  █████   █████   █████  
  █████████████████████  
  █████████████████    
    ███████████████    
 ▀██▄ ████████████  ▄██▀
      ▀██▀   ▀██▀   
       ▄█       █▄
ANN
Lightpaper
Bounty
Facebook
Twitter
Telegram
lowbander80
Legendary
*
Offline Offline

Activity: 1036
Merit: 1000


View Profile
March 21, 2017, 09:32:56 PM
 #136

Not going into the ins and outs of the arguments but there is one certainty Bitcoin will hard fork shortly and what will happen to your stored bitcoins is anybodys guess.If we finish with two chains could one run zero protocol?could be a good time to integrate it
spiderbrain
Legendary
*
Offline Offline

Activity: 889
Merit: 1013



View Profile
March 21, 2017, 10:30:21 PM
 #137

I am not saying this because of being in love with conspiracy theory. It is because I know as a technical fact that PoW can't be decentralized. So I expect it to be factions fighting over the control.

And so now all you hate me. Sorry. Nevertheless I continue to think Bitcoin is important and must be protected for as long as we can. But I also accept the Invisible Hand is in control.

No hate from me. Crypto needs bitcoin as the poster boy first mover, but I think it's going to get eaten by the financial establishment. Same goes for ethereum, by the looks of things. Good luck to anyone trying to make something robustly decentralised!

Miz4r
Legendary
*
Offline Offline

Activity: 1246
Merit: 1000


View Profile
March 21, 2017, 11:24:37 PM
 #138

I intuitively expect Core masterfully justified the necessity of their takeover (as funded by the banksters). The influential leaders can influence the flock of followers.

But I don't have time to go argue that. But I bet you I could.  Wink

So now both BU and Core hate me. Perfect.  Tongue

Yes sounds perfect and convenient for someone who is trying to create a new altcoin to compete with Bitcoin. Obviously it would hurt your cause to say anything else. At the same time you need Bitcoin to stay big and healthy as it's the heart that pumps blood into all the other altcoins, including yours if your own idea ever comes off the ground. Which I have my doubts about because if I remember correctly you've been writing about creating something that's better than Bitcoin and any other altcoin for many years now. You are Anonymint are you not?

Quote
I also expect you have factions who are fighting to have the control over the centralization inherent in PoW. I expect there are powerful entities behind BU (and Core) that the useful idiots aren't aware of it.

I am not saying this because of being in love with conspiracy theory. It is because I know as a technical fact that PoW can't be decentralized. So I expect it to be factions fighting over the control.

And so now all you hate me. Sorry. Nevertheless I continue to think Bitcoin is important and must be protected for as long as we can. But I also accept the Invisible Hand is in control.

I don't hate you. I appreciate your writings although I am taking them with a grain of salt. I will agree that 100% decentralization is impossible, and right now mining is surely the opposite of decentralized. Core isn't perfect either, but at least it's way better than giving more power to that which is most centralized right now in Bitcoin, which is mining. Mike Hearn who left Core and Bitcoin earlier to work for the banks had some crazy ideas which would have been disastrous for fungibility and the censorship resistant properties of BTC, but his ideas did not become reality because other Core members and the community spoke against it. So I think we have sufficient defense mechanisms built in to ensure corrupt Core members do not screw up Bitcoin. Now we're going to see whether we also have sufficient defense mechanisms against the miners screwing up Bitcoin. I think we do.

Bitcoin = Gold on steroids
iamnotback
Sr. Member
****
Offline Offline

Activity: 336
Merit: 265



View Profile
March 21, 2017, 11:35:02 PM
 #139

the war debate continues to escalate, since on one is an a position of absolute power. the power struggle is complex and very real due to bitcoin's decentralized nature.

meanwhile...
"Satoshi's design is fundamentally centralized"

lol.

My thought is the power struggle wouldn't exist if Bitcoin was decentralized.

I presume BU supporters think that their protocol will make the block size issue decentralized, but I think they are deceiving themselves. But I am not going to argue that point further to the extent of needing to write about Andrew's white paper and detailed discussions and tangents that would ensue.

And it doesn't matter any way whether I convince anyone.

Thanks for the encouragement. I don't want an undeserved appreciation. I haven't done anything worthy yet. My remarks were not intended to foster animosity.
mining1
Hero Member
*****
Offline Offline

Activity: 532
Merit: 500


View Profile
March 22, 2017, 12:04:07 AM
 #140

But BTC could be decentralized. Unfortunately satoshi/team released it flawed.
Pages: « 1 2 3 4 5 6 [7] 8 9 10 11 12 »  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!