Pages:
Author

Topic: Decentralisation is harder than you think (Read 740 times)

hero member
Activity: 1071
Merit: 500
February 10, 2019, 04:38:50 PM
#67
Although the establishment of a system based on decentralization is more difficult, there are many benefits to users. Therefore, I believe that an effective campain has been carried out in order to neutralize or discredit our decentralized system. But I think all of this will fail and people will turn to decentralized systems for their own benefit.
copper member
Activity: 658
Merit: 402
February 10, 2019, 10:29:16 AM
#66
While reading articles there were two paragraphs that questioned me

Quote
Proof of work was only ever a way to take central control out of the Bitcoin system. But decentralisation is hard – centralisation is always more efficient. So decentralisation failed by 2014, when mining had recentralised to a few large pools. Remember the 51% apocalypse in 2014?

Bitmain has controlled up to 50% of the mining (across multiple pools), makes 80% of the ASICs, and already messed with the BTC hash rate in late 2017. Nobody cared much at the time, because the crypto bubble was in the throes of full “number go up” on the exchanges.

The point of cryptocurrency was decentralisation. If you remove that, the only question left is “why on earth are you bothering with all of this.”

(There’s arguably a hypothetical use case for a centrally-administered blockchain-like currency, such as XRP, which then doesn’t have to bother with proof of work. In that case, we’re still waiting for non-hypothetical production systems that move beyond pilot stage.)
https://www.theblockcrypto.com/2019/01/31/the-buttcoin-standard-the-problem-with-bitcoin/

Quote
It turns out that crypto communities make a lot of noise about the value of decentralization, but when you look under the covers, the entire coin comes down to a very small number of participants. For instance, Bitcoin’s blockchain is constructed by 19 mining entities, that’s it. Ethereum’s blockchain is constructed by 11. These are tiny numbers. While it’s true that each and every one of these mining entities consists of multiple sub-players, the fact is that they have come together under a unified entity and are operating together as one big business unit. There is a narrative that mining pools are internally decentralized, that there is invisible decentralization in these systems.


That argument turns out to be complete bunk. It’s like the emperor’s new clothes: they claim that there is something there that no one can see or measure or touch. The bottom line is participants in a mining pool are typically in no position to question what a pool operator is doing. They are in no position to detect when a pool operator launches an attack. So this narrative that these entities are internally decentralized doesn’t hold water. They might not be incorporated, but they are very much one group of people operating for a common cause.
https://www.longhash.com/news/interview-with-emin-gun-sirer-there-are-no-truly-decentralized-coins

Sure centralization is easier that decentralization but does it mean it's impossible? Hell no, I am confident we can still build something decentralized, we can't be perfect within a decade, that's something taking a lot of more years.

I am interested in a debate with people on this subject and the author's opinion

Let's admit that decentralization is quite harder and complicated. There's always pros and cons about centralized and decentralized. We're just used of centralization in our society. Maybe in the future and if the public adopts decentalized system, we'll get use of it too. There's always a room for improvement though.
legendary
Activity: 4410
Merit: 4766
February 09, 2019, 05:56:30 PM
#65
at what point would there ever be 100% agreement on a change? how would you ever be able to measure that? you're trying to confuse things with loaded and political terms. please try and stick to discussing what nodes are actually doing.

let's take segwit as an example.

by running my legacy node in 2017, i opted into to the consensus---i agreed to the current set of consensus rules. when segwit happened, my legacy node retained consensus with all segwit nodes. there was no chain split. therefore, segwit never violated the consensus that i agreed to. that consensus still exists today and i am still opted into it.

with a hard fork, that consensus would be broken by definition. hard forked nodes would be ignored by my legacy node because the two disagree about what the consensus rules are.

as for the whole 'backward compatibility' where older nodes get a stripped out data thats not fit for the full relay layer, and thus forms an underclass of downstream/filtered nodes. yes thats a soft fork as no one is dictatorially thrown off the network. but activating a new ruleset by excluding a certain class from a vote before the ruleset is even activated is not consensus. its a controversial softfork

your position on "downstream/filtered nodes" obviously disagrees with the design as satoshi wrote it:

The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.  The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate.  It's just an equation that evaluates to true or false.  Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script.  Currently, receivers only accept two templates: direct payment and bitcoin address.  Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them.  All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.

1. yes never 100%. but i was addressing your comment about 100%.. just to correct you that if in YOUR scenario of 100% that there would be no fork. but instead just an united upgrade.
i then went on, passed your limited scope.. and i digressed to show the other parameters of majority(under 100%) and then controversial(less than majority).. it was not me that was highlighting just a 100% agreement. that was you.. like i said i went and explained the multiple levels of what happens when less and less agree and i also described how things play are when nodes are thrown out before consensus(to fake a vote)
...
but in short segwit only got 35% in spring 2017 and so instead of going back to the drawing board with a new option of a varient feature. they doubled down and really pushed for their segwit1x controversially

2. what you dont realise is that downstream/filtered nodes are not just skipping transaction full verification and just saying they pass a minimal test.. these nodes are actually being handed stripped data. which if they were part of the relay layer, the main relay layer nodes would reject the blocks. so its not true compatibility. its just fake compatibility t keep an underclass online but without voting rights (you might want to look into it.. ) the block data 'compatible' nodes get is not the same data full nodes get.
presuming 'compatible nodes' are true full relay nodes and have same vote rights is a flaw in your understanding of the relay network.

3. also before the segwit new ruleset even activated there was a controversial biased fork. some devs called it a bilateral split, amungst many names, but the devs do not deny that a controversial non consensus hardfork occured to push opposition off the network to then get a faked approval vote to get segwit1x activated.
there was no "honest consensus" / "honest node" event around how segwit1x got activated.

some people really need to do some research.. or atleast before trying to deny events happen. atleast speak to devs and realise devs do not need to be defended by lying and saying events didnt happen if said devs are happy to admit their own actions/involvement.
i see no reason for you to pretend things didnt happen. as it defends no one. and also blockdata which is immutible can prove you wrong, let alone quotes from devs themselves. so i wonder what are your motives for continuing the echo chamber of mythical nonsense that a certain group of of people want to continue pushing...

... as the only motive for such i can see is that certain echo chamber group. do NOT care for bitcoin. but only care for keeping bitcoin stifled to then promote another network(LN) where the echo chamber can only hope to become factory/watchtower nodes to be greedy income earnrs.. which if you play out scenario's of LN the echo chamber would soon learn they they wont get to be the hubs of get rich quick. as it will end up being the custodial services of the DCG portfolio that will be the big income earners.. all at the expense of making peer-to-peer self control a thing of the past, while the aim is to push the community into counterparty controlled, banking system which is not community/blockchain confirmed/validated. but instead co-custodian managed and manipulatable. thus killing off the whole point of bitcoin by making bitcoin too expensive and also too small utility to be useful
legendary
Activity: 1652
Merit: 1483
February 09, 2019, 04:47:29 PM
#64
the idea of getting consensus to change a protocol like bitcoin is insane. there's millions of users. there's no way 100% of users would ever agree to a hard fork, except maybe in the narrow case where the protocol is under existential threat from a bug (like if ECDSA were broken).

that's one of the strengths of soft forks. if backed by majority hashpower, they are compatible with the prior consensus. if consensus is never broken, you don't need 100% of users to agree to a fork. everyone can co-exist with backward compatible software.
you been sniffing too much of the echo chamber mantra.

if there was 100% agreement. there would be no soft/hardfork. as everyone would be in agreement. thus they all follow the new rule, thus no fork.. just an upgrade

at what point would there ever be 100% agreement on a change? how would you ever be able to measure that? you're trying to confuse things with loaded and political terms. please try and stick to discussing what nodes are actually doing.

let's take segwit as an example.

by running my legacy node in 2017, i opted into to the consensus---i agreed to the current set of consensus rules. when segwit happened, my legacy node retained consensus with all segwit nodes. there was no chain split. therefore, segwit never violated the consensus that i agreed to. that consensus still exists today and i am still opted into it.

with a hard fork, that consensus would be broken by definition. hard forked nodes would be ignored by my legacy node because the two disagree about what the consensus rules are.

as for the whole 'backward compatibility' where older nodes get a stripped out data thats not fit for the full relay layer, and thus forms an underclass of downstream/filtered nodes. yes thats a soft fork as no one is dictatorially thrown off the network. but activating a new ruleset by excluding a certain class from a vote before the ruleset is even activated is not consensus. its a controversial softfork

your position on "downstream/filtered nodes" obviously disagrees with the design as satoshi wrote it:

The solution was script, which generalizes the problem so transacting parties can describe their transaction as a predicate that the node network evaluates.  The nodes only need to understand the transaction to the extent of evaluating whether the sender's conditions are met.

The script is actually a predicate.  It's just an equation that evaluates to true or false.  Predicate is a long and unfamiliar word so I called it script.

The receiver of a payment does a template match on the script.  Currently, receivers only accept two templates: direct payment and bitcoin address.  Future versions can add templates for more transaction types and nodes running that version or higher will be able to receive them.  All versions of nodes in the network can verify and process any new transactions into blocks, even though they may not know how to read them.
legendary
Activity: 4410
Merit: 4766
February 09, 2019, 04:25:52 PM
#63
I do know what is a consensus. But consensus doesn't work. Yes, it does if we are only 10 people, not difficult, but it can't work with everybody included. And it can also work if people are ready for some compromise.
Imagine a consensus in politic, do you really think it's possible? Hell no.

