A viable alternative to order-based coloring is embedding meta-info into a scriptPubKey.
The most straightforward way to do this is OP_DROP message, but there is a rather elegant approach which uses already standard multisig transactions:
No, that is the opposite of elegant: it adds blockchain bloat that is difficult to recognize or avoid or prune. |
|
|
|
On the contrary: colored bicoins are bitcoins, transactions with them are indistinguishable from normal bitcoin transactions. There is no way it can screw the bitcoin blockchain.
OTOH merged mining has to embed its meta-info into blocks... It's literally about screwing with blockchain.
Not sure "screwing with the blockchain" is accurate or fair. Merged mining is preferable to colored coins, because you do not bloat the blockchain with person-to-person property transfers. However, colored coins offer the unique advantage of being automatically swapped for bitcoin payment. It is a trade-off. Merged mining is far more scalable, and many discussions about creating a "data chain" for timestamping have been discussed. |
|
|
|
Interesting stuff. I have considered writing own pool, but experimenting with 50 BTCs per block doesn't sound very tempting. I guess a quick approach would be running multiple instances of pushpool in multiple virtual machines until a more reliable pool shows up.
You could experiment on testnet, or use testnet-in-a-box. |
|
|
|
If you want to check and see if you have corrupt files on disk, you may start with -checkblocks=0 -checklevel=6
Stopping and restarting the client will freshen the set of peers, in case you are stuck on something network-related. Watch debug.log for progress (or lack thereof). |
|
|
|
This is not a mass-market solution. Lack of a dirt-simple, secure way of keeping your coins seems to me the biggest bottleneck to bitcoin adoption, unless trusted online wallets take over as the primary storage method.
Bleh, hopefully a centralized solution like "trusted online wallets" is not preferred over a safer, more decentralized solution. If the coins are not easy to store in a safe, decentralized manner... blame us! Keep the heat on. We need the best user experience possible. Ideally you want to make it hard to not store your coins securely. |
|
|
|
|
WRT Tor and anonymity, it is still not easy:
1) Protocol fingerprint shows you are using the bitcoin protocol
2) If coins are not mixed perfectly, you can be vulnerable to network analysis.
|
|
|
|
In other words, TBF users vote as a bloc.
Centralized, privacy killing, often hacked website users do too. They hand their votes, in big thick metaphorical bundles, to the website operator. What do you think is the result of creating obstacles to improvement and distribution of the decentralized client? People will switch to easy-to-use websites and forget all about that silly decentralized nonsense. I would rather see focused resources put towards scaling the Satoshi client, keeping the network running under the strain of doubling data volumes and completing the Satoshi vision with SPV mode. Seeing the scalable Satoshi client (or compatible client!) in the hands of as many people as possible is the only way to ensure bitcoin's survival and thus the only way to ensure bitcoin's monetary freedom remains with us. |
|
|
|
What does the protocol design say is possible? What the majority of users want. If the majority of users want IP tracking and a 400M coin limit, that is what bitcoin becomes.
I wager the majority of bitcoin users will actively and fervently resist any such changes. At least I hope so.
Relying on hope is not such a great plan.. And yeah I would, in a heart beat. That's the best we have. All systems are ultimately human systems. Bitcoin is just another system for humans voting on something. Bitcoin works without central authority, but only by replacing that with mob rule... with all that entails. Why do you do think we have code to spread network connections as widely as possible, guard against Sybil attacks and the like? The entire blockchain (your money) is only as safe as the voting procedure (network peer selection). I'm, sadly, even considering it right now because of the Bitcoin Foundaton.
Well, that is disappointing... but we are open to suggestions! What is a sustainable way to help fund devel, testing, network defense, security patch response, etc.? Bounties fail. KickStarter-like provides unpredictable bursts. Anonymous donations are a beer-money tiny trickle. Self-supporting through for-profit ventures steals developer focus and introduces clear, direct conflicts of interest (as opposed to indirect conflicts of interest through a trade association). On the other hand, voluntary visible donations through neutral trade organizations are a well worn path. What are the other realistic, sustainable alternatives are available? Maybe you haven't been paying attention to the wonderful stats that dooglus and others have been posting, but we need some serious engineering to avoid incentivizing users away from the P2P clients and towards centralized, privacy killing websites: - One single gambling application has doubled the size of the blockchain in the past 4-6 months
- The reference client, the "full nodes" keeping the network alive, is feeling the strain
- A punishing blockchain download may incentivize users away from P2P clients, towards easy-to-use websites
- Resultant P2P node counts decline, reducing decentralization factor
We are racing to implement ultraprune and other changes to address some of the scaling issues. But the most important part of Satoshi's design, the part that keeps the network scaling further -- SPV mode -- was only lightly sketched by Satoshi. SPV mode enables anyone to be a fully decentralized P2P client, even on your mobile phone. It is a race to fully implement the decentralized design, otherwise users will simply not bother with apps at all and go straight to mtgox.com or instawallet.org or blockchain.info. And even that is a race, to "seed" bitcoin across the world, making sure it is sufficiently entrenched before the inevitable legal and governmental and central banker push-back. So frankly I do not think many critics in this thread even comprehend the Clear And Present challenges looming, just to keep bitcoin alive and decentralized. The critics here are worrying about phantoms, tilting at windmills, while missing the freight train heading straight for you. Every objective measure shows that Gavin and the rest of the devs are working as hard as we can to keep decentralization in your hands. The Bitcoin Foundation is the only entity that has stepped up to the plate with some real solutions that can help us complete the Satoshi design and scale beyond the next 12 months. A truly decentralized solution, the private free market at work. If you don't like it... fix the problem! Start another foundation, and fund the dev team 50% matched with BF. Or figure out another, more creative solution to solving the problems listed above. |
|
|
|
Exactly. You're right that gitian is a helpful tool, actually. But it still doesn't account for naive non-tech savvy users - the majority of users.
Yes it does -- see the previous "Aunt Tillie" example. |
|
|
|
I don't think people here misunderstand that the tool chain has controls to prevent secret or malicious code change. I just don't don't think it is enough.
You're right -- it is the community associated with the software that is vigilant. The tools just help with the vigilance. |
|
|
|
Every git (or gitian, if binary) user around the world would instantly see the "secret" change.
We're not talking about ONLY using systems as they are SUPPOSED to be used. We're talking about malicious intent, like the illegal wiretaps I talked about earlier. How many users download Bitcoin from Git? They don't. They go to a site like Bitcoin.org. In a "Bitcoin Foundation" world they would likely go there since it's the "official representation" of Bitcoin. Now once a user is downloading a file from your site, how hard is it to give select users select files? Google "gitian", please. |
|
|
|
Two years down the road the Bitcoin foundation will say jump, and the community will ask how high, how will you prevent this scenario from playing out?
The devs would probably quit BF, I imagine. What does the protocol design say is possible? What the majority of users want. If the majority of users want IP tracking and a 400M coin limit, that is what bitcoin becomes. I wager the majority of bitcoin users will actively and fervently resist any such changes. At least I hope so. (of course, if the majority of users wanted IP tracking or currency supply inflation, per manifesto I would quit bitcoin in a heartbeat, and hope you would too) |
|
|
|
Or language to this effect as lawyers find suitable to ensure secret changes aren't given to programmers and then compelled to be implemented via fear of job loss.
Secret changes do not occur in the current system; that is the part being missed. Every git (or gitian, if binary) user around the world would instantly see the "secret" change. |
|
|
|
I'm very interested in being a part of this aspect of things. I've worked in software QA (admittedly primarily video game related) for over a decade, and would love a chance to work on helping secure bitcoin software. the thought hadn't ever crossed my mind, or i'd have already been doing so.
who should i contact regarding this?
The bitcoin-development mailing list at http://sourceforge.net/projects/bitcoin/ currently has a thread discussing bitcoin testing. We welcome -- and need! -- more people testing the software. |
|
|
|
Government pressure does not change that. Government pressure cannot magically compromise SHA256 or ECDSA -- that's the whole point of the system.
Now, see? This is what hazek means by indirect answers. Did I ask anything about the bitcoin design? You of all people know that if you can get a user to run an executable file on their computer you now own everything on the computer, and once that computer connects to the Internet, then you own that computer from anywhere in the world including executing more instructions. How are we not connecting? You guys keep pointing to things like protocols and bylaws. That's NOT where our concern lies. Those things mean basically NOTHING in the day to day world. Bitcoin design was the answer, because bitcoin design is directly relevant to why these fears are unrealistic, paranoid fantasies. Satoshi created a design that enables open review, and gitian enhances that with provable binaries. Any "government pressured" back-doored executable file would be immediately noticed by the community, with cryptographic certainty. Aunt Tillie might wind up downloading bitcoin-paranoia.exe, but soon all hell would break loose, and forks would appear immediately. Users would vote against bitcoin-paranoia.exe with their feet. It is a self-correcting system. How are we not connecting? You guys keep pointing to things like protocols and bylaws. That's NOT where our concern lies. Those things mean basically NOTHING in the day to day world.
That's the beauty of Satoshi's design: they do. If a judge or a man with a gun orders someone to add IP tracking, the system is designed to make that immediately apparent, and route around that. |
|
|
|
Such non answers and trickery..
The system works how it works? How about with an answer like "Yes the system works where change is possible, especially backwards compatible change like BIP16, so yes theoretically we could make rules stricter to include an IP address with every transaction and if we got enough mining support there wouldn't even be a hard fork necessary. You are right that is a problem."
And the community would reject any version that added such IP tracking. As they should. Each user's use of bitcoin software is a vote to accept or reject changes. If community does not like the changes coming down the pipe, they won't use them! Every single change is public, out in the open for inspection. The process for firing Gavin and any other dev is therefore simple. git and gitian guard well against "include an IP address with every transaction" back doors. |
|
|
|
The Foundation's core values include openness and transparency. I think the Bitcoin anonymous thing is overblown and a bit of a myth, by the way. Every bitcoin transaction links two addresses; often people can be determined from those addresses.
At any rate, we wish to make sure you can't stuff the ballot box during voting, and we wish civil productive discourse among our members, so we need real names and addresses.
If you just want to support us without joining, you can always send money to our vanity donation address: 1BTCorgHwCg6u2YSAWKgS17qUad6kHmtQW The important part is in bold, it suggests that people using Bitcoin should not expect privacy at all. Read https://en.bitcoin.it/wiki/AnonymityWhat is dangerous is telling an activist in an authoritarian country "bitcoin is anonymous" without further detail. They believe you, and then get arrested or worse. Satoshi never claimed bitcoins were anonymous. They are pseudonymous, and with a lot of work, can be mostly anonymous. |
|
|
|
Are you familiar with what happened at 611 Folsom Street in San Francisco? Let me give a brief overview. President Bush instructed phone companies to allow an illegal warrant-less wiretap be installed at this location and others recording ALL Internet traffic unfiltered, which a whistle blower found out about. The administration then had Congress retroactively grant the phone companies immunity from prosecution for siding with them in breaking the law. https://www.eff.org/issues/nsa-spyingAs a U.S. corporation that openly develops the software to conduct bitcoin transactions, how would the foundation deal with similar government pressure to "save us from the terrorists, pornographers, government anarchists, etc"? The bitcoin design permits what it permits, and prevents what it prevents. Government pressure does not change that. Government pressure cannot magically compromise SHA256 or ECDSA -- that's the whole point of the system. The system works how it works. |
|
|
|
This is an interesting idea. However I don't see how it makes a distributed exchange possible. The hard part is keeping track of buy/sell orders and colored coins don't do anything for that.
You're right that colored coins alone do not enable the tracking of buy/sell orders. The distributed bonds example describes how an added layer would enable this. Distributed bonds are just a special type of colored coin; the concept is the same. |
|
|
|
Oh and let's be precise. The plan was never openly discussed, just Gavin's intentions or wishes. The plan was formulated and executed in private and this is a fact which you admit.
Yes, let's be precise. You go first. "The plan"... what, precisely, was done in private and unexpectedly? That a foundation was actively moving forward? (including selection of board members and setting up a corporation, discussed between a select few?) In October, it was written "Assuming there is rough consensus that a Bitcoin Foundation is a good idea, I would like to get something imperfect up and running quickly, with the expectation that it will evolve over time." |
|
|
|
|
Show Posts
