Senor.Bla (OP)
|
|
March 05, 2017, 05:56:27 PM |
|
First of all thank you for a better explanation than i could come up with. I do have to miner questions i'm not sure about if i got it right. 1. Regarding step three. Can the node with the lowest consensus.h limit hold back/block the network by not upping the limit while still running? 2. Regarding the bilateral split. Why do the Node and the pool need to intentionally ban the others to become a small network of their own? I thought this happens automatically since they assume they have the longest legit chain.
1. if nodes and pools decide 95% of the network is the metric then it requires 5.01% of the network to hold up block growth with 5% possible orphan heaches. if 75% of the network is the metric . the 25.01% of the network is needed to hold back growth with upto 25% orphan headaches. what you need to also take into account is nodes might have 75%-95%.. but pools may also have their own safer metric to reduce orphan risks EG nodes at 75% where consensus.h 4mb and policy at 2.5mb EG pools at 95% where consensus.h 2.5mb and policy at 1.01mb for instance. resulting in pools only making blocks 1mb-2.5mb before seeing issues and pools only moving passed 2.5 if 95% of pools agree and 75% of nodes agree.. 2. if an orphan game results in bilateral split(it doesnt).. we would be having several altcoins being created a week for the last 8 years just because of orphans https://blockchain.info/orphaned-blocksorphans KILL OFF opposing blocks. to keep to one chain to avoid orphaning a block. the nodes need to ban the opposition 1. I assume we could also downscale. If nodes lower their limit for whatever reasons (or new nodes with low limits get added to the network). The pools would adopt and make smaller blocks if the orphan rate would be to high. 2. I thought the difference between an orphan and an invalid block would be that an invalid block doesn't meat the parameters of the consensus. Whereas an orphan is a valid block that is just propagated at the same time with another and it is not sure which one will result in the longer chain. So invalid = fork and orphan =/= fork. edit: just read your edit and this makes it clear clear for me. Thank you.
|
|
|
|
manselr
Legendary
Offline
Activity: 868
Merit: 1006
|
|
March 05, 2017, 06:39:04 PM |
|
Let's see BU fork and let's see how they manage themselves without leeching off Core devs. But they are too scared to fork so they will keep using their shitty tactics. Jihan Wu is a disaster for bitcoin, I wish his stupid monolopy ended, but im not sure about UASF fixing anything in the long run.
|
|
|
|
AngryDwarf
|
|
March 05, 2017, 06:42:30 PM |
|
If this is how BU works, I don't think I like the idea of running a node and constantly have to check whether my synchronization has stopped because I have dropped out of the bottom consensus and then having to change configuration. Also, there is a need for blocksize to shrink to stop the fee market tending back to zero when there is no or little block reward when volume drops. If BU doesn't do this then I don't think it is the right answer either. It all needs to be a lot more automatic for me.
|
|
|
|
AngryDwarf
|
|
March 05, 2017, 09:52:15 PM |
|
X% are with segwit X% are with BU X% are with classic but ~60%.. yep well over 50% are UNDECIDED
so do not classify the 50-60% undecided as being in any camp just to suit some biased brand camp social games
Here is a thought. Perhaps a good percentage of these undecided are not really undecided but just don't like the options available to them, so are happy to keep the status quo until a better solution is found, or perhaps that one of the solutions is better implemented?
|
|
|
|
franky1
Legendary
Offline
Activity: 4354
Merit: 4703
|
|
March 05, 2017, 10:55:42 PM Last edit: March 06, 2017, 12:13:37 AM by franky1 |
|
or perhaps that one of the solutions is better implemented?
there are many solutions. you just dont hear about them due to the censorship and hoops you have to jump through just to get a core dev to even class it as a bip on "their" bip wall. and the social media trolling drowning out other methods of promoting one because "its not been reviewed by the blockstream gods" recently gmaxwell handed the Bip reins over to luke jr but gmaxwell still moderates the technical discussion boards of this forum and works along side theymos in the reddit forum. and also admins the mailing lists. and has co-horts moderating the IRC. so goodluck to anyone not ass kissing blockstream for coming up with anything new that actually gets passed the blockstream wall, and into the communities general acceptance
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
BillyBobZorton
Legendary
Offline
Activity: 1204
Merit: 1028
|
|
March 05, 2017, 11:01:30 PM |
|
Talking about BU any further it's useless. BU will never work, the model is flawed, it leads to destruction, miners would be total bosses, more than now and now it's bad enough already. Jihan Wu would rule Bitcoin under the BU model, which is why he pushes it. Very sad..
|
|
|
|
franky1
Legendary
Offline
Activity: 4354
Merit: 4703
|
|
March 05, 2017, 11:02:49 PM Last edit: March 05, 2017, 11:34:52 PM by franky1 |
|
Talking about BU any further it's useless. BU will never work, the model is flawed, it leads to destruction, miners would be total bosses, more than now and now it's bad enough already. Jihan Wu would rule Bitcoin under the BU model, which is why he pushes it. Very sad..
do your research. stop reading the 20 second reddit scripts. your getting obvious read code learn consensus understand bitcoin stop defending humans 1. jihan isnt the mining king that wil own bitcoin.. please research stats not social media 2. pools are not the boss never have or will be. they are the secretaries.. nodes are the bosses and devs need to be reminded that devs are just workers 3. implementations that are not blockstream are not the ones wanting to be kings. 4. its actually blockstream that gave ONLY pools the vote over segwit.. yet a hard consensus is about NODES st the rules pools follow
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
doc12
Legendary
Offline
Activity: 1284
Merit: 1042
|
|
March 05, 2017, 11:10:37 PM Last edit: March 05, 2017, 11:22:22 PM by doc12 |
|
Talking about BU any further it's useless. BU will never work, the model is flawed, it leads to destruction, miners would be total bosses, more than now and now it's bad enough already. Jihan Wu would rule Bitcoin under the BU model, which is why he pushes it. Very sad..
Jap, i think maybe we should stop to talk about that crap (BU) and not respond to the trolls anymore (frany1). BU is not an option and never will be. We should work towards bringing more power to the users, not to the miners, they are getting their fucking blockreward and should be fine with that. Nothing more and especially no ultmate decision power. So UASF is maybe a way to go. The reaction from Mr. Jihan shows its a at least an option. No franky im not interested in what you have to say, just STFU.
|
|
|
|
Peter R
Legendary
Offline
Activity: 1162
Merit: 1007
|
|
March 05, 2017, 11:49:27 PM |
|
If this is how BU works, I don't think I like the idea of running a node and constantly have to check whether my synchronization has stopped because I have dropped out of the bottom consensus and then having to change configuration. If you don't want to drop from consensus due to too small a block size limit and you don't want to update your node, then you can set your "excessive block gate" to something like 12 or so (this is actually the default setting). This means that your node will try to reject blocks larger than your block size limit setting, but give up and follow the mining majority if the network as a whole decides to accept larger blocks. Here is an article that describes how this optional feature works: https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4
|
|
|
|
franky1
Legendary
Offline
Activity: 4354
Merit: 4703
|
|
March 06, 2017, 12:26:09 AM |
|
2. I thought the difference between an orphan and an invalid block would be that an invalid block doesn't meat the parameters of the consensus. Whereas an orphan is a valid block that is just propagated at the same time with another and it is not sure which one will result in the longer chain. So invalid = fork and orphan =/= fork.
edit: just read your edit and this makes it clear clear for me. Thank you.
an invalid block = blocks that doesnt meet the rules (your understanding of not meeting the parameters) a rejected block can be valid(data/rule) but for propagation or longer chain or other reasons it just doesnt get accepted. an orphan is just an umbrella term. EG real world. an orphan is a child thrown aside and detached from its parent. it can be because the parent is killed off. it can be because the parent no longer wants to be linked to the child (gave up for adoption) it can be force away from parent (social services removed parental rights) so in bitcoin the umbrella term orphan, just means thrown aside.. orphans happen alot http://blockchain.info/orphaned-blocksbut explanations as to WHY, vary. all you can see is what other child replaced it as the preferred child
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
franky1
Legendary
Offline
Activity: 4354
Merit: 4703
|
|
March 06, 2017, 12:54:54 AM |
|
If this is how BU works, I don't think I like the idea of running a node and constantly have to check whether my synchronization has stopped because I have dropped out of the bottom consensus and then having to change configuration. Also, there is a need for blocksize to shrink to stop the fee market tending back to zero when there is no or little block reward when volume drops. If BU doesn't do this then I don't think it is the right answer either. It all needs to be a lot more automatic for me.
the description of DYNAMIC BLOCKS i made in post #57 is the broader way of how nodes set limits and pools follow in regards to how consenus generally works for all of the different 'dynamic proposals' BU(just one of many proposals) for instance has a little extra(which is about the Excessive block stuff). which would occur in step two of my broader description. which would as you say 'automate' to move the goal posts. thus if you have the right upper setting. will find that your node wont unsync and be left behind as much as you think but like i said there is more then one 'limit' and also pools follow what nodes allow, not the other way round. yes if your nodes upper limit is not that high then you have to check now and again that its still syncing. but if your node has sufficient limits set and knowing that pools are not stupid to jump too high to fast (pools are smart to take small tolerable steps to avoid orphan drama as much as possible) you wont have to worry about checking often
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
doc12
Legendary
Offline
Activity: 1284
Merit: 1042
|
|
March 06, 2017, 06:26:39 AM |
|
If this is how BU works, I don't think I like the idea of running a node and constantly have to check whether my synchronization has stopped because I have dropped out of the bottom consensus and then having to change configuration. If you don't want to drop from consensus due to too small a block size limit and you don't want to update your node, then you can set your "excessive block gate" to something like 12 or so (this is actually the default setting). This means that your node will try to reject blocks larger than your block size limit setting, but give up and follow the mining majority if the network as a whole decides to accept larger blocks. Here is an article that describes how this optional feature works: https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4LOL look this shows what a bullshit BU is. Why have a limit then anyway? If I dont want to be forked off the network I have to set it to unlimited anyway. So all decision power goes to some chinese miners, no thx. If you ever get this shit activated the price will tank so hard, that mxgox desaster will will look like a mini dump. At least on the BU-altcoin chain :p
|
|
|
|
Peter R
Legendary
Offline
Activity: 1162
Merit: 1007
|
|
March 06, 2017, 06:40:57 AM |
|
If this is how BU works, I don't think I like the idea of running a node and constantly have to check whether my synchronization has stopped because I have dropped out of the bottom consensus and then having to change configuration. If you don't want to drop from consensus due to too small a block size limit and you don't want to update your node, then you can set your "excessive block gate" to something like 12 or so (this is actually the default setting). This means that your node will try to reject blocks larger than your block size limit setting, but give up and follow the mining majority if the network as a whole decides to accept larger blocks. Here is an article that describes how this optional feature works: https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4LOL look this shows what a bullshit BU is. Why have a limit then anyway? If I dont want to be forked off the network I have to set it to unlimited anyway. So all decision power goes to some chinese miners, no thx. If you ever get this shit activated the price will tank so hard, that mxgox desaster will will look like a mini dump. At least on the BU-altcoin chain :p Some people want to automatically track consensus regardless of the size of blocks; other people want to hold firm on the size of blocks they will accept. So we (Bitcoin Unlimited) allowed users to do either. BTW--Bitcoin Unlimited doesn't "activate." BU nodes by default will accept blocks larger than 1 MB today.
|
|
|
|
doc12
Legendary
Offline
Activity: 1284
Merit: 1042
|
|
March 06, 2017, 07:07:13 AM |
|
If this is how BU works, I don't think I like the idea of running a node and constantly have to check whether my synchronization has stopped because I have dropped out of the bottom consensus and then having to change configuration. If you don't want to drop from consensus due to too small a block size limit and you don't want to update your node, then you can set your "excessive block gate" to something like 12 or so (this is actually the default setting). This means that your node will try to reject blocks larger than your block size limit setting, but give up and follow the mining majority if the network as a whole decides to accept larger blocks. Here is an article that describes how this optional feature works: https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4LOL look this shows what a bullshit BU is. Why have a limit then anyway? If I dont want to be forked off the network I have to set it to unlimited anyway. So all decision power goes to some chinese miners, no thx. If you ever get this shit activated the price will tank so hard, that mxgox desaster will will look like a mini dump. At least on the BU-altcoin chain :p Some people want to automatically track consensus regardless of the size of blocks; other people want to hold firm on the size of blocks they will accept. So we (Bitcoin Unlimited) allowed users to do either. BTW--Bitcoin Unlimited doesn't "activate." BU nodes by default will accept blocks larger than 1 MB today. No this is bullshit man, if you always want to stay sync with the network you have to set the litmit to unlimited. Maybe you have the time to sit infront your node and track the blocksize the whole day, but many surely dont. So please just go away with your divergent consensus. Good that a supermajority of the network is on core and will reject your altcoins blocks if a fork happens.
|
|
|
|
Peter R
Legendary
Offline
Activity: 1162
Merit: 1007
|
|
March 06, 2017, 07:34:33 AM |
|
If this is how BU works, I don't think I like the idea of running a node and constantly have to check whether my synchronization has stopped because I have dropped out of the bottom consensus and then having to change configuration. If you don't want to drop from consensus due to too small a block size limit and you don't want to update your node, then you can set your "excessive block gate" to something like 12 or so (this is actually the default setting). This means that your node will try to reject blocks larger than your block size limit setting, but give up and follow the mining majority if the network as a whole decides to accept larger blocks. Here is an article that describes how this optional feature works: https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4LOL look this shows what a bullshit BU is. Why have a limit then anyway? If I dont want to be forked off the network I have to set it to unlimited anyway. So all decision power goes to some chinese miners, no thx. If you ever get this shit activated the price will tank so hard, that mxgox desaster will will look like a mini dump. At least on the BU-altcoin chain :p Some people want to automatically track consensus regardless of the size of blocks; other people want to hold firm on the size of blocks they will accept. So we (Bitcoin Unlimited) allowed users to do either. BTW--Bitcoin Unlimited doesn't "activate." BU nodes by default will accept blocks larger than 1 MB today. No this is bullshit man, if you always want to stay sync with the network you have to set the litmit to unlimited. Maybe you have the time to sit infront your node and track the blocksize the whole day, but many surely dont. So please just go away with your divergent consensus. Good that a supermajority of the network is on core and will reject your altcoins blocks if a fork happens. Bitcoin Unlimited simply removes friction from node operators adjusting their block size limits. Everything that a node operator can do with BU they can already do with Core by modifying the code and recompiling. If you think Bitcoin Unlimited "breaks" Bitcoin then you must think that the only reason Bitcoin is not broken is because it takes a bit of effort to recompile the code. Some more thoughts on the matter: https://medium.com/@peter_r/what-were-doing-with-bitcoin-unlimited-simply-6f71072f9b94
|
|
|
|
jonald_fyookball
Legendary
Offline
Activity: 1302
Merit: 1008
Core dev leaves me neg feedback #abuse #political
|
|
March 07, 2017, 02:43:04 AM |
|
If this is how BU works, I don't think I like the idea of running a node and constantly have to check whether my synchronization has stopped because I have dropped out of the bottom consensus and then having to change configuration. If you don't want to drop from consensus due to too small a block size limit and you don't want to update your node, then you can set your "excessive block gate" to something like 12 or so (this is actually the default setting). This means that your node will try to reject blocks larger than your block size limit setting, but give up and follow the mining majority if the network as a whole decides to accept larger blocks. Here is an article that describes how this optional feature works: https://medium.com/@peter_r/the-excessive-block-gate-how-a-bitcoin-unlimited-node-deals-with-large-blocks-22a4a5c322d4LOL look this shows what a bullshit BU is. Why have a limit then anyway? If I dont want to be forked off the network I have to set it to unlimited anyway. So all decision power goes to some chinese miners, no thx. If you ever get this shit activated the price will tank so hard, that mxgox desaster will will look like a mini dump. At least on the BU-altcoin chain :p I would like to understand your point of view here when you say "giving all power to the miners". Other than allowing the miners to come to a consensus about blocksize with less constraint, what power do you feel that BU gives to the miners that they don't already have?
|
|
|
|
Vaskiy
Legendary
Offline
Activity: 2646
Merit: 1106
Enterapp Pre-Sale Live - bit.ly/3UrMCWI
|
|
March 07, 2017, 03:39:11 AM |
|
Soft fork and hard fork have explained about the pro's and cons of each supporting their own group. Hard fork focus towards mining full nodes and transaction time. Soft fork focus towards the decentralization and the miners fee, so a common committee could resolve it.
|
|
|
|
tokyopotato
Legendary
Offline
Activity: 812
Merit: 1000
|
|
March 07, 2017, 03:54:42 AM |
|
|
|
|
|
kiklo
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
March 07, 2017, 09:35:17 AM Last edit: March 07, 2017, 09:46:13 AM by kiklo |
|
|
|
|
|
kiklo
Legendary
Offline
Activity: 1092
Merit: 1000
|
|
March 07, 2017, 09:38:50 AM |
|
|
|
|
|
|