the idea of getting consensus to change a protocol like bitcoin is insane. there's millions of users. there's no way 100% of users would ever agree to a hard fork, except maybe in the narrow case where the protocol is under existential threat from a bug (like if ECDSA were broken).

that's one of the strengths of soft forks. if backed by majority hashpower, they are compatible with the prior consensus. if consensus is never broken, you don't need 100% of users to agree to a fork. everyone can co-exist with backward compatible software.
you been sniffing too much of the echo chamber mantra.

if there was 100% agreement. there would be no soft/hardfork. as everyone would be in agreement. thus they all follow the new rule, thus no fork.. just an upgrade

in a majority consensus(majority but not 100%) the minority wont be hard forked to a different network. they would just be stalled out. same network just not receiving new blocks/data(soft fork).
the minority then decide if they rejoin. or make their own network

in a controversial hardfork where nodes are banned off the network before activation and not due to activation. well thats dictatorship at play.
in a controversial hardfork where code is activated AND THEN nodes are banned/thrown off the network due to rule incompatibility. well if pools were in that group thrown off.. then a new network would occur(hard fork)

as for the whole 'backward compatibility' where older nodes get a stripped out data thats not fit for the full relay layer, and thus forms an underclass of downstream/filtered nodes. yes thats a soft fork as no one is dictatorially thrown off the network. but activating a new ruleset by excluding a certain class from a vote before the ruleset is even activated is not consensus. its a controversial softfork

core pulled of many tricks to get sgwit1x active.. they didnt and make a more community acceptable compromise when they seen they only had 35%. thy decided to get controversial and fake consensus
legendary
Activity: 4410
Merit: 4766
February 09, 2019, 03:59:30 PM
#62
I do know what is a consensus. But consensus doesn't work. Yes, it does if we are only 10 people, not difficult, but it can't work with everybody included. And it can also work if people are ready for some compromise.
Imagine a consensus in politic, do you really think it's possible? Hell no.

hell yes.
politics with consensus = democracy
politics without consensus = dictatorship

the only reason politics dictatorship is limited to one vote per 4-5 years is the fact that it takes people having to walk to a polling station per vote, which is lengthy to organise. yet things like america's got talent can achieve voting using technology more often than politics hense why americas got talent does voting every year.

with bitcoin where nodes are always online voting can happen even more rapidly. it just requires devs to not biased throw out certain classes from a vote and instead accept a vote didnt go their way(35%) and instead have them compromise and re try a new proposition, rather than dig deeper with thir proposals and get buddies to social drama other fake options to pander out the opposition and sway/threaten others to accept the dug deeper proposition.

but yea.. consensus can work, but has been bypassed so now consensus(byzantine generals problem) has been sidelined so absurdly that it has now made consensus 'broke' and core show no sign of wanting to go back to a consensus system of satoshis invention as they now control and dictate the rules.
Luke JR is super happy that he gets to do that as and when he likes without opposition now
legendary
Activity: 1652
Merit: 1483
February 09, 2019, 03:53:03 PM
#61
I do know what is a consensus. But consensus doesn't work. Yes, it does if we are only 10 people, not difficult, but it can't work with everybody included. And it can also work if people are ready for some compromise.
Imagine a consensus in politic, do you really think it's possible? Hell no.

the idea of getting consensus to change a protocol like bitcoin is insane. there's millions of users. there's no way 100% of users would ever agree to a hard fork, except maybe in the narrow case where the protocol is under existential threat from a bug (like if ECDSA were broken).

that's one of the strengths of soft forks. if backed by majority hashpower, they are compatible with the prior consensus. if consensus is never broken, you don't need 100% of users to agree to a fork. everyone can co-exist with backward compatible software.
copper member
Activity: 2940
Merit: 4101
Top Crypto Casino
February 09, 2019, 03:27:48 PM
#60
I do know what is a consensus. But consensus doesn't work. Yes, it does if we are only 10 people, not difficult, but it can't work with everybody included. And it can also work if people are ready for some compromise.
Imagine a consensus in politic, do you really think it's possible? Hell no.
legendary
Activity: 4410
Merit: 4766
February 06, 2019, 05:52:13 PM
#59
@frankky
Just throwing an idea

A society cannot function and evolve without leadership. Without rules, it becomes a mess and anarchy and we'd live like 500 years ago with no progress. A consensus between a few people is possible but a consensus with everyone is just impossible and it also implies notions of compromise

