Every time someone asks "Why do we need [altcoin] when we have bitcoin?" I'm reminded of the disturbing bitcoin-related proposals like blacklisting. If bitcoin goes down that road, and [altcoin] doesn't, I can see a lot more people making the switch.
As of now, none of the altcoins implement protocols that would protect them from such blacklists, so any sort of safe haven would only be temporary or otherwise imagined. |
|
|
|
Wow, interesting revelations. I always knew the dev team was divided, but this runs a special sort of deep. Very intrigued by the revelations about libbitcoin, always was concerned about that just didn't know why. They have the chance to turn the tides but it seems they are getting on the wrong train. That's a shame. As a matter of fact, user BCB was caught tracking in the same thread jdillon was posting in, so there is your first nugget. Jdillon a fed with something to hide, this could be very bad for you. Please be safe. |
|
|
|
In the past most threats against the Foundation have been idle (imo), but even now I get a very bad feeling in my stomach about this. I wouldn't be surprised if we start seeing the BF forums get DDoS'd, defaced, among other things. Given the poor standing of other notable members (see: Peter Vessenes), the future of the Foundation is very fragile. Yes they pay Gavin, but that's only because we accept their changes and update our software. If we stop doing that and fork QT, the need for them diminishes quickly. It would be in their benefit to remember that.
the Foundation who has claimed to champion the fungibility of the protocol.
You know you can simply create a github account and start contributing? (right here: https://github.com/bitcoin/bitcoin, behold the Fork button) Like many others in this community you make it sound like forking the code is some grandiose act of rebellion. But it's simply how open source works. No need to BF member, or go through a secret core dev initiation ritual. Seriously, we can use more active contributors for Bitcoind/-qt. Get involved! Stop complaining, start coding (or as Erik Hughes wrote in his manifesto in 1993: Cypherpunks write code). Forking the code is not a threat to anyone. Don't confuse it with forking the blockchain. Complaining? lol, cmon dude get over yourself. I was just speaking my truth in a discussion based forum, no need to get all wrapped up in the emotions of it. And yes I am aware we are just one good fork away from a break off from the BF. Their version of QT is the one featured on bitcoin.org, which is what I was getting at. Thanks for the vote of confidence though. Oh and if you were going to bother responding to this post, don't. |
|
|
|
|
Whatever you do, base it not in rhetoric but in code.
You can't stop the Foundation from meeting with regulators at this point. That shipped has sailed. However, if you disagree with changes they make to the protocol you can have the code be your protest; disable and otherwise hinder redlisting efforts, etc...
But just imagine if the Foundation dissolves, who talks to the government? Someone has to; whoever takes their place probably won't have a private forum you can peruse and speak your mind. We might not even know who they are.
So what's that saying about keep your friends close your enemies closer...
|
|
|
|
Yes they pay Gavin, but that's only because we accept their changes and update our software. If we stop doing that and fork QT, the need for them diminishes quickly. Gavin doesn't need BF to get paid. He could open a ReDonate account tonight and get enough people to sign up to support whatever salary requirement he has. I like you, let's be friends. Question is whether or not Gavin would be willing to break away from the Foundation. Hint: the answer is [probably] no. Maybe this is all part of Gavin's scheme. He's said before that he is in favor of a heterogenous network composed of multiple implementations - perhaps Bitcoin Foundation's job is to piss us all off and get people to take a serious look at btcd and Bits of Proof. I wonder what it would take to make Armory work with btcd instead of bitcoind... Well, I am always reminded of this post by satoshi: I don't believe a second, compatible implementation of Bitcoin will ever be a good idea. So much of the design depends on all nodes getting exactly identical results in lockstep that a second implementation would be a menace to the network. The MIT license is compatible with all other licenses and commercial uses, so there is no need to rewrite it from a licensing standpoint. Although there are so many scenarios Satoshi could not have been expected to plan for. I've always been a fan of alternative implementations although they must be maintained and tested with utmost care and precision. |
|
|
|
Yes they pay Gavin, but that's only because we accept their changes and update our software. If we stop doing that and fork QT, the need for them diminishes quickly. Gavin doesn't need BF to get paid. He could open a ReDonate account tonight and get enough people to sign up to support whatever salary requirement he has. I like you, let's be friends. Question is whether or not Gavin would be willing to break away from the Foundation. Hint: the answer is [probably] no. |
|
|
|
I like Peter Todd's response the most: When you are chair of a position you have to accept that you no longer are speaking for yourself, especially when you are specifically talking about an idea positively and in relation to setting official policy. In bureaucrat speak, that's promoting an idea, and given his other posts he's promoting it pretty heavily.
You know I mentioned this debacle today to someone I know who is a high-profile government bureaucrat. They read jdillon's initial post and their response was pretty blunt: the fact that this blew up as quickly and as big as it did by itself indicates that Mike doesn't know what he's doing.
....
An important part of not being disorganized on the inside is accepting common principles - there is rough consensus that fungibility and privacy is important and that blacklists and coin taint are bad ideas. Given that the first few times the idea has come up it's been thoroughly shot down a good committee chair would put their personal opinions aside, and work with that consensus to figure out how to best implement it into policy that was accepted by the community and achieved the goals of the community. Instead Mike is pushing a very minority opinion and is wasting his time and credibility.
Now if Mike did want to fix this situation he could do so very easily: Just say that while his personal opinions differ, as chair he accepts that the community is strongly opposed to any form of blacklist, redlist or whatever is the latest name applied to them, and in his official capacity will respect that and will honestly work towards policy that reflects those desires. I think it's time for Mike to reconsider his role. Even if the redlisting thread was just a thought experiment/discussion, he should have known better. The Foundation (and Mike) have done quite a bit in the past to piss off the community, but I think these most recent events could pose a real problem for the Foundation moving forward. In the past most threats against the Foundation have been idle (imo), but even now I get a very bad feeling in my stomach about this. I wouldn't be surprised if we start seeing the BF forums get DDoS'd, defaced, among other things. Given the poor standing of other notable members (see: Peter Vessenes), the future of the Foundation is very fragile. Yes they pay Gavin, but that's only because we accept their changes and update our software. If we stop doing that and fork QT, the need for them diminishes quickly. It would be in their benefit to remember that. And while I do believe there is a certain level of overreaction here, there is no doubt Mike (and others) are in support of this idea--whether or not they are willing to openly admit it anymore is another question. Redlisting was always going to happen, question was who was going to push the idea and implement the software. Never did I ever think we would see something like this from the Foundation who has claimed to champion the fungibility of the protocol. |
|
|
|
Again you are giving the foundation too much power.
Mod Edit Note: Shove your tracking pixel up your ass, BCB. Cheers, Raoul Duke
BCB, you're going to have to answer for this. Care to explain? |
|
|
|
This is what I thought too, but now I am looking closer and it appears that Forbes may have misrepresented the tech. Read Alex's reddit posts from the previous day: http://www.reddit.com/user/alex_waters : He probably is spinning PR or focusing on short-term implementation plans to avoid discussing the longer term plans discussed in the article. If you read it with the PR-interpretation mindset its not so good. Whatever his intentions, he is not thinking through the implications or just selfishly doesnt care for quick buck reasons, I dont know him so I cant tell. Either way I think this will not end well. I've been in the privacy tech / crypto business for 15 years, its quite common to encounter and have to navigate around people of all stripes: well meaning, neutral, dont care, and anti-privacy. Even the ones that are neutral or well meaning often dont think about the long or even mid-term implications of what they are doing. Thinking about implications is complex, requires concentration, deep understanding across many fields, and may conflict with short term objectives (ie rush something ill-thought-out but "pragmatic" to get something out the door). Sometimes making a buck even conflicts with user interests, or even the survival of the system. Some of these people might even show concern and genuine remorse afterwards when it predictably blows up (to their genuine surprise because they didnt think more than the first chess move.) Most probably though they'll be onto their next venture and pretend it never happened or more likely not even make the connection between their actions and the outcome. The technology space is littered with implications from ill considered decisions. Eg web pages are not signed, and jscript is not signed; a single server key is used for combined tunnel auth/encryption but no transferable signature on the content. So people can hack servers and modify and replace code and steal eg jscript bitcoin wallets. These things matter because architecture defines the internet. “We don’t want to be the sheriff of the Bitcoin community. We just want to create an ecosystem of clean addresses.”
So first they want to identify clean addresses (from the forbes article). Please stop confusing "clean coins" with KYC'd Bitcoin addresses. And then they want to distance themselves from clean addresses (from reddit). So whats a clean address? Its one that according to them has not got taint on it according to some threshold they decide against some blacklist. Seems squarely what we are talking about. Thats my interpretation. Waters or the other people at CoinValidation are welcome to clarify. It is beginning to sound a bit more like what you proposed Adam.
The KYC part yes, the clean coins I am not so sure - they really do seem to think longer term that tracing coins is somehow a useful thing to do, which can only harm fungibility. We may need a priority deployment of CoinJoin option into multiple clients before they get far with that. DarkWallet could probably do with some funding help also. Adam Thank you for that thoughtful analysis. There are clearly mixed signals being sent; given their limited response it appears that they may purposely disseminating varying information to create a smoke screen while they speak with the DHS. Either way, like you I am deeply concerned and the community response to this will make or break this moment. Interesting times ahead; this is good that this is happening now, we need to face these hurdles. |
|
|
|
The mixing application described in the OP uses same valued outputs And I believe that drastically reduces its usefulness. It's fine as an academic exercise but how people actually use their bitcoins in the real world is considerably more messy. Unless you can handle situations where the users need to mix differing amounts of coins you'll either degrade the mixing to uselessness or else end up with a double coincidence of wants problem where nobody can find suitable partners top mix with. Yea, and to that effect there should be a step prior to the CJ where outputs are made uniform. |
|
|
|
I'm disappointed that Mike Hearn would advocate for the use of blacklists, tainting and reduced fungibility of bitcoin . As one of the significant members of the The Bitcoin Foundation, he has the ability to make this kind of scheme a reality. For someone who just went on a rant against the NSA for violating Google's privacy, this kind of betrayal of the bitcoin user's privacy is really heinous. Who will dictate what constitutes a crime? Who will dictate when a bitcoin will no longer be listed? I doubt that he's given much thought to such questions beyond "whatever the police say", which, in this current political climate, is a very ignorant stance. I suggest those who want to keep bitcoin a viable and fungible currency let Mr. Hearn and all of the The Bitcoin Foundation members know that this idea should not be implemented and produce policy positions rejecting it.
I opened a new topic on the Bitcoin Foundation's forum: Deep concern about the foundation's chairman of Law and Policy (Mike Hearn) pushing for coin taint Me, and many others in the bitcoin community are deeply concerned about Mike Hearn pushing for coin taint. We feel that if the Bitcoin Foundation is even going to consider mentioning this in the upcoming government meeting, that we can no longer stand behind them. This is serious. Coin taint is even worse than increasing the 21 million limit. Since the chairman of Law and Policy is involved here, I would like to call for a vote against this, and a clear stance from the Bitcoin Foundation. I know many of the board members are supporters of mixing coins even more, so something like this can never happen again. It would be a good message to the bitcoin community to confirm that the foundation supports keeping coins anonymous, instead of going in the opposite direction. Thank you, please keep us posted. |
|
|
|
All previous addresses that received the coin are listed on the public blockchain ledger. From what was said I believe Coin Validation plans to look at the history of the addresses associated with coins. If your coin was used 10 transactions ago by a silk road user, (eg seen entering the silk road address) then likely implications are you will not be able to spend your coin on any site using their system.
They hope it will be viral, ie because you dont want to hold coins you cant spend, you may also refuse to accept coins they do not white list. Having them validate your coins will not be free and the uncertainty arising from not knowing if your coins will suddenly become less spendable will create fungibility problems.
This is what I thought too, but now I am looking closer and it appears that Forbes may have misrepresented the tech. Read Alex's reddit posts from the previous day: http://www.reddit.com/user/alex_waters : we're not planning on tracking coins... so go ahead and send coins to those coins  As mentioned above, if there were "clean coins" and "unclean coins" - we would quickly run out of clean coins. That is a ridiculous model that we have worried about for some time, and its advent is likely impossible.
It is very easy to taint "clean coins" with the current protocol - so that would be a fruitless endeavor to pursue.
Please stop confusing "clean coins" with KYC'd Bitcoin addresses.
I agree, KYC Bitcoin addresses != blacklist.
I think the quote you are referring to, and the one that has people upset is somewhat out of context. We are not looking to create a distinction for clean / unclean coins or even clean / unclean addresses for that matter. It is simple as you stated, creating a list of known addresses. This is something that has been thought about and worked on for years. BIP 15 https://en.bitcoin.it/wiki/BIP_0015 is an example of how much this has been thought about. In fact, Satoshi himself originally thought about using IP addresses as an alternative to Bitcoin addresses, and it existed in the client for some time. There was even some work done by some prominent core devs to explore using DNS or email addresses in conjunction with or as an alternative. Ultimately the new payment protocol was developed: https://bitcointalk.org/index.php?topic=300809.msg3225143#msg3225143"Is this just about creating known addresses?" Yes "Let's say I buy some coins on an exchange, and a couple hops ago they passed through some illicit site's wallet. Does your system track that?" No "Am I going to be able to spend my coins with a company using your system?" Yes, I hope so "Do I just have to send them to my personal known registered address first?" Probably, depending on how strict the company receiving them is about receiving coins from KYC'd addresses. It is beginning to sound a bit more like what you proposed Adam. |
|
|
|
Thanks so much. What a scary thread, there are a suprising number of foundation members in support of this idea. They are clearly out of touch with reality; it seems the power is getting to their heads. Like somehow it is up to them to decide. It's moments like these when I remember that it only takes one bad decision to make the value of Bitcoin plummet forever. People thought Bitcoin was THE cryptocurrency... looks like that won't be the case. We need something with absolute fungibility, blind sigs and homomorphic encryption really is the only way forward now.... |
|
|
|
Alex Waters has not worked for BitInstant for a long time, you should take that down. He helps run the Apex Incubator as far as I'm aware. edit: source, i've met him in person. also his linkedin: www.linkedin.com/pub/alex-waters/10/605/29b |
|
|
|
One way I can see to avoid that is a convention where outputs are always a standard size (integer powers of two, for example).
I like this idea, although enforcing it network-wide might have other implications (or maybe not, I'm not sure). A script could be written to easily condense a users outputs prior to a CJ tx, so gmaxwell's original design can be followed: To use this to increase privacy, the N users would agree on a uniform output size and provide inputs amounting to at least that size. I think Peter Todd wrote something that cleans out dust, you could just rework that to accomplish the above methinks. |
|
|
|
Do you think this idea could work for Mastercoin under the context of user issued redeemable cryptocurrencies?
I will watch this.
Yes absolutely. It would for effectively any color coin implementation. |
|
|
|
Satoshi had a point. He hasn't been here for some time, and his comments were relevent to the state of Bitcoin at that time. The main client was still, itself, very rough. Very much still beta. IT's also a monolithic implimentation. Which is fine for early work.
We are beyond early work. I have long complained that the main bitcoin client didn't have simple unix like tools. Libbitcoin seems to intend to be that set of unix tools. I want to be able to pipe a transaction to a file, move it with a usb sneakernet, and pipe it to the bitcoin network on another machine. I want a client that can do this for me, automaticly. I want a client that I can create the keypairs on one machine, and manage the funds on a headless server half way around the world, without either of those machines even knowing the IP address of the other. I want an online wallet service client that can logic bomb my funds onto the bitcoin network if tripwire is activated. If the tools exist to perform each of the simple operations that the bitcoin client performs; then clients that can do a great many things can be developed to suit small group needs.
Very good points. I am in agreement in many respects; I think modular nodes are vital (see: Bits of Proof). We can't wait for the core devs to do everything, that's not fair. We just need to make sure we are very careful and meticulous in our preparations... |
|
|
|
Yes, such a method was proposed in the Bitcoin Banknote scheme by Sergio. I like both ideas, although your solution works outside of the dollar bill scenario. |
|
|
|
You guys are so quick to jump down ex-trader's throat. Slow down.
Yes this question has been posed many, many times, but the point still remains: the business model cryptocyprus is trying to pull off is HARD, and trading your way through heavy dips in price will be a site to see.
Even if they have what they think is a successful trading model (which they won't share because it's their secret sauce), there is still the possibility they will not be able to handle what they thought they could. Point being, pegged accounts are not a sure bet, no matter how good of a trader you are. This is a scary proposition, so no amount of spreadsheets with possible scenarios should quell the prudent investor.
People have to understand this business is a bet on 2 things: A - Bitcoin's growth and B - A bet on the future of banking You get exposure to both these 2, shooting two birds with one stone. Ofc if A fails B will fail also, unless Neo uses some ace day traders that could make money in both bull and bear market playing the charts and using huge chunks of money to get the upper hand. Right but Bitcoin can still survive extreme lows. Whether or not NEO can is another question entirely.... |
|
|
|
|
Show Posts
