(And it's not for "no reason," it's because they know quite well where the dog's loyalties lie, and it's sure as shit not to the State.)
I stand corrected. |
|
|
|
Except these are not isolated incidents. They happen nearly constantly, to the point that a polite, kind, friendly policeman is the exception now, no longer the rule. The police are not your friends. They are not on "your side."
It's come to the point now that if you have any kind of interaction with the police at all you should consider yourself lucky if your dog isn't killed in front of you for no reason. |
|
|
|
|
Only one that I can be certain of. All the rest of you might be illusions created by a demon to deceive me.
I Bit therefore I am.
|
|
|
|
I largely agree, except that the final step isn't tiny and in my opinion won't happen until exchange rates stabilize (which will take a long time). Stabilization of the exchange rate comes through increased adoption. Once a business is using Bitpay (or an equivalent service) to convert instantly convert BTC sales into local currency they will start asking their suppliers to accept BTC directly so the business can benefit from the lower fees associated with keeping the sale in BTC. These suppliers will probably also start using a service like BitPay because their costs are still in local currency. BTC use then moves up the supply chain one layer at a time, by the time nobody needs national currencies any more the exchange rate will be dominated by the supply and demand for commerce instead of speculation so it will be stable enough to use directly. |
|
|
|
The reason some people are querying that you allow US customers is FATCA. It isn't correct that you aren't subject to US regulations. Yes, obviously, in a reasonable and just world that would be the case, however the US is trying to change that as hard as possible as it appears that they are succeeding, FATCA implementation is proceeding at the moment - though it's not yet in force. FATCA forces non-US financial institutions to follow US laws in two ways. Firstly, they are busy signing agreements with different governments that will mean financial institutions are forced to provide customer data to the IRS. These are called "inter-governmental agreements", and yes France is signing one: http://www.stepjournal.org/journal_archive/2012/step_journal_june_2012/fatca_in_the_frame.aspxThe second way is far nastier and more insidious. They are planning to impose a recursive "passthru" 30% withholding tax. That means if you do business with the USA you must follow US law and if you don't, your US assets will be taxed at 30% (essentially bankrupting you or making you uncompetitive). But any business that comes into line because of that must also impose the 30% tax on any other financial institution they deal with, even if that institution does not interact with the US in any way shape or form! Because the financial system is a fully connected graph, this essentially means that US law spreads through it like an infection and eventually every financial institution will be forced to comply or face crippling sanctions from other financial institutions they interact with. This happens even in cases where US law conflicts with local law. Dave, as you're the one exposed to this stuff, please make super sure you have fully researched this topic. The US will force you to follow its rules whether you like it or not and the French government will not save you - this is not a paranoid hypothetical but a phenomenon that is already happening. Your best bet is to do what all other financial institutions are doing and deny access to "US persons" (citizens, residents and people who have held a green card in the last 10 years, iirc). This doesn't exempt you from FATCA but it minimizes the amount of paperwork and reporting to the IRS you'll have to do. Mike Hearn... you're such a smart guy, but everything you say depresses me  The silver lining of all this is that these kinds of rules infecting the legacy financial system only serve to make Bitcoin more valuable as a method of avoiding them. In that sense those laws become a subsidy that makes Bitcoin even more profitable to adopt. |
|
|
|
|
That makes more sense. I dislike doing things manually so I'm trying to make ebuilds to do the compiling and installation for me, but it was difficult to know which branches/repositories to point them at.
|
|
|
|
What's confusing me is how there are a couple 0.6.x branches, and no 0.7.x branches at all. If some code has been merged into master which will become 0.8 and development is still going on for 0.7 where are those commits being merged? Into the 0.6.3 branch? |
|
|
|
|
If you're worried about the Eurocrats freezing your account then use some basic risk management.
Don't store all your bitcoins there. Keep most of your balance on a wallet under your direct control and only add small amounts of bitcoins as needed to fund your debit card.
|
|
|
|
Where exactly is 0.8? I looked everywhere in the bitcoin respository on Github and saw no sign of such a branch. |
|
|
|
|
In the case of my home lan I have a file server optimized for IO performance, and I have my main desktop which is optimized for CPU and graphics performance. I want to be able to maintain only one copy of the blockchain, on the computer that makes sense to store it on, and run my client applications on the desktop machine. Right now I run bitcoind on the file server, and also run Bitcoin-Qt and Armory on the desktop. Right now on the desktop machine I store its copy of the blockchain on a raid-0 in order to get acceptable performance, but sooner or later one of those drives is going to fail and I'll have to restore everything from backups.
|
|
|
|
It's funny you bring that up, because there has been an extended conversation over the past few days on the mailing list, about exactly that. There's some debate about the qualities of an acceptable to solution to promote as the default, and right now Bitcoin-Qt being the only "usable" full node implementation wins because we need full-nodes and that's the safest for the network. But I do agree with you -- there should be a better experience for new users -- and maybe that discussion will yield something like: "Multibit should be default if it implements X, Y and Z and gets some more support behind it". I think the ideal solution would increase the modularity of the reference code by completely splitting the functionality bitcoind and Bitcoin-Qt. Bitcoin-Qt should be a UI and wallet manager only, with no blockchain or network managing functions and bitcoind should remove the corresponding UI features. Bitcoind should be able to serve alternate UI clients, like Armory or a theoretical bitcoin-curses, directly. |
|
|
|
We only need a key hierarchy as in BIP32 (chaincodes on >=two levels) if we are required to derive 2nd-level chaincodes from 1st-level chaincodes because, for some reason, it is infeasible to derive 2nd-level chaincodes from 1st-level privkeys. I would imagine this is the case for any website that needs the ability to generate new 2nd-level codes on the fly, since you wouldn't want to put the private keys on a public-facing server, such as if a public donation page handed out unique extended public keys for improved anonymity. |
|
|
|
You can also patch your bitcoin daemon to not enforce fees, but then your transactions may take a long time to be included in blocks, if they ever are (depends on miners accepting them). Every time I've sent a transaction without fees it eventually got included in a block, although sometimes it took more than two hours. |
|
|
|
|
Another use case for key hierarchies is shopping sites. When I create an account on Bitmit they should assign me an extended public key that my client saves in order to create all future payment addresses. This provides two advantages:
Security: As long as one does not go undetected during the initial account setup, a MITM attack can not redirect payments to the attacker's addresses since my client already knows where to send payments.
Anonymity: To the extent possible I don't want to use outputs from different addresses as inputs in a single transaction. If I need to pay Bitmit 10 BTC but all I have are two 6 BTC outputs on different addresses I can use two transactions to complete the sale by sending 6 BTC to address k and 4 BTC to address k+1. Now it will be more difficult for a third party to examine the blockchain and determine that the same individual controls both addresses.
|
|
|
|
It's a feature, not a bug... Armory inherits all the security properties of Bitcoin-Qt by using it as a gateway to the Bitcoin network. If I rewrote all that stuff myself, it'd probably be a disaster. And in the end, since you don't ever need to touch Bitcoin-Qt, you can just minimize it and pretend it isn't there. Armory is a bit slow to start, but the recent beta release includes insta-load so you can manage your wallets (like importing keys) while it is scanning the blockchain. Do you ever plan to make it possible to use bitcoind (possibly running on a different machine) instead of Bitcoin-Qt? |
|
|
|
GNU actually had most of the operating system ready, and it was just Satoshi that came along and added the final piece they needed for digital currency in the GNU operating system. This community certainly needs more things to argue pointlessly about, and whether it should be called Bitcoin or GNU/Bitcoin is a perfect fit. |
|
|
|
As far as key hierarchies go, do we have any significant application for it yet? I would really like to be convinced that we absolutely need them.
I listed one in an earlier post. If I'm going to buy Bitcoins on an exchange I'd like to be able to give the exchange an extended public key so that they can automatically generate new withdrawal addresses without further interaction. Similar I'd like the exchange to give me an extended public key so that my HD-aware client can automatically generate the next unique deposit address every time I want to add Bitcoins to my account. If Wikileaks wants to receive donations without allowing a third party to monitor how much they have received or who the donors are they could use an BIP32 HD wallet. Every visitor who requests a donation address gets an extended public key instead of a regular public key, so now the donor can generate his own unique donation addresses without needing to visit the Wikileaks web page every time. Clients that understand HD wallets could be configured to store a counter in the address book entry of each extended public key and to by default automatically send to a unique address when that entry is selected by the user. |
|
|
|
|
Given Stallman's political views he's one of the last people I'd expect to be interested in the monetary freedom Bitcoin represents.
|
|
|
|
|
Show Posts