Bitcoin needs leadership to progress. Maybe Blockstream is just conservative, and not surprising when you see the soap opera. And I know that you're going to say about DCG, even if you're right about it it's a different point.

but the whole point of bitcoins invention/revolutionary technology is that satoshi solved the problem of allowing rules to be followed and new rules adopted by decentralised individuals without needing a central leader, without mandates and without throwing off the network to get new feature activation.

seems some people forgot what consensus is(or never learned it) and have instead become devoted to those that abused/bypassed consensus because they feel that bitcoin needs leadership.

all in attempt to remove diversity and decentralisation. just so they can get centralisation and distribution(which is different than decentralisation)

the whole revolutionary thing about bitcoin is the no need of leadership. but that got eroded down as of 2013 onwards to th point we are at now.

by saying things need a central leader is ignoring what the consensus mechanism of solving byzantine generals issue was all about..
X7
legendary
Activity: 1162
Merit: 1009
Let he who is without sin cast the first stone
February 06, 2019, 05:46:10 PM
#58
While reading articles there were two paragraphs that questioned me

Quote
Proof of work was only ever a way to take central control out of the Bitcoin system. But decentralisation is hard – centralisation is always more efficient. So decentralisation failed by 2014, when mining had recentralised to a few large pools. Remember the 51% apocalypse in 2014?

Bitmain has controlled up to 50% of the mining (across multiple pools), makes 80% of the ASICs, and already messed with the BTC hash rate in late 2017. Nobody cared much at the time, because the crypto bubble was in the throes of full “number go up” on the exchanges.

The point of cryptocurrency was decentralisation. If you remove that, the only question left is “why on earth are you bothering with all of this.”

(There’s arguably a hypothetical use case for a centrally-administered blockchain-like currency, such as XRP, which then doesn’t have to bother with proof of work. In that case, we’re still waiting for non-hypothetical production systems that move beyond pilot stage.)
https://www.theblockcrypto.com/2019/01/31/the-buttcoin-standard-the-problem-with-bitcoin/

Quote
It turns out that crypto communities make a lot of noise about the value of decentralization, but when you look under the covers, the entire coin comes down to a very small number of participants. For instance, Bitcoin’s blockchain is constructed by 19 mining entities, that’s it. Ethereum’s blockchain is constructed by 11. These are tiny numbers. While it’s true that each and every one of these mining entities consists of multiple sub-players, the fact is that they have come together under a unified entity and are operating together as one big business unit. There is a narrative that mining pools are internally decentralized, that there is invisible decentralization in these systems.


That argument turns out to be complete bunk. It’s like the emperor’s new clothes: they claim that there is something there that no one can see or measure or touch. The bottom line is participants in a mining pool are typically in no position to question what a pool operator is doing. They are in no position to detect when a pool operator launches an attack. So this narrative that these entities are internally decentralized doesn’t hold water. They might not be incorporated, but they are very much one group of people operating for a common cause.
https://www.longhash.com/news/interview-with-emin-gun-sirer-there-are-no-truly-decentralized-coins

Sure centralization is easier that decentralization but does it mean it's impossible? Hell no, I am confident we can still build something decentralized, we can't be perfect within a decade, that's something taking a lot of more years.

I am interested in a debate with people on this subject and the author's opinion


Maintaining decentralization while upholding strong security mechanisms is the tricky part, most people give up on the security for more tx throughput but like yourself I don't think we need to sacrifice one to achieve the other.

Just need to consider more 2nd layer solutions or create alternative systems which can encompass both, the solution will probably be based in math given that it is the universal language of truth.

copper member
Activity: 2940
Merit: 4101
Top Crypto Casino
February 06, 2019, 05:42:38 PM
#57
@frankky
Just throwing an idea

A society cannot function and evolve without leadership. Without rules, it becomes a mess and anarchy and we'd live like 500 years ago with no progress. A consensus between a few people is possible but a consensus with everyone is just impossible and it also implies notions of compromise

Bitcoin needs leadership to progress. Maybe Blockstream is just conservative, and not surprising when you see the soap opera. And I know that you're going to say about DCG, even if you're right about it it's a different point.

The social dramas you talk about are brought on the table by the forks
https://spectrum.ieee.org/tech-talk/computing/networks/the-bitcoin-for-is-a-coup
legendary
Activity: 4410
Merit: 4766
February 06, 2019, 02:51:27 PM
#56
^ doomad still has not learned consensus /byzantine generals issue. and still wants to pursue his mindset that core should control the network without community majority triggering the activations of new rules.
his viw is not of bitcoin as it was suppose to be 2009-2013.. but of the view of how bitcoin is now under control 2013-2019
which is the problem
he will continue to argue that bitcoin is now centralsied coded by one group, while then social dramatising (flip flopping) that its then not the case. meaning he is just wasting time with his flip flops..

