I've argued with Luke before on this obsession of his, your never going to go mainstream with something that dose not give people DURABLE identities. Disposable identities are never going to fly in mainstream commerce where law enforcement must be conducted. Also you have the grandmother factor at work here, a users needs a durable identity to give to other people and they can barely handle the technical hurdles of BTC as it is now. This kind of secrecy and techno-elitist obsession will always fail.
Maybe you can use grandma as a hostage against privacy preservation today, but there are projects in the works to make anonymous commerce just as safe (or safer) as non-anonymous commerce, in a grandmother-friendly way. After that's done, law enforcement can shove their desire to spy on everyone and everything up their ass. |
|
|
|
Thin wallets like Electrum and blockchain.info retrieve UTXOs from server, and cost for server is roughly proportional to number of addresses used, so address re-use improves efficiency. Are you against that?
Are you saying that address reuse makes the UTXO set smaller? |
|
|
|
|
For those who haven't figured it out yet, Come-from-Beyond is a troll. Everything he says is the opposite of what is good for Bitcoin.
|
|
|
|
Pretty embarrassing that the Bitcoin ecosystem can't keep up with a couple year old feature.
This, I don't want to make this off-topic cause coinjoin is a great feature, but P2SH is also another important feature. I am surprised Armory doesn't support it since it uses the bitcoind/bitcoin-qt as a backend. To what extent I don't know but it should be easy to add at least sending to that type of address. Yes, I've resisted updating the interface to support this because changing the supported address formats without exhaustive testing can lead to money-losing bugs. The change is, at its core, quite simple. But making sure it's integrated correctly is not.
After 0.90 is released, I'll do the upgrade to support sending to P2SH addresses for 0.91. When I finally implement multi-sig in the wallets, I'll make sure that the interface works with it naturally. |
|
|
|
https://twitter.com/matthew_d_green/status/401798811070107648We designed a new version of Zerocoin that reduces proof sizes by 98% and allows for direct anonymous payments that hide payment amount. Is a 98% reduction in proof size enough to overcome any existing valid reasons to not merge ZeroCoin functionality?
|
|
|
|
Figuring out how to construct CoinJoin transactions is just the first step in having a usable system. The rest of the work is the nuts and bolts of how users actually find suitable mixing partners. Based on how users are likely going to want to employ CoinJoin, there are going to be two general classes of clients: - Opportunistic clients which are configured to wait for suitable conditions and perform mixing in the background. These will necessarily be clients where the private keys are stored on a online machine. Mixing is not time sensitive at all for them.
- Immediate clients who want to use a CoinJoin transaction to send bitcoins. They need to be able to complete the protocol quickly, within a few seconds, because they using an Armory-style offline wallet where they need to save an unsigned transaction to a suitable medium, cross the air gap, sign the transaction, and broadcast it all before the BitPay timer runs out.
In order for the immediate clients to be able to operate, you need a lot of opportunistic clients. Also, some of the opportunistic clients will be FBI honeypots, so there's that too. Right off the bat, a CoinJoin negotiation protocol should be work over Tor. The TorChat system is a good model for this - they actually bundle a Tor binary directly into their application so that a TorChat user doesn't need to download, install, and configure Tor separately. They also use the hidden service URL as a user name, which means you don't need some additional name mapping system. It's too bad the Tor project hasn't separated their core functionality library into a library that could be used by third-party applications, despite repeated calls to do so. Perhaps CoinJoin clients could just work through the libpurple plugin for TorChat. Once the clients all meet up, they need a way to negotiate parameters like output sizes. If an immediate client wants to use CoinJoin for a purchase, it's not likely that any other immediate clients are going to have the exact same output size needs, so they'll have to rely on opportunistic clients who have specified a compatible range of acceptable output sizes. tl;dr: Clients need a protocol by which they can register their willingness to participate in a CoinJoin, and any relevant constraints which determine who is and is not a suitable partner, over a secure channel (because even though you might theoretically do it in the clear, people who want CoinJoin are also going to want to have IP address-level privacy too). |
|
|
|
Bitcoin: Gold Standard backing the future of money
Litecoin: Silver standard, regular use currency. a wish fulfilment fantasy for CPU GPU miners
Namecoin: Public ledger, internet routing
Open Transactions: Business transaction service, safety net interim solution for smart contracts until its features are folded into Bitcoin
Ripple: Decentralized liquidity system, barter exchange The next PayPal
Bitmessage: safe communications protocol FTFY |
|
|
|
|
Thanks for creating yet another thread on this topic. The other 9000 weren't enough.
|
|
|
|
It seems like you have no idea what "ponzi scheme" and what "racism" means...  In United States political dialogue, a racist is "someone who disagrees with me". |
|
|
|
This would be all well and good if every wallet client (or even most of them) actually, you know, implemented BIP32! As it is, the best you can do is point me to a python tool? I'm capable of using it, but that just seems like a massive pain in the ass to go to. (Oh look, someone used another one of my addresses! Better boot to linux, generate the private key, and import it into my wallet!) And that's for me, a software engineer. What about the less tech-savvy users?
Moreover, most Bitcoin-related websites don't have BIP32 support either! They take one address for withdrawals. Some allow you to give multiple addresses, if they're a bit fancier, but even then, I'm supposed to post 50 addresses and log in to switch the address every time I get a payout?
And then there's Blockchain.info. Did you know Blockchain.info wallets reuse addresses by default unless you create new ones?
I appreciate the intent behind this proposal, but I don't think we're ready for this change yet. I do agree that we need to do this at some point in the future, but shouldn't we, you know, roll out the infrastructure necessary to make it actually workable first?
I was not commenting on the advisability of the patch in the OP, just pointing out that just because people are using single address wallets does not mean that it's the right thing to keep doing. That behaviour was known broken ever since the beginning, but since Satoshi didn't worry about the ability of users to backup their keys when he wrote the client (otherwise he would have gone with deterministic key generation), client developers responded by making wallets with a single key. Now a bunch of new users have been trained with bad practises and it will take some now to reverse. |
|
|
|
I don't trade on traditional markets, so I'm just wondering the following. Take for instance Google stock, right now it's floating around 1000$. I can't imagine the Google stock has the same shitty market depth bitcoin has, e.g. 1000 bitcoins (or 1000 shares) dropping the price by 40$. Why is it that bitcoin has such bad market depth? The price keeps going up but a few big dumps could drop the price back to the low 300's. I can't imagine the same thing happening to Google stock.
Traditional markets lie. They let people trade with assets they don't actually have. Soon enough, Wall Street will get involved and play fractional reserve games with Bitcoin trading. When that happens just remember - only bitcoins that are in a wallet whose private keys you exclusively control are real. Everything else is just promises back by (potentially) nothing at all. |
|
|
|
Looks like the cartel is much farther with conspiring against the bitcoin principles, than I had ever expected.
That's exactly what we could predict after Google itself had put their dirty hands on the development - anyone with a working brain knew that nothing good could have come from
You haven't read the posts or the thread have you. Please go back and read what was actually said. I even posted a fair summary of quotes but you can read all the originals for yourself. What's missing from that thread in the BF forum is the private conversations businesses and BF members have been having with regulators. Of course the worst quotes aren't going to be made public - we've got to infer what's going on behind the scenes based on what is public. From the Forbes article: “Essentially, we’ve been working with regulators for a structured approach for Bitcoin customers to be compliant,” says Waters. “We set up an API to work with their systems and we supply reporting tools they need for their databases. Which bitcoin addresses belong to a person? That’s the problem we’re solving.” Who started telling the regulators this was even possible in the first place and also a good idea? Peter Vessenes. Where is Peter right now? Chairman of the Board for Bitcoin Foundation. The leaked thread is not where the important discussions and decisions are being made. A group of people including US government officials and business owners have decided this is going to happen, and the thread is one of many attempts to figure out a way to sell it to the community, before they give up and just ram it down everybody's throats (at least, everybody within the grasp of the US government). |
|
|
|
The non-profit sector, and donors to it, would also benefit from such radical transparency. Charities that can prove that they're not blowing donor funds on exorbitant executive pay, corporate jets, fancy hotels and catering, for example, and are actually delivering real benefits to people in need (or at least working diligently toward what they've promised to donors), globally visible (at least up to the fiat interface or the real-world-goods/services interface), supplant and, er, out-compete, those which waste so much on overheads. For them and for donors, globally visible public records are a desirable feature, at least for the ones that survive the transition to a cryptocoin economy.
As another example, I operate a Bitcoin legal defense fund for the accused Dread Pirate Roberts (link in my sig). The transaction record to the fund's sole address shows that I've disbursed nothing of what's been given, and it needs to stay that way until I can properly justify an expenditure.
All of these models, and others, can benefit from reusing addresses tied to individual and/or institutional identity, and address re-use carries a massive benefit in simplicity ("donate here" QR codes on paper flyers? yes we can!), despite the known drawbacks. Deprioritizing or (especially!) filtering transactions seems to raise the costs for implementing such models, significantly. The right way for an organization that desires this level of transparency is to use BIP32 and publish their extended public key. The single address model for simplicity is like trying to use a screwdriver as a hammer. |
|
|
|
what are the friendly countries where one would go to be able to make normal living who is in no way a criminal or launderer? Almost any country would be easier than the United States, except maybe Cuba, Venezuela, and North Korea. Exactly. You don't need a bank account to start a bitcoin business. That's a major benefit, not a con.
Why would you even want a bank account if you do business in BTC, and only BTC? If you believe in it as a long term solution, you would never even trade into fiat at all. Show some balls.
Here's an example of how to operate a BTC business that involves USD without needing to touch it directly: http://www.reddit.com/r/BitSpend/comments/1gqjf8/an_open_letter_to_the_bitspend_team/ |
|
|
|
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. I think this is an artifact of Satoshi being stronger in crypto than in software engineering. http://www.fastcompany.com/28121/they-write-right-stuff |
|
|
|
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... |
|
|
|
What a load of bullshit.
You misspelled science. |
|
|
|
|
Some kind of puzzle game where solving a puzzle extends your blockchain. You're racing against other opponents, and whoever gets left too far behind loses.
|
|
|
|
I really don't understand the "all or nothing" mentality of some people. Hold some, trade some. Even when you lose, you win.
You're neglecting opportunity cost. What if you spend hours per day trading for months, just to end up where you would have been with a buy and hold strategy? What else could you have done with your life during those months? |
|
|
|
|
Show Posts
