Windowly
Active Member
- Dec 10, 2015
- 157
- 385
It's quite a high security area, much like Tibet because of the sporadic unrest that breaks out there between the Han Chinese and the Uyghurs.
Gold collapsing. Bitcoin UP.
- Thread starter cypherdoc
- Start date
Oh did I open a can of worms in twitter - the result over 579 people celebrating blind faith in bitcoin authority and calling me ignorant of the fact he was mentioned in the white paper. - like i haven't read it!
I just want to clarify after reading the criticism I've received.
I just want to clarify after reading the criticism I've received.
Last edited:
adamstgbit
Well-Known Member
- Mar 13, 2016
- 1,206
- 2,650
UASF signaling has begun!
let's start a sybil attack 50,000nodes signaling for them to FUCK OFF
lol
who's got 1/2million dollars to burn for lolz
[doublepost=1490841732,1490840906][/doublepost]this node is signaling for a UASF
https://bitnodes.21.co/nodes/158.69.102.114-8333/
[doublepost=1490841822][/doublepost]30 nodes!
https://bitnodes.21.co/nodes/?q=UASF-Segwit
let's start a sybil attack 50,000nodes signaling for them to FUCK OFF
lol
who's got 1/2million dollars to burn for lolz
[doublepost=1490841732,1490840906][/doublepost]this node is signaling for a UASF
https://bitnodes.21.co/nodes/158.69.102.114-8333/
[doublepost=1490841822][/doublepost]30 nodes!
https://bitnodes.21.co/nodes/?q=UASF-Segwit
- Aug 29, 2015
- 536
- 2,597
That's very interesting. Seems to me that UASF is quite risky for nodes. They are saying they will reject the longest chain if it includes transactions that don't follow the new rules they want to institute.
If they are very confident that the vast majority of the economy will also reject the longest chain if it violates their new rules, then they can make the longest chain worth less for miners. This would incentivize the miners to only produce blocks that comply with the new rules.
But this seems like a huge risk for them. If the miners call their bluff, and don't enforce the new rules, they will be forking themselves off, following a minority chain with all the risk that entails. If there are significant economic nodes following the longest chain, the UASFers risk isolating themselves.
There is no real way for the UASF nodes to know if they have an overwhelming majority, I would expect there is a lot of inertia of non-switching nodes. So this reduces the potency of their ultimatum. For instance, SPV or Electrum wallets would presumably follow the longest chain as long as they connect to at least one non-UASF node.
It will certainly be interesting to see how things play out if they follow through. Seems ill-advised to me though.
If they are very confident that the vast majority of the economy will also reject the longest chain if it violates their new rules, then they can make the longest chain worth less for miners. This would incentivize the miners to only produce blocks that comply with the new rules.
But this seems like a huge risk for them. If the miners call their bluff, and don't enforce the new rules, they will be forking themselves off, following a minority chain with all the risk that entails. If there are significant economic nodes following the longest chain, the UASFers risk isolating themselves.
There is no real way for the UASF nodes to know if they have an overwhelming majority, I would expect there is a lot of inertia of non-switching nodes. So this reduces the potency of their ultimatum. For instance, SPV or Electrum wallets would presumably follow the longest chain as long as they connect to at least one non-UASF node.
It will certainly be interesting to see how things play out if they follow through. Seems ill-advised to me though.
I remember that the initial discussions around 'EC' with @Peter R. et al. led to someone (was it you, Peter?) saying EC has a feeling of being *inevitable*.
You can see some folks who are now pro bigger blocks on reddit, but still dislike the BU approach, because it is all chaos and will lead to chaos (that's essentially the complaint).
Here's why I think it is *inevitable* if the majority wants bigger blocks:
- Bitcoin being decentralized means with no central authority. This appears to be already hard to swallow for some, as, as we all know, a circular reference to Core's 'authority' slips in for many at some point. I think each of us has argued lots and lots on this mental hang-up. However, I *have* seen people who are pro bigger-blocks, critical of Core and still dislike BU. So assume this is accepted and lets get to the next point:
- We had a dozen or so proposals on a blocksize increase. All of them except BU have not gathered widespread, unanimous support.
- It thus appears that people have varying and different preferences for blocksize.
- With different preferences for blocksize, *no single blocksize proposal* will gather widespread support.
- That means that the only thing you can do if you indeed truly want bigger blocks is to signal your readiness for them.
- Which means a form of EC.
The alternative to EC is to have some magic authority decide on blocksize and everyone to accept that authority. Which actually exists in Bitcoin, but is Nakamoto consensus, meaning the miners.
So I think there are three groups:
1) rabid, hardcore 1MB small-blockers
2) reasonable blockers who want to increase blocksize but do not want to give it to the miners
3) reasonable blockers who want to increase blocksize and do not care if the miners decide
EC works for both 2) and 3).
You can see some folks who are now pro bigger blocks on reddit, but still dislike the BU approach, because it is all chaos and will lead to chaos (that's essentially the complaint).
Here's why I think it is *inevitable* if the majority wants bigger blocks:
- Bitcoin being decentralized means with no central authority. This appears to be already hard to swallow for some, as, as we all know, a circular reference to Core's 'authority' slips in for many at some point. I think each of us has argued lots and lots on this mental hang-up. However, I *have* seen people who are pro bigger-blocks, critical of Core and still dislike BU. So assume this is accepted and lets get to the next point:
- We had a dozen or so proposals on a blocksize increase. All of them except BU have not gathered widespread, unanimous support.
- It thus appears that people have varying and different preferences for blocksize.
- With different preferences for blocksize, *no single blocksize proposal* will gather widespread support.
- That means that the only thing you can do if you indeed truly want bigger blocks is to signal your readiness for them.
- Which means a form of EC.
The alternative to EC is to have some magic authority decide on blocksize and everyone to accept that authority. Which actually exists in Bitcoin, but is Nakamoto consensus, meaning the miners.
So I think there are three groups:
1) rabid, hardcore 1MB small-blockers
2) reasonable blockers who want to increase blocksize but do not want to give it to the miners
3) reasonable blockers who want to increase blocksize and do not care if the miners decide
EC works for both 2) and 3).
Agreed @awemany but I think the term EC is hopelessly tainted now. Adjustable blocksize cap, or even more directly spelled out, simply not pretending that a barrier of inconvenience can keep everyone using the same setting in open source code, is all people really need to get behind.
It's clearly a lost cause to keep trying to herd users by attempting to remove their choices. If people have not assented to this argument it can only be because it has not been presented clearly enough to cut through the noise. Indeed the end of "rule by locked-down settings" is inevitable. Once you see it, you can't unsee it.
It's clearly a lost cause to keep trying to herd users by attempting to remove their choices. If people have not assented to this argument it can only be because it has not been presented clearly enough to cut through the noise. Indeed the end of "rule by locked-down settings" is inevitable. Once you see it, you can't unsee it.
KoKansei
Member
- Mar 5, 2016
- 49
- 360
FWIW, over the last week I have found that the "security through inconvenience" argument is probably more effective than anything else at shutting down authoritarian "we must all follow the same consensus rules" malarkey, possibly because it is still not a very widespread meme so the core side hasn't developed an effective counter... at least yet.
It might be worthwhile to write up something like a medium article that leverages this argument for maximum impact. I'm in the middle of a massive work-related project at the moment, so if nobody has it tackled by next week, I will write something up myself.
Here's an example of the "security through inconvenience" argument in action:
/u/paleh0rse clearly didn't quite know how to respond to this argument.
It might be worthwhile to write up something like a medium article that leverages this argument for maximum impact. I'm in the middle of a massive work-related project at the moment, so if nobody has it tackled by next week, I will write something up myself.
Here's an example of the "security through inconvenience" argument in action:
/u/paleh0rse clearly didn't quite know how to respond to this argument.
Wang-Chung has a new tweet I had to share. I've got my popcorn ready and looking forward to see the new set of fireworks go off!
But Wait! Comedy hour isn't over yet!
https://www.docdroid.net/NG1sbVq/pantera-march-2017.pdf.html
I guess these slides are from one of Roger's presentation. They go great with morning coffee. Just be careful not to let any coffee come out your nose or onto paperwork from laughing so hard.
https://www.docdroid.net/NG1sbVq/pantera-march-2017.pdf.html
I guess these slides are from one of Roger's presentation. They go great with morning coffee. Just be careful not to let any coffee come out your nose or onto paperwork from laughing so hard.
https://coin.dance/blocks
I don't know if we are getting closer to the end but we would be getting closer to "an event" or the "happening."
So currently
BU = 37.6
Segwit = 28.8
8 MB Blocks = 4.5%
F2Pool controls around 12% network hashpower;
So if F2Pool starts signalling for larger blocks = 37.6% +4.5% +12% = 54.1%
I'm not sure how the narrative would change at that point and recognize that we would still be a relatively significant hurdle away from +/- 75%. I mean Bitfury alone now controls 10%, Slush 7%; but I think things would get interesting. The change in narrative lately is most disconcerting to me. It's become blatant lies at this point that are accepted as truth.
I don't know if we are getting closer to the end but we would be getting closer to "an event" or the "happening."
So currently
BU = 37.6
Segwit = 28.8
8 MB Blocks = 4.5%
F2Pool controls around 12% network hashpower;
So if F2Pool starts signalling for larger blocks = 37.6% +4.5% +12% = 54.1%
I'm not sure how the narrative would change at that point and recognize that we would still be a relatively significant hurdle away from +/- 75%. I mean Bitfury alone now controls 10%, Slush 7%; but I think things would get interesting. The change in narrative lately is most disconcerting to me. It's become blatant lies at this point that are accepted as truth.
SanchoPanza
Member
- Mar 29, 2017
- 47
- 65
If anyone here is willing to help a simple peasant like me get his petition through to bitcoin-dev :
I am looking for witnesses who I can CC or BCC (as you wish) on the re-submission tomorrow.
Please message me here privately (or PM me on reddit) if you are willing to help.
I am looking for witnesses who I can CC or BCC (as you wish) on the re-submission tomorrow.
Please message me here privately (or PM me on reddit) if you are willing to help.
"He just told me in the linked thread to 'get lost' because I'm "censoring reality"
LMFAO I'm sorry Sancho. That response seems absurd. I'm not willing to help because I don't want to play with Core. I like streaming netflix and I don't want to subject myself to an unending dos attack.
LMFAO I'm sorry Sancho. That response seems absurd. I'm not willing to help because I don't want to play with Core. I like streaming netflix and I don't want to subject myself to an unending dos attack.
- Aug 29, 2015
- 536
- 2,597
I agree with @awemany and @Zangelbert Bingledack
One of the current hangups is that people identify "Emergent Consensus" with the Acceptance Depth parameter as implemented in Bitcoin Unlimited.
They imagine EC as a process where miners are producing blocks, testing nodes' AD settings to try to bump blocks size, resulting in frequent re-orgs. I agree with them that this would be a crazy way to settle on a block size limit on the network. I seems obvious to me that things wouldn't work this way, just because miners have a huge incentive to only produce blocks that are virtually certain to be accepted by the network. But if people think that we think this... That explains some of the anti-BU sentiment.
Here are some ideas of things I think can be done to help address this:
One of the current hangups is that people identify "Emergent Consensus" with the Acceptance Depth parameter as implemented in Bitcoin Unlimited.
They imagine EC as a process where miners are producing blocks, testing nodes' AD settings to try to bump blocks size, resulting in frequent re-orgs. I agree with them that this would be a crazy way to settle on a block size limit on the network. I seems obvious to me that things wouldn't work this way, just because miners have a huge incentive to only produce blocks that are virtually certain to be accepted by the network. But if people think that we think this... That explains some of the anti-BU sentiment.
Here are some ideas of things I think can be done to help address this:
- De-emphasize Acceptance Depth in explanations of Emergent Consensus.
- Use the term Adjustable Block-Size Cap (ABC) in preference to EC.
- Remove signalling of AD from the client agent string, and in coinbase message.
- Add an "off" option for AD in BU (aka "infinity setting").
- Highlight and encourage use of other ABC clients that don't have AD, like Bitcoin Classic
- Develop alternatives to AD for node consensus tracking. For example, just monitoring for alternate chains, and warning the node operator of there is an alternate chain being mined would be a good safety feature.
- Develop "pluggable modules" to control nodes' EB setting. These would basically be scripts that could get information from the nodes (for example coinbase messages, or block sizes observed on the network), and then adjust the node's EB setting according to certain rules. These "pluggable modules" could be used to implement BIP100, for example, or any other block size coordination proposal. They could also be used across different ABC clients, thus removing the link between dev team and block size consensus policy.
SanchoPanza
Member
- Mar 29, 2017
- 47
- 65
Thank you Tomothy - it is why I suggested BCC is an option, but I do understand why you feel you wouldn't want to get involved.
I guess those who would be able to publicly back me up would need to be CC'able.
If only there was a service which CC'd emails to the blockchain... but alas, I can just include the hash of the most recent block in the chain. This proves my mail was sent no earlier. O no...
https://np.reddit.com/r/Bitcoin/comments/5mxgdu/using_blockchainbitcoin_to_certify_email/
Last edited:
Richy_T
Well-Known Member
- Dec 27, 2015
- 1,085
- 2,741
@Mengerian, no economically significant node will UASF. It's a paper tiger.
[doublepost=1490894386,1490893483][/doublepost]@Mengerian, I'm down with trying to reframe the discussion of EC but I think it would be a mistake to start meddling with the BU mechanism at this point. Some would see it as a sign of weakness, others would try and exploit a "they don't know what they're doing" narrative and others (or most probably the same people) would point out that the changes were another opportunity for the introduction of bugs.
Let's stick the course with a promise to revisit EC *after* a fork. For people who are uncomfortable with it, we explain how to set the AD or suggest they use another compatible client like Classic. It would also be nice to have a patched Core client available but now Segwit code is in there, that might be a bit more difficult.
[doublepost=1490894386,1490893483][/doublepost]@Mengerian, I'm down with trying to reframe the discussion of EC but I think it would be a mistake to start meddling with the BU mechanism at this point. Some would see it as a sign of weakness, others would try and exploit a "they don't know what they're doing" narrative and others (or most probably the same people) would point out that the changes were another opportunity for the introduction of bugs.
Let's stick the course with a promise to revisit EC *after* a fork. For people who are uncomfortable with it, we explain how to set the AD or suggest they use another compatible client like Classic. It would also be nice to have a patched Core client available but now Segwit code is in there, that might be a bit more difficult.
- Aug 29, 2015
- 536
- 2,597
@Richy_T Sure, I agree we shouldn't make radical course changes. I guess I see the "infinity AD option" and not signalling AD in the coinbase or user agent string as small tweaks that clarify things, rather than complicating them.
I also think of it this way: I run a node, and I don't want to broadcast my AD to everyone. I just don't see what benefit there is, for the individual node operator, to tell everyone their AD setting.
Generally though, BU is on a good course, so we should stick with it. These are just minor tweaks I'm talking about.
I totally agree that it's a good idea to promote compatible clients like Classic, or an "ABCore" minimal patch.
I also think of it this way: I run a node, and I don't want to broadcast my AD to everyone. I just don't see what benefit there is, for the individual node operator, to tell everyone their AD setting.
Generally though, BU is on a good course, so we should stick with it. These are just minor tweaks I'm talking about.
I totally agree that it's a good idea to promote compatible clients like Classic, or an "ABCore" minimal patch.
molecular
Active Member
- Aug 31, 2015
- 372
- 1,391
what about the "bitcoin-infinity" patches? They're available for core 0.12.1 (does that have segwit?)
adamstgbit
Well-Known Member
- Mar 13, 2016
- 1,206
- 2,650
i agree with @Mengerian AD shouldn't necessarily be advertized.
Bagatell
Active Member
- Aug 28, 2015
- 728
- 1,191