though its clear what his deep down desire is.

foolish now to even keep talking to doomad as he will just continually perpetuate his belief that central control is what bitcoin was designed for, and will continue to ignore the whole consensus/byzantine generals thing that made bitcoin such a unique/innovative/revolutionary thing.

may doomad one day wake up to the purpose of blockchains.. or stay in his echo chamber of blockchains are useless... who knows. but no point trying to get him to do real research outside his echo chamber. as he seems too deep in it to even want to think independently

oh well
moving on
legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
February 06, 2019, 09:16:17 AM
#55
Show me where I said "after".  That word doesn't even appear in my post.  Users can disconnect other nodes at any time.  If you are disconnected before your proposed rule change activates, I'll repeat again that any funds you have on the network are still safely secured and you can rejoin the network at any time by simply following consensus rules again.  There is nothing incorrect about my statement.  My words do not solely relate to "AFTER activation".  If you can't understand that, it's your error, not mine.  Every time you say "flip flop" I say you fail at comprehending plain English.  That, or you're attempting to deliberately twist or distort what I'm saying.  It's hard to tell with you sometimes.

mr flip flop

if core want to change the rules.. and its core nodes that disconnect opposers. then its not the opposers that need to "rejoin by following the consensus rules again" because if your trying to twist your rhetoric to be about BEFORE activation.. then no rules have changed yet thus the opposers are and would be running the same rules.. OBVIOUSLY

It shouldn't be this difficult for it to sink in.  If users choose to enforce a rule that says bit 6 and bit 8 are no longer valid, that is a change in the rules.  It's immaterial if your proposed feature has or hasn't activated.


the only condition where opposers would need to change anything to "follow the rules" (as if they are not following the rules).. is if the rules have changed.. thus AFTER
so its obvious your rant was talking about AFTER because thats the only time an opposer wont be "following the rules"

Nodes began enforcing a consensus rule that meant nodes are disconnected for flagging invalid bits.  If you were flagging bit 6 or bit 8, then you were in breach of the rules nodes freely chose to enforce. 


...
getting to the point of before activation. WHERE RULES HAVE NOT CHANGED.

Rules did change.  Users ran code to enforce the change. 

No one cares what you believe the rules were. 
No one cares if you think they hadn't changed when they had.
No one cares if it was before, during or after proposed features in other clients activating.

Users ran the code and it happened.  But please keep achieving absolutely nothing by refusing to acknowledge events as they were, rather than how you would ideally want them to be and whining that it doesn't work how you think it should.  There is no flip flop, you simply can't accept reality.
legendary
Activity: 4410
Merit: 4766
February 05, 2019, 08:58:14 PM
#54
Show me where I said "after".  That word doesn't even appear in my post.  Users can disconnect other nodes at any time.  If you are disconnected before your proposed rule change activates, I'll repeat again that any funds you have on the network are still safely secured and you can rejoin the network at any time by simply following consensus rules again.  There is nothing incorrect about my statement.  My words do not solely relate to "AFTER activation".  If you can't understand that, it's your error, not mine.  Every time you say "flip flop" I say you fail at comprehending plain English.  That, or you're attempting to deliberately twist or distort what I'm saying.  It's hard to tell with you sometimes.

mr flip flop

if core want to change the rules.. and its core nodes that disconnect opposers. then its not the opposers that need to "rejoin by following the consensus rules again" because if your trying to twist your rhetoric to be about BEFORE activation.. then no rules have changed yet thus the opposers are and would be running the same rules.. OBVIOUSLY

the only condition where opposers would need to change anything to "follow the rules" (as if they are not following the rules).. is if the rules have changed.. thus AFTER
so its obvious your rant was talking about AFTER because thats the only time an opposer wont be "following the rules"

now...
getting to the point of before activation. WHERE RULES HAVE NOT CHANGED. if core are disconnecting nodes BEFORE cores bips activate then your nonsense about "rejoin by following rules" does not apply because the opposers were following the current rules, but were simply objecting and opposing cores FUTURE proposal
thus core nodes were not doing consensus. they were instead being contentious by throwing out nodes simply due to brand bias to fake approval by only having approval nodes left on the network, to get the bip activated.

you also rant about how you as a unique user have the free choice to disconnct whomever you like from your node. but as your link in an earlier post shows. it was not about unique users manually disconnecting nodes pre-vote deadline/pre activation. it was CODE that biasedly wanted to disconnect certain bitcoin node versions.
so you cant blame the users for manually disconnecting certain nodes. it was the devs who wrote code to automatically disconnect certain nodes, out of pure bias to ensure only segwit1x got activated.
and yes. core devs(blockstream devs more specifically) because of how FIBRE(mattblue) functions as the ringfense layer between mining pools and user nodes had the ultimate say in what data streams from pools to the majority of nodes
..
anyways, your obviously trying too hard to defend cores actions. so just keep it short and sweet. you love centralisation and you think the community should just sheep follow core or get thrown off the network

