Gavin Andresen (still have some trust for him) FYI:  |
|
|
|
this is why bitpay is getting investors to give bitpay large reserves ($32mill example) so that bitpay does not eat up the buy-wall of exchanges., and investors do not eat up the buy wall of exchanges for them to get their bitcoins either.
that way the investor well away from an exchange, gives bitpay FIAT, and bitpay gives the investor bitcoin. I expect payment processors to eventually turn in to the primary price discovery mechanism. Sooner or later, some investors are going to get impatient with this arrangement so they'll ask the payment processors to start offering higher exchange rates in order to attract more BTC sellers. |
|
|
|
What in your experience would be the easiest method of achieving this? Just use Armory. |
|
|
|
I've watched the whole Instawallet fiasco like a hawk because I had some BTC in Instawallet. I never used Instalwallet, but I did keep an eye on how davout and boussac behaved during and after the incident because they are involved in other Bitcoin projects. The way they handled the situation looks to me consistent with what I'd expect from scammers. Honest people would show some signs of remorse and humility after losing so much of other people's money - they were arrogant and hostile instead. |
|
|
|
|
"Those who don't understand Open-Transactions are condemned to reinvent it, poorly."
|
|
|
|
|
There are no safe exchanges, yet.
|
|
|
|
Sounds a nice concept ... Proof-of-Bandwidth Altcoins for Compensating Relays Abstract. The Tor network relies on volunteer relay operators for relay bandwidth, which may limit its growth and scaling potential. Wepropose an incentive scheme for Tor relying on two novel concepts. We introduce TorCoin, an \altcoin" that uses the Bitcoin protocol to reward relays for contributing bandwidth. Relays \mine" TorCoins, then sell them for cash on any existing altcoin exchange. To verify that a given TorCoin represents actual bandwidth transferred, we introduce TorPath, a decentralized protocol for forming Tor circuits such that each circuit is privately-addressable but publicly veri able. Each circuit's participants may then collectively mine a limited number of TorCoins, in proportion to the end-to-end transmission goodput they measure on that circuit. http://dedis.cs.yale.edu/dissent/papers/hotpets14-torpath.pdf... your thoughts Like all appcoins, their application would be better off by just using Bitcoin directly. |
|
|
|
Executive Summary:
The SharedCoin mixing service provided by Blockchain.info offers only limited privacy to users due to weaknesses in its design. Bitcoin users should carefully consider their privacy requirements and evaluate other mixing services if they require serious privacy guarantees. A tool for analyzing SharedCoin and other CoinJoin-based mixing protocols will be released approximately two weeks following this advisory to allow SharedCoin users adequate time to protect their privacy. http://www.coinjoinsudoku.com/advisory/ |
|
|
|
In two weeks, this site is going to release an open source tool that purports to de-anonymize Shared Coin transactions. http://www.coinjoinsudoku.com/advisory/Coming from the perspective that it's impossible to improve that which is not measured, I'm glad to see tools like this appear. Hopefully in the future we'll be able to evaluate privacy claims in a more empirical and objective way and so be more likely to have tools that actually work. |
|
|
|
Okay, then that bring up a question for me. Is there a way to *only* try to route to other TOR hidden services? For example, if I didn't even want to leave via an exit node to the rest of the network? -onlynet=tor I have evidence of it failing to connect to an external IP using "-proxy:" from an error message here: (modified for anonymity of exit node) Jun 06 13:34:11.449 [Notice] We tried for 15 seconds to connect to '[scrubbed]' using exit $ECC33AB15915C6E167A0EAEF9D4BD1A005B12F56~GoodBoy23 at 201.151.231.31. Retrying on a new circuit. Right with -proxy, all connections are sent through it. If you used -onion you'd never see that message since you'd only be attempting to connect to hidden services. I'm not sure this is needed for most people, but I think it'd be interesting to run a within-TOR-only node. Obviously this could be done by using the wiki for TOR services and only adding TOR IPs, but is there a way within the client to do only TOR-based IPs and avoid even exit nodes? -onlynet=tor combined with -onion should do everything you need, except I'm not sure if there's a way to automatically bootstrap a Tor-only node. I always bootstrapped manually from known Tor nodes. |
|
|
|
I've heard some people say if you use -onion=127.0.0.1:9050 your client will never leave TOR, which might be best for anonymity purposes. I'm pretty sure that's the opposite of true. As far as I understand it, -proxy sends all connections through the proxy. -onion only send connections to Tor hidden services over the proxy, and connections to regular ipv4 peers bypass the proxy. If you do this, however, I am not sure if the server will be accessible Having your node accessible as a hidden service (something.onion) is just a matter of configuring your Tor nodes to publish the hidden service and redirect incoming connections to your node, and then using -externalip so that your node can tell its peers how to reach it. |
|
|
|
once people are savvy to the mechanism they will simply click no, allowing them to post the topic. Also there may be legitimate cases to make a new topic. It's easier for moderators to censure badly-behaving users if those users act in ways that take away their plausible deniability. That's mostly what my original proposal was about - making it very difficult for an honest user to accidentally post in the wrong area. This means moderators can generally assume any post which posted in the wrong place was done so deliberately and respond accordingly without needing to second-guess themselves. |
|
|
|
|
How do you suppose they know how much money their users are transferring?
|
|
|
|
And U.S. congress simply don't understand how money works. They allowed the removal of gold standard, since then reserve bankers are printing money like crazy to buy everything they can
Of course they understand how money works. Going off the gold standard made them and their cronies fabulously wealthy. The monetary system is working perfectly (for them). |
|
|
|
Andytoshi and I spent some time trying to formalize a notion of "coinjoin entropy"— e.g. how many possible mappings of inputs to outputs are possible given the values. A result of that was that discussion was the realization that if you allow for the possibility that coinjoin participants might also be paying each other then basically all coinjoin's have perfect entropy because there is some payment matrix that permits any of the output parties to be any of the input parties.
We didn't actually solve the entropy question for the non-concurrent payment case, it's an interesting question.
I'm ready to accept that CoinJoin can be viable with outputs of different sizes. Next question: what about information leaked via script types? I think we can assume that in the near future there will be several types of scripts in common use: P2PKH, multisig, and stealth. We can also assume that the frequency with which these scripts types are used will vary between different classes of users (merchants vs customers). Even if the amounts associated with inputs and outputs don't make the join trivially reversible, how do you stop the scripts from acting as a side channel that can deliver enough information to make the join reversible? |
|
|
|
If anybody has any more ideas, please let us know! I don't know what exactly will make it into 0.92 but I'll do my best to squeeze in as much as possible. Is armoryd tied to bitcoind specifically, or can it be run against any full node implementation that is RPC compatible (btcd)? |
|
|
|
since there is no such thing as "a Bitcoin", it is impossible to make a deterministic linkage between inputs and outputs. That is a true, but useless, statement. As I mentioned before, mass surveillance doesn't require 100% accuracy. |
|
|
|
|
Good. They can implement blacklists, and asset forfeiture, and demurrage, and identity tracking, and then people can stop suggesting that Bitcoin add those things because we can tell them to just use Fedcoin if that's what they want.
|
|
|
|
so its not 'theoretically' possible to hide a trojan horse in the main bitcoin-core Haven't you ever heard of this NSA crowdsourcing program? http://en.wikipedia.org/wiki/Underhanded_C_ContestThe Underhanded C Contest is a programming contest to turn out code that is malicious, but passes a rigorous inspection, and looks like an honest mistake. The contest rules define a task, and a malicious component. Entries must perform the task in a malicious manner as defined by the contest, and hide the malice. Contestants are allowed to use C-like compiled languages to make their programs. |
|
|
|
|
Show Posts
