DooMAD
Legendary
Offline
Activity: 3948
Merit: 3191
Leave no FUD unchallenged
|
|
July 03, 2015, 07:19:57 AM |
|
We don't really use the alert mechanism, and many of the contributors to Bitcoin Core would like to remove it-- because the value it provides is very low, relative to the administrative overhead we receive in terms of people justifying non-starter proposals based on it (e.g. wanting to use it to remotely control miner default behaviour) or just the cost users have in reasoning about its security implications for them.
That said, there is very little potential for abuse, because if a bogus alert is sent a special alert can be sent that disables further use of the alert system erases all other alerts and sets a static alert key compromised message. As a result, active misuse is already effectively constructively disabled.
And all without fanning any extra drama.
While this might be true the question remains why someone who actively undermines the Bitcoin network, its devteam and community needs to hold said keys. Leaving Gavin with the keys is like saying one could leave his car unlocked in a highly criminal neighbourhood because if a thief would be taking it, the police would stop him. You lock the car so the thief can't drive away with it regardless of possible countermeasures! Gavin tried a hostile takeover, mind you. No he didn't. Also gmaxwell is one of the core devs. One of the people you trust implicitly (simply because they aren't Gavin), just told you there isn't a security risk. So far i can not identify new arguments or valid concerns against the proposal.
Translation: " La la la la la I'm not listening unless people agree with me". For someone who takes offence at someone else acting unilaterally (despite the fact there's nothing wrong with him doing that in an open source project), do you not see the irony in your tirade here? You complain that Gavin did something without everyone agreeing, yet you want to do something without everyone agreeing? Cry ad-hominem ad-nauseam if you like, but please stop being a hypocrite. There's no other word to describe it. Yes, someone can send a message-- but that message can be disabled, locked out, and replaced with a key compromised method by anyone with the alert key. For security reasons everyone who has the alertkey is not enumerated (so that someone can't attempt to suppress use of the alert key by targeting multiple people). Multiple people currently active in the project have the key, and there are also other security measures in place.
I hear your concerns. You're not the first or only one to express them; but I believe there is still a more professional cooperative way forward available and I think we should make use of it to the greatest extent possible.
Thank you for bringing some well needed sanity to this otherwise deranged thread.
|
|
|
|
gmaxwell
Staff
Legendary
Offline
Activity: 4270
Merit: 8805
|
|
July 03, 2015, 07:36:29 AM |
|
No he didn't. Also gmaxwell is one of the core devs. One of the people you trust implicitly (simply because they aren't Gavin), just told you there isn't a security risk.
To spare a little credit here; I'm unconcerned in part due to reasons that he was previously unaware of-- I think if I knew only what he knew, I would have been concerned. I'm thankful that people other than the development team are also thinking about these things and raising concerns; and I welcome it (though think it's much more productive if they're expressed in the most polite way possible; simply because adding emotion almost never makes a tricky situation easier)... it's just in this particular case I believe the concerns are adequately addressed for the moment, but I don't mind answering questions about it.
|
|
|
|
turvarya
|
|
July 03, 2015, 07:42:56 AM |
|
Sure, people are against this raise. I am looking into this discussion for months. Seems like you have just joined after Gavin made this deal with Hearn. That is a result of this whole discussion, not the reason for this discussion.
You cant say that people are against an increase only because most community members dont want to do haste things. Gavin acted like if we would meet the blocksizelimit tomorrow. Graphs were posted with exponential axis values that let it look like blocks are already 90% full now and other things. The thing is that all the other developers see the problem. They only wanted a discussion about the best solution. And as far as i see it nearly no one is against a change in the future, when it becomes a problem. Though most think we have at least time to find the best solution. You cant say so many are against it only because they dont want to follow gavins idea that we have to do it now, instantly, and the way he wants it. That this behaviour brings up resistance is normal. So i would prefer when you say that people are against doing it the hasty way. Its not true that the ones that dont support gavin doesnt see the need of an increase. The problem is only the when and the how. Sorry, but you are just wrong, all kinds of people say, that they don't want the blocksize limit raised ever. Look e.g. here: https://www.youtube.com/watch?v=cZp7UGgBR0II even had a real life discussion about that at my local Bitcoin Meetup. The bottom line was: "No blocklimit raise, we need trusted third parties" So, don't tell me, what I have read/heard.
|
|
|
|
SebastianJu
Legendary
Offline
Activity: 2674
Merit: 1083
Legendary Escrow Service - Tip Jar in Profile
|
|
July 03, 2015, 10:05:25 AM |
|
Sure, people are against this raise. I am looking into this discussion for months. Seems like you have just joined after Gavin made this deal with Hearn. That is a result of this whole discussion, not the reason for this discussion.
You cant say that people are against an increase only because most community members dont want to do haste things. Gavin acted like if we would meet the blocksizelimit tomorrow. Graphs were posted with exponential axis values that let it look like blocks are already 90% full now and other things. The thing is that all the other developers see the problem. They only wanted a discussion about the best solution. And as far as i see it nearly no one is against a change in the future, when it becomes a problem. Though most think we have at least time to find the best solution. You cant say so many are against it only because they dont want to follow gavins idea that we have to do it now, instantly, and the way he wants it. That this behaviour brings up resistance is normal. So i would prefer when you say that people are against doing it the hasty way. Its not true that the ones that dont support gavin doesnt see the need of an increase. The problem is only the when and the how. Sorry, but you are just wrong, all kinds of people say, that they don't want the blocksize limit raised ever. Look e.g. here: https://www.youtube.com/watch?v=cZp7UGgBR0II even had a real life discussion about that at my local Bitcoin Meetup. The bottom line was: "No blocklimit raise, we need trusted third parties" So, don't tell me, what I have read/heard. Oh well... that video is hefty. Did some minercorporation sponsor it? Though even then its plain stupid. A blocksize limit raise HAS to happen. At least in some years. Its stupid to force users to pay higher and higher fees and transactions stay unconfirmed. It would mean a big hit to the network since a currency that cant flow is useless. Miners would destroy their own eating ground. Miners will get bigger fees. They shouldnt fear. They simply would need to enforce adoption and the more transactions happen the more fees will be collected. If someone really wants to restrict the network then this would not be a smart move. By the way.. miners have all right to not include transactions they feel have a too small fee. When the users find that their transaction waits longer with a low fee then they will start to raise it. Simple as that. And they fear centralisation? What do they think bigger fees will do? Surely companies that try to exploit it. It will not save decentralization. It cant. A Bitcoin only for big transactions? Thats plain stupid. Bitcoin should be useable for everyone and every usecase of a value around the minimum fiat currency units. I dont know what kind ot bitcoin these users want but surely its not what satoshie wanted when he wanted to free the people from the banks. These bitcoiners seem to want to free the rich from the banks. Ok, guess i understand bitcoin-xt fans now a bit more. Though i cant support him because i think he has a somewhat dangerous character. At the end the miners will decide and it looks like the majority is for a raise at least. I mean the compromise with chinese miners. This happens in the sport world too.... When the team performs bad, the couch is blamed. ...
Yes... blame the couch...
|
Please ALWAYS contact me through bitcointalk pm before sending someone coins.
|
|
|
forlackofabettername (OP)
|
|
July 05, 2015, 02:49:39 PM |
|
Thats a good info gmaxwell. I guess a fast reaction is almost certain then. [...] The results werent so impressing?
Yes, I estimate it could be corrected in under 5 minutes right now. WRT result, the primary thing the alert does right now is triggers the error bar in Bitcoin Core and the alert notify output; which almost no one will notice. Past notices have had very little effect in general. Basically, the person(s) with the alert key possesses the authority to instruct bitcoin users to update. So strangely, at the moment, a man that vanished 5 years ago has that authority as does a developer that has apparently broken away from core. Yet, to the best of my knowledge, no remaining core dev has this key.
More or less incorrect on both counts. Yes, someone can send a message-- but that message can be disabled, locked out, and replaced with a key compromised method by anyone with the alert key. For security reasons everyone who has the alertkey is not enumerated (so that someone can't attempt to suppress use of the alert key by targeting multiple people). Multiple people currently active in the project have the key, and there are also other security measures in place. I hear your concerns. You're not the first or only one to express them; but I believe there is still a more professional cooperative way forward available and I think we should make use of it to the greatest extent possible. So you're saying there are more people holding the keys than we know about? You further say anyone holding a key can disable messages? May i ask how many more people hold alert keys (number of people we don't know about)? How many of the core devs do actually secretly hold alert keys? More or less than 50% of them? So if Gavin would go rogue his alerts would simply be disabled by someone else holding the keys? What if the submits the alert again? Will it end up in an endless childish 'submit and disable' war between Gavin and other people holding keys? All this still doesn't solve the issue at hand: the complete loss of trust for Gavin from the userbase and it also still doesn't justify why he needs to have those keys. So we're actually back to square 1 either way. I still can't identify a single rational justification why Gavin needs to hold keys and commit acess. The truth is: there is no reason for it to be that way and that's also why 4 pages into the thread no valid justification came up other than "don't worry, we can disable that alert when it is abused" which isn't exactly an 'on topic reply' and doesn't represent a reason why he needs to hold the keys. Translates to: "Gavin and nobody else needs to hold the keys because we can disable them when he abuses them" isn't an argument that's valid or made any sense because according to this logic you could give the keys to everyone on this thread and then some 500 people more just because "you can disable the message in case of abuse". So, no, that's not a valid argument.
|
"If you see fraud and don't shout fraud, you are a fraud" -- Nassim Taleb
|
|
|
Lauda
Legendary
Offline
Activity: 2674
Merit: 2965
Terminated.
|
|
July 05, 2015, 03:04:09 PM Last edit: July 05, 2015, 03:28:37 PM by LaudaM |
|
So you're saying there are more people holding the keys than we know about? You further say anyone holding a key can disable messages?
May i ask how many more people hold alert keys (number of people we don't know about)? How many of the core devs do actually secretly hold alert keys? More or less than 50% of them?
So if Gavin would go rogue his alerts would simply be disabled by someone else holding the keys? What if the submits the alert again? Will it end up in an endless childish 'submit and disable' war between Gavin and other people holding keys?
All this still doesn't solve the issue at hand: the complete loss of trust for Gavin from the userbase and it also still doesn't justify why he needs to have those keys. So we're actually back to square 1 either way. -snip-
He just stated that it is kept a secret for security reasons and you start asking him question about it. Stop doing that. Let me tell you how many have the keys: definitely more than 1; definitely less than 10,000. As for the part in bold, the simple answer is no. Why would someone tolerate that behavior? There isn't a complete loss of trust for Gavin. You're pulling this out of a hat. I still trust Gavin and I'm part of the userbase; thus your statement is invalidated. Enough with the Gavin is bad propaganda. If they think it is okay to let him keep them, then he should keep them. Update: You probably don't trust keyholder Y, but you don't know his identity. It loses credibility for you, but not for the people who don't trust him.
|
"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" 😼 Bitcoin Core ( onion)
|
|
|
forlackofabettername (OP)
|
|
July 05, 2015, 03:07:04 PM |
|
So you're saying there are more people holding the keys than we know about? You further say anyone holding a key can disable messages?
May i ask how many more people hold alert keys (number of people we don't know about)? How many of the core devs do actually secretly hold alert keys? More or less than 50% of them?
So if Gavin would go rogue his alerts would simply be disabled by someone else holding the keys? What if the submits the alert again? Will it end up in an endless childish 'submit and disable' war between Gavin and other people holding keys?
All this still doesn't solve the issue at hand: the complete loss of trust for Gavin from the userbase and it also still doesn't justify why he needs to have those keys. So we're actually back to square 1 either way. -snip-
He just stated that it is kept a secret for security reasons and you start asking him question about it. Stop doing that. Let me tell you how many have the keys: definitely more than 1; definitely less than 10,000. As for the part in bold, the simple answer is no. Why would someone tolerate that behavior? There isn't a complete loss of trust for Gavin. You're pulling this out of a hat. I still trust Gavin and I'm part of the userbase; thus your statement is invalidated. Enough with the Gavin is bad propaganda. If they think it is okay to let him keep them, then he should keep them. Well if Gavin keeps holding alertkeys then the whole alert system looses a lot of credibility because right now i can't trust the alerts since i don't trust Gavin but that only as a note on the sideline. I still am looking for a justification why Gavin needs to hold said keys at all. Please someone provide that!
|
"If you see fraud and don't shout fraud, you are a fraud" -- Nassim Taleb
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3542
Merit: 6886
Just writing some code
|
|
July 05, 2015, 03:29:21 PM |
|
So if Gavin would go rogue his alerts would simply be disabled by someone else holding the keys? What if the submits the alert again? Will it end up in an endless childish 'submit and disable' war between Gavin and other people holding keys?
If that were to happen, then as gmaxwell said, there would be a new alert that cannot be canceled and cancels all previous alerts that states "Alert Key Compromised" At that point, I would assume that the dev team would change the client to have a new alert key and simply not distribute that key to Gavin, thus solving the problem. However, that is not needed right now and is much more hassle to do because some people would have clients with the old key and some with the new. This means that if an alert was needed such as in the yesterday's problem, the same alert must be sent twice with both key's signatures in order to reach everyone. Well if Gavin keeps holding alertkeys then the whole alert system looses a lot of credibility because right now i can't trust the alerts since i don't trust Gavin but that only as a note on the sideline.
What alerts would you not trust? Use your own brain. Obviously an alert such as "URGENT: Upgrade to Bitcoin XT NOW" should probably be ignored. Every legitimate alert sent out links to a page from here: https://bitcoin.org/en/alerts.
|
|
|
|
MicroGuy
Legendary
Offline
Activity: 2506
Merit: 1030
Twitter @realmicroguy
|
|
July 05, 2015, 03:39:25 PM Last edit: July 05, 2015, 04:06:50 PM by MicroGuy |
|
If that were to happen, then as gmaxwell said, there would be a new alert that cannot be canceled and cancels all previous alerts that states "Alert Key Compromised" ...
Since no current member of core has been reported to have this key, that could become an awkward and most troublesome task.
|
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3542
Merit: 6886
Just writing some code
|
|
July 05, 2015, 03:49:22 PM |
|
If that were to happen, then as gmaxwell said, there would be a new alert that cannot be canceled and cancels all previous alerts that states "Alert Key Compromised" ...
Since no current member of core has been reported to have this key, that could become an awkward and most troublesome task. And, to the best of my knowledge, there is no override option that makes an alert cancel proof. Your knowledge is quite wrong. There are most certainly people on the core dev team that have the key. I'm pretty sure that gmaxwell has the alert key because he said this I'm using 0.10.2 and still got the message, it's not a version specific announcement.
The message was briefly up for 0.10.2 because 0.10 had failed to increment the protocol version and I failed to account for that. The there are two alerts which are active right now covering everything prior to 0.9 plus the specific subversion strings for 0.9.0-0.9.5. about the recent blockchain fork. He is referring to the alert sent out. Note the "I" There is in fact an override option that makes an alert cancel proof. Go look in the code. alert.cpp, line 178 https://github.com/bitcoin/bitcoin/blob/master/src/alert.cppgmaxwell said it too. More or less incorrect on both counts. Yes, someone can send a message-- but that message can be disabled, locked out, and replaced with a key compromised method by anyone with the alert key. For security reasons everyone who has the alertkey is not enumerated (so that someone can't attempt to suppress use of the alert key by targeting multiple people). Multiple people currently active in the project have the key, and there are also other security measures in place.
|
|
|
|
MicroGuy
Legendary
Offline
Activity: 2506
Merit: 1030
Twitter @realmicroguy
|
|
July 05, 2015, 04:10:08 PM |
|
If that were to happen, then as gmaxwell said, there would be a new alert that cannot be canceled and cancels all previous alerts that states "Alert Key Compromised" ...
Since no current member of core has been reported to have this key, that could become an awkward and most troublesome task. Your knowledge is quite wrong. There are most certainly people on the core dev team that have the key. I'm pretty sure that gmaxwell has the alert key because he said this I'm using 0.10.2 and still got the message, it's not a version specific announcement.
The message was briefly up for 0.10.2 because 0.10 had failed to increment the protocol version and I failed to account for that. The there are two alerts which are active right now covering everything prior to 0.9 plus the specific subversion strings for 0.9.0-0.9.5. about the recent blockchain fork. He is referring to the alert sent out. Note the "I" There is in fact an override option that makes an alert cancel proof. Go look in the code. alert.cpp, line 178 https://github.com/bitcoin/bitcoin/blob/master/src/alert.cppgmaxwell said it too. More or less incorrect on both counts. Yes, someone can send a message-- but that message can be disabled, locked out, and replaced with a key compromised method by anyone with the alert key. For security reasons everyone who has the alertkey is not enumerated (so that someone can't attempt to suppress use of the alert key by targeting multiple people). Multiple people currently active in the project have the key, and there are also other security measures in place.
Yes. I just found this: http://www.reddit.com/r/Bitcoin/comments/2dz9ri/why_in_the_world_does_theymos_have_the_private/cjuu360But since Gavin sends out all alerts, he could also send out an override making that failsafe a double-edged sword. Didn't Gavin send out the alert yesterday? In my view, the entire alert system should be stripped from the client. It is a point of unnecessary centralization with abuse potential.
|
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3542
Merit: 6886
Just writing some code
|
|
July 05, 2015, 04:23:10 PM |
|
He may have sent most, but I don't think he has sent all of the alerts he could also send out an override making that failsafe a double-edged sword. Didn't Gavin send out the alert yesterday?
He cannot override the failsafe. The alert key compromised alert has a fixed message and cannot be canceled. The message is specifically "URGENT: Alert key compromised, upgrade required" From this code block at line 178 in alert.cpp // alert.nID=max is reserved for if the alert key is // compromised. It must have a pre-defined message, // must never expire, must apply to all versions, // and must cancel all previous // alerts or it will be ignored (so an attacker can't // send an "everything is OK, don't panic" version that // cannot be overridden): int maxInt = std::numeric_limits<int>::max(); if (nID == maxInt) { if (!( nExpiration == maxInt && nCancel == (maxInt-1) && nMinVer == 0 && nMaxVer == maxInt && setSubVer.empty() && nPriority == maxInt && strStatusBar == "URGENT: Alert key compromised, upgrade required" )) return false; } Even if he did send out this failsafe alert, it wouldn't do him any good. People would check the bitcoin.org website where they got the client and not go to Gavin for the client. If Gavin committed code to change the alert key and put the new client on the bitcoin.org website, other committers can revert that change and remove his commit privileges thus preventing Gavin from changing the alert key to something that only he has. The other core devs can then change the alert key, put up the message about alert key compromised on the network status page (don't need to send the message, Gavin already did it) and put up the new client on bitcoin.org without Gavin's interference.
|
|
|
|
MicroGuy
Legendary
Offline
Activity: 2506
Merit: 1030
Twitter @realmicroguy
|
|
July 05, 2015, 04:27:12 PM |
|
He may have sent most, but I don't think he has sent all of the alerts he could also send out an override making that failsafe a double-edged sword. Didn't Gavin send out the alert yesterday?
He cannot override the failsafe. The alert key compromised alert has a fixed message and cannot be canceled. The message is specifically "URGENT: Alert key compromised, upgrade required" From this code block at line 178 in alert.cpp // alert.nID=max is reserved for if the alert key is // compromised. It must have a pre-defined message, // must never expire, must apply to all versions, // and must cancel all previous // alerts or it will be ignored (so an attacker can't // send an "everything is OK, don't panic" version that // cannot be overridden): int maxInt = std::numeric_limits<int>::max(); if (nID == maxInt) { if (!( nExpiration == maxInt && nCancel == (maxInt-1) && nMinVer == 0 && nMaxVer == maxInt && setSubVer.empty() && nPriority == maxInt && strStatusBar == "URGENT: Alert key compromised, upgrade required" )) return false; } Even if he did send out this failsafe alert, it wouldn't do him any good. People would check the bitcoin.org website where they got the client and not go to Gavin for the client. If Gavin committed code to change the alert key and put the new client on the bitcoin.org website, other committers can revert that change and remove his commit privileges thus preventing Gavin from changing the alert key to something that only he has. The other core devs can then change the alert key, put up the message about alert key compromised on the network status page (don't need to send the message, Gavin already did it) and put up the new client on bitcoin.org without Gavin's interference. Thank you for this information. -- -- I guess this would mean that whomever owns the domain bitcoin.org is the ruling controller of Bitcoin.
|
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3542
Merit: 6886
Just writing some code
|
|
July 05, 2015, 04:34:01 PM |
|
I guess this would mean that whomever owns the domain bitcoin.org is the ruling controller of Bitcoin.
Nope. The code for bitcoin.org is open source and has multiple committers just like Bitcoin does. It is also hosted from github. Actually, I don't think Gavin has commit access to Bitcoin.org, but I'm not sure. See this page: https://bitcoin.org/en/about-us
|
|
|
|
MarketNeutral
|
|
August 30, 2015, 06:12:44 PM |
|
Gavin currently holds the alert key to Bitcoin Core. Am I correct to presume he also holds the alert key to XT? So both?
Who is confirmed/unconfirmed having the alert keys to Core?
I want to press this issue since it seems to have fallen through the cracks, especially since Gavin's allegiance is clearly with XT. Also, I wouldn't put it past Hearn to try to get the Core alert key from Gavin.
|
|
|
|
tvbcof
Legendary
Offline
Activity: 4746
Merit: 1282
|
|
August 30, 2015, 06:28:19 PM |
|
I could see an alert key being abused in a time of crisis. Say, for instance, that XT forked. An alert could dampen down use to the advantage of one strategy or another. Probably the biggest risk of abuse would be to induce upgrades of Multibitch-class clients to a version which would split a users coins between forks in such a way that was not to the user's advantage (by formulating spends in a certain way.)
Alert keys seem like a likely place for a broad range of participants to exercise some control. I could imagine, say, half a dozen of them chosen from a pool of core contributors as well as other actors. Some by user vote even. When an alert is issues, each key would be represented as being pro, con, abstaining, or absent. This could be represented compactly in a GUI as a little color widget or some such. In this way users could see at a glance if there were universal consensus about the nature of any alert.
I've heard it said that this is a non-problem because alerts have not been abused to date. To this I would say that certain very possible attacks have also not been seen to date so it is not a totally valid argument.
|
sig spam anywhere and self-moderated threads on the pol&soc board are for losers.
|
|
|
achow101
Staff
Legendary
Offline
Activity: 3542
Merit: 6886
Just writing some code
|
|
August 30, 2015, 06:32:59 PM |
|
Gavin currently holds the alert key to Bitcoin Core. Am I correct to presume he also holds the alert key to XT? So both?
Who is confirmed/unconfirmed having the alert keys to Core?
I want to press this issue since it seems to have fallen through the cracks, especially since Gavin's allegiance is clearly with XT. Also, I wouldn't put it past Hearn to try to get the Core alert key from Gavin.
The alert key for the entire bitcoin network is the same, so that includes XT. Confirmed to have the alert key: Gavin Andresen, Theymos, Satoshi Nakamoto, Gregory Maxwell Not confirmed but probably have the key: Wladimir J. van der Laan, Jeff Garzik, Pieter Wuille Also, please note that there will not be a definitive list of everyone who has the alert key for their own personal safety as well as to prevent attempts to coerce key holders.
|
|
|
|
MarketNeutral
|
|
August 30, 2015, 06:41:28 PM |
|
Gavin currently holds the alert key to Bitcoin Core. Am I correct to presume he also holds the alert key to XT? So both?
Who is confirmed/unconfirmed having the alert keys to Core?
I want to press this issue since it seems to have fallen through the cracks, especially since Gavin's allegiance is clearly with XT. Also, I wouldn't put it past Hearn to try to get the Core alert key from Gavin.
The alert key for the entire bitcoin network is the same, so that includes XT. Confirmed to have the alert key: Gavin Andresen, Theymos, Satoshi Nakamoto, Gregory Maxwell Not confirmed but probably have the key: Wladimir J. van der Laan, Jeff Garzik, Pieter Wuille Also, please note that there will not be a definitive list of everyone who has the alert key for their own personal safety as well as to prevent attempts to coerce key holders. Thank you. I understand all of this except for the XT part. If there is a hard fork, perforce creating two separate chains and thus two competing cryptocurrencies, will the alert key remain the same for both, such that Theymos could issue an alert on XT? Surely there's code in XT that creates a new alert key or alert mechanism. I understand that presently both Core and XT are the same blockchain, but if there is a hard fork, then what? Both parties have mutual access to each other's alert keys?
|
|
|
|
turvarya
|
|
August 30, 2015, 07:00:15 PM |
|
Gavin currently holds the alert key to Bitcoin Core. Am I correct to presume he also holds the alert key to XT? So both?
Who is confirmed/unconfirmed having the alert keys to Core?
I want to press this issue since it seems to have fallen through the cracks, especially since Gavin's allegiance is clearly with XT. Also, I wouldn't put it past Hearn to try to get the Core alert key from Gavin.
The alert key for the entire bitcoin network is the same, so that includes XT. Confirmed to have the alert key: Gavin Andresen, Theymos, Satoshi Nakamoto, Gregory Maxwell Not confirmed but probably have the key: Wladimir J. van der Laan, Jeff Garzik, Pieter Wuille Also, please note that there will not be a definitive list of everyone who has the alert key for their own personal safety as well as to prevent attempts to coerce key holders. Thank you. I understand all of this except for the XT part. If there is a hard fork, perforce creating two separate chains and thus two competing cryptocurrencies, will the alert key remain the same for both, such that Theymos could issue an alert on XT? Surely there's code in XT that creates a new alert key or alert mechanism. I understand that presently both Core and XT are the same blockchain, but if there is a hard fork, then what? Both parties have mutual access to each other's alert keys? There is no new alert mechanism in XT. The alert is for the bitcoin network not a specific client. A fork doesn't change anything about that(unless it is a fork, exactly for that and I am not aware of any fork proposal for that)
|
|
|
|
MarketNeutral
|
|
August 30, 2015, 07:17:40 PM |
|
Gavin currently holds the alert key to Bitcoin Core. Am I correct to presume he also holds the alert key to XT? So both?
Who is confirmed/unconfirmed having the alert keys to Core?
I want to press this issue since it seems to have fallen through the cracks, especially since Gavin's allegiance is clearly with XT. Also, I wouldn't put it past Hearn to try to get the Core alert key from Gavin.
The alert key for the entire bitcoin network is the same, so that includes XT. Confirmed to have the alert key: Gavin Andresen, Theymos, Satoshi Nakamoto, Gregory Maxwell Not confirmed but probably have the key: Wladimir J. van der Laan, Jeff Garzik, Pieter Wuille Also, please note that there will not be a definitive list of everyone who has the alert key for their own personal safety as well as to prevent attempts to coerce key holders. Thank you. I understand all of this except for the XT part. If there is a hard fork, perforce creating two separate chains and thus two competing cryptocurrencies, will the alert key remain the same for both, such that Theymos could issue an alert on XT? Surely there's code in XT that creates a new alert key or alert mechanism. I understand that presently both Core and XT are the same blockchain, but if there is a hard fork, then what? Both parties have mutual access to each other's alert keys? There is no new alert mechanism in XT. The alert is for the bitcoin network not a specific client. A fork doesn't change anything about that(unless it is a fork, exactly for that and I am not aware of any fork proposal for that) Thank you. I understand this. Bitcoin has had hard forks in the past. Nothing changed with alert keys. I get it. I am well-versed in the technical side of bitcoin. However, I am probably not asking my question the right way. Instead of asking dumb hypothetical questions to lead the discussion, I'll say it plain. The responsibility of knowing the alert key and the political ramifications thereof seems to be off the radar in this discussion of XT vs Core. I'm pressing the issue of alert keys, because I see them as a potential object of a further power struggle between the two factions. The person who gives an alert key agency should be one whom the bitcoin community, devs, and merchants trust. To many people, Gavin has betrayed that trust. Further, although potential brinksmanship, retaliation, or retribution seems improbable, this is a 4 billion dollar market we're dealing with, as well as people's livlihoods, families, and egos. Moreover, is this not a good time to establish clear criteria regarding the mechanism by which one is entrusted with the alert key? And why does Gavin still have such authority?
|
|
|
|
|