have a nice day
P.S you seem to be very emotional with all your insults. so i wonder what is behind your motives. why you are so hard nosed dedicated and devoted to wanting core centralisation.
let me guess.. youll flip flop about how consensus should not exist because now you believe that miners and users should not have a choice because that means that devs need others "permission" and your beliefs are that thre should be no permission..

to which ill tell you again.. learn true consensus

also if someone was to check post histories they would see that YOU are the one throwing out the majority of insults. but to address the concern you have about alternative clients being sheep. ill reword it to your buddies prefered buzzwords. seeing as you love their words
"compatible"
"downstream"
"filtered"
"outerlayer"
"not part of the peer-to peer relay layer"
"stripped"
"not quite full nodes"

You just have overly emotive appeals to childish notions of "why can't everyone just play nice together?" and other such "fluffy clouds and rainbows" nonsense.  Sorry, but the real world doesn't play nice.

this statement here proves you have no clue about satoshi's consensus solution to the byzantine generals issue. which made bitcoin so revolutionary

and why core bypassing it purely to gain dictatorship goes against the whole point of decentralisation..

.. but hey, your buddy groups echo chamber is that of wanting a commercial network that does not use a blockchain(LN). so i can see why you dont care to learn about why blockchains and byzantine generals issues and consensus, and why such are not important to you.

you might aswell just go play around on a LN forum and really show your admiration for it, as your wasting ur time on a bitcoin forum by showing your obvious lack of care and understanding of what made bitcoin bitcoin
member
Activity: 228
Merit: 10
February 05, 2019, 08:19:43 PM
#53
Decentralization is the key element of crypto currencies. Advancement in technology makes easier to implement decentralized system in many sector. Because it offers flexibility and speed when compared to former. Similarly, we are going to a financial sector which is decentralized and because only this way financial sector can fit into our age.
with a decentralized system, the data that we have or the currency we have will be safe, this will cause there will be no doubling of data that occurs, because all systems are interconnected, if there is one false or multiple data then it will be quickly detected by another server , the decentralized system will record all transaction data throughout the world starting from the first time the blockchain is created until now and in the future, so it is very safe.
legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
February 05, 2019, 02:20:21 PM
#52
^ more flip flops

here he goes again about thrown off the network AFTER activation.. yet he ignores the whole point of PUSHING people off the network BEFORE activation.

Show me where I said "after".  That word doesn't even appear in my post.  Users can disconnect other nodes at any time.  If you are disconnected before your proposed rule change activates, I'll repeat again that any funds you have on the network are still safely secured and you can rejoin the network at any time by simply following consensus rules again.  There is nothing incorrect about my statement.  My words do not solely relate to "AFTER activation".  If you can't understand that, it's your error, not mine.  Every time you say "flip flop" I say you fail at comprehending plain English.  That, or you're attempting to deliberately twist or distort what I'm saying.  It's hard to tell with you sometimes.

You don't have a point.  You just have overly emotive appeals to childish notions of "why can't everyone just play nice together?" and other such "fluffy clouds and rainbows" nonsense.  Sorry, but the real world doesn't play nice.  It's time for you to grow up and accept that life isn't fair and that not everyone thinks you deserve a medal just for taking part.  

Run the code you want to run.  If doing that puts you on another network, that's a "you" problem.  None of us owe you a solution to the part where you want something we clearly don't want.  Your freedom only extends to the point where you encroach on the freedom of others.  If you do that, you are free to leave.  


you can rejoin the network at any time by simply following consensus rules  

gotta love the warped mind he has
in essense... you can rejoin the network if you give up your objection and code your node to flag that you desire some feature activating.(meaning only option is to show agreement)

Oh wow, you're actually starting to get it.  YES FRANKY1, THAT'S HOW CONSENSUS WORKS.  USERS WHO AGREE WITH EACH OTHER BUILD A CHAIN TOGETHER ON THE SAME NETWORK.  INCOMPATIBLE CODE CAN BE FORKED OFF AT ANY TIME TO FORM A DIFFERENT NETWORK.  Took you long enough, but I'm glad we got there in the end.  Well done.  

It's not an altcoin until a fork occurs, but either side can reject the other at any time.  If you're going to run code that proposes an incompatible change, it should go without saying that you run the risk of other users being so vehemently opposed to your change that they may want to remove you from their network.  Consider it an occupational hazard.  Either those proposing the change can initiate a fork, or those who opposing the change can initiate the fork.  But no doubt you'll somehow fail to comprehend this and label it a flip flop as well, or tell me another made up reason why I need to research something, or just make some other weak deflection about social drama or whatever other catchphrases come to mind.  

To give an example to help you avoid your inevitable confusion, the client you are running proposes a change to the current consensus rules.  It runs on the BTC chain and currently enforces BTC consensus rules.  But it also contains incompatible code that has not been activated.  As such, it's an alternative client, not an altcoin.  One option is that users of your client could change the rules they enforce, enacting a fork, because the two rulesets would no longer agree with each other.  Another option (the one you don't like) is that users who are not running your client could change the rules they enforce, also enacting a fork, because the two rulesets would no longer agree with each other.  Alternatively, users of neither client change the rules they enforce and things remain as they currently do.  All three of these options are valid.  You do not have the right to rule any of them out.  

It's not viable to have a network where two diametrically opposed sides want to move in completely different directions.  What does it achieve to keep the two opposed sides on the same network, with neither side achieving anything?  We'd still be in a bitterly entrenched civil war, stuck in total deadlock if things hadn't unfolded how they did.  That's why it's far better for those who want raw throughput to do their thing on another chain while users on this chain focus on the things they want to implement.  Both sides get to move forward.  We then get to see which path works best.  Sometimes decentralisation can take the form of different chains trying different things.  If those other chains demonstrate success, we might adopt similar ideas on this chain later, who knows?  


so where is the consensus CHOICE to actually oppose a feature activation (imagine it being malicious code) if the only options are accept cores BIP or get thrown off BEFORE the bip even activates.

I honestly don't know how you can sit there and claim those are the only options when you are running a client that wasn't made by Core and hasn't been "thrown off".  You have a choice.  You've already made it.  How do you then pretend the choice you've made somehow isn't an option?  It's lunacy.  Other clients exist.  You clearly know that if you are running one.  Try being less dishonest.

Your problem, as I've explained to you time and time again, is that you need OTHER USERS to agree with the choice you've made.  If users agreed with you, they'd be running the same client as you.  Apparently, they don't agree with you.  Keep arguing whatever it is you're going to argue and I'll continue decimating it, but your client has hardly any users.  Nothing you can say will change this fact.  The stuff you want is categorically not what other users want.

Features only activate if users run them.  If code was malicious, users wouldn't run it, so it wouldn't activate.  How can you possibly fail to grasp this?  Stop pretending that the code users have run to disconnect incompatible clients is malicious just because you personally disagree with it.  


yes i know you will say "those enforcing the rules" but thats the issue... CORE are in command of such. and users are just distributed 'compatible' sheep of core because the CHOICE of brands(of full nodes that would allow opposition) has been removed

As always, your last resort is to insult the intelligence of everyone securing the BTC network.  Please keep calling them sheep.  Please keep telling us about your genuine and fervent belief that all the users on the BTC chain are too stupid to decide for themselves and are just blindly following what one dev team tell them to do.  Please keep telling us we're just mindless drones and how only your vivid fantasies (that aren't even remotely feasible to implement) will somehow save us from ourselves.  
legendary
Activity: 4410
Merit: 4766
February 05, 2019, 12:17:17 PM
#51
^ more flip flops

here he goes again about thrown off the network AFTER activation.. yet he ignores the whole point of PUSHING people off the network BEFORE activation.

consensus is about continually following ACTIVE rules. and then choosing what new features should become active..
the morals of pushing people off the network before a new feature choice is made. is NOT consensus.. its contentious

anyway ill let him flip flop for another year in his echo chamber. as its only wasting his time by him being stuck where he is.

you can rejoin the network at any time by simply following consensus rules  

gotta love the warped mind he has
in essense... you can rejoin the network if you give up your objection and code your node to flag that you desire some feature activating.(meaning only option is to show agreement)

.
The rules that are enforced mean that miners get to choose fee policy.  
 the code is 100% meaningless if those securing the chain don't agree with it.
so where is the consensus CHOICE to actually oppose a feature activation (imagine it being malicious code) if the only options are accept cores BIP or get thrown off BEFORE the bip even activates.

yes i know you will say "those enforcing the rules" but thats the issue... CORE are in command of such. and users are just distributed 'compatible' sheep of core because the CHOICE of brands(of full nodes that would allow opposition) has been removed
legendary
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
February 05, 2019, 12:11:35 PM
#50
devs should provide an option. and then users should decide.. WITHOUT FEAR of being thrown off the network purely for opposing an option.

It all sounds a bit dramatic, doesn't it?  "Thrown off the network".  Scary stuff.  Except any funds you have on the network are still safely secured and you can rejoin the network at any time by simply following consensus rules again.  You can follow multiple chains each with their own consensus rules if you desire.  But you don't get to tell me who I can or can't disconnect from my node.  I can disconnect anyone, at any time, for any reason I wish.  If your fear can't handle my right to do that, go play with fiat.


if an option does not get approval WITHOUT network throw off's.. so be it. that option simply does not activate. no harm no foul

And how will you enforce that?  Oh right.  You can't.  You can express your will in the code you run, but, to the best of my knowledge, no one has invented code that stops me disconnecting someone from my node.


devs dont even provide a VARIETY of options for users to choose. (its just a their road map or no other way)

Which client are you running again?  Devs gave you that client, didn't they?  You have your variety.  Why is that not enough for you?  Why do you believe devs are only here so that they can code every ludicrous idea you've ever had?  I doubt that's what they signed up for.  You are so far beyond entitled that it's laughable.


no one should be thrown off a network before the vote is complete

You can't enforce that.  All you have is "should", "should" and more "should".  Also, consensus is happening every second of every minute of every hour of every day.  It's not a "vote" you can "complete".  Consensus is happening right now.  It is embodied by the rules that are enforced on the BTC network right now by those securing the chain.  The rules that are enforced can involve clients being disconnected.  The rules that are enforced mean that miners get to choose fee policy.  The rules that are enforced do not include any of your whiny "should" talk.


again for the umpteenth time.. learn consensus
consensus is NOT throw people off the network to gain approval count
consensus is gain approval count(without throwing people off network) or it just doesnt activate if no majority is found

try to atleast learn consensus and why its a big deal in regards to how satoshis invention is so revolutionary. and how core bypassed it for thier own purposes

We heard you the first dozen times.  We know how you think consensus "should" work.  But the fact that it demonstrably doesn't work like that means you are the one you needs to learn it.  Consensus does mean you can be forked off.  Consensus does mean some users can implement ideas via softfork that you don't approve of.  Consensus does mean devs can code what they like and the code is 100% meaningless if those securing the chain don't agree with it.

None of your idealism and wishful thinking counters the crushing reality of how consensus actually works in the wild.  
legendary
Activity: 4410
Merit: 4766
February 04, 2019, 05:28:28 PM
#49
you would need to collude with a mining pool who can withhold certain transactions (losing bets) from the blockchain

problem is that even if a pool goes back and rehashes/re-orgs a block to exclude a losing bet..
that losing bet just becomes TEMPORARILY unconfirmed again.. and another pool will pick up that 'losing bet' thats suddenly become unconfirmed.. and reconfirm it into their block later

The attacker would obviously want to respend those outputs to addresses they control at the same time and try to confirm the double spends..

i see what your saying that pool C would
change:
block 600000 pool a: TX123 1poolcaddr 1btc->1gamblingsite 1btc
block 600001 pool b
to
block 600000 pool c:  TX123 1poolcaddr 1btc->1poolcaddr 1btc
block 600001 pool c
block 600002 pool c

which would prevent
block 600003 pool a: TX123 1poolcaddr 1btc->1gamblingsite 1btc
because tx123 is spent at 600000 back to 1poolcaddr


but if pool C gave up at 600002 and sat back and had a coffee thinking job done game over...
here is what can happen
block 600000 pool a: TX123 1poolcaddr 1btc->1gamblingsite 1btc
block 600001 pool b
block 600002 pool a
block 600003 pool a
thus pool A and B re-orged back to the original 600000 and then continued on their merry way as if poolC never occured

meaning that pool C would need to continue way way way passed 600002 just to ensure pools A and B didnt re-org back and reconfirm TX123 with the gambling site
legendary
Activity: 1666
Merit: 1196
STOP SNITCHIN'
February 04, 2019, 04:58:44 PM
#48
you would need to collude with a mining pool who can withhold certain transactions (losing bets) from the blockchain

problem is that even if a pool goes back and rehashes/re-orgs a block to exclude a losing bet..
that losing bet just becomes TEMPORARILY unconfirmed again.. and another pool will pick up that 'losing bet' thats suddenly become unconfirmed.. and reconfirm it into their block later

The attacker would obviously want to respend those outputs to addresses they control at the same time and try to confirm the double spends.

That's why the amount of hash rate an attacker controls matters so much. Just like selfish mining, the expected value is a matter of probability because Bitcoin's mining algorithm is based on a discrete probability distribution (a Poisson distribution). There's never a guarantee that any attack will work 100% of the time, but the important thing is that the higher an attacker's hash rate, the higher the chances of success. The bigger an entity is, the bigger their incentive to attack.
Pages:
Jump to: