FT: US regulators eye Bitcoin supervision http://www.ft.com/intl/cms/s/0/b810157c-b651-11e2-93ba-00144feabdc0.html#axzz2SXW9UnLrSenior officials at a top US financial regulator are discussing whether Bitcoin, the controversial cyber-currency, might fall under their regulatory remit.
Bitcoin “is for sure something we need to explore”, Bart Chilton, one of the five commissioners at the Commodity Futures Trading Commission (CFTC) told the Financial Times. A person familiar with the CFTC’s thinking said that the regulator is “seriously” examining the issue.
Said Mr Chilton: “It’s not monopoly money we’re talking about here – real people can have real risk in these instruments, and we need to ensure that we protect markets and consumers, even in what at first blush appear to be ‘out there’ transactions.”
[...]
Paywall note: FT permits a few free articles per month, with registration. |
|
|
|
Do you have a theory as to who he is?
No. It is most likely not any of the dev team, based on in-person chats and observation of code. |
|
|
|
Hard drive technology has no problems keeping up with blockchain growth. Network technology is probably the same, though I think there will be some amount of balancing on-chain versus off-chain transactions.
Anonymous network technology is just barely good enough to support mining anonymously with 1MB blocks. (not hashing! I mean being a mining pool, solo-mining, or running p2pool) That isn't going to get better quickly, and could easily get worse if we see attacks on the Tor and I2P networks. Indeed. The more people who run a full node, the greater the decentralization[1][2]. Using the chain as data storage, rather than currency, costs everybody, because it increases the rate at which people are discouraged from running full nodes. It increases the costs of that dataset that cannot be pruned, and must be carried for eternity: the unspent transaction output set (UTXO), the list of coins available for spending. Right now, it remains within the realm of a hobbyist to run a full node, especially with the recent memory usage improvements in bitcoind. But one day, that will not be the case. By pushing back on data spam, we reduce the rate-of-increase on blockchain resource costs, and reduce the disincentive to run a full node. We push back the day at which there are just a handful of archive nodes with a copy of the full block chain. [1] Probably. [2] Though "decentralized" does not necessarily imply "private", as your message indicates. |
|
|
|
Not a file sharing, but distributed DHT-like database HASH=BLOCK
This "DHT" call comes up frequently. This is fine for experiments, and as a backup method akin to the recent blockchain-over-twitter project. But it is woefully less secure and resilient than the current scheme. Bitcoin uses a "D1HT"... a fancy term for "everybody has a copy of the database." Currently the entire blockchain is massively replicated, perhaps 20,000+ times or more. This is larger than all but the largest torrent swarms.Benefits: More secure and resilient. Far more decentralized. Better chance of useful work, if one honest peer is found. 100% provable for any node; no "holes" in the history. Costs: Network and disk resources required to store the blockchain, and provide it to others for download. Going from that, a DHT is quite a step down, quite a bit less secure. DHTs are vulnerable to hot spots -- where the whole world queries just a few nodes -- and sybil attacks[1]. On sybil attacks, bitcoin's current peer finding mechanism does a better job of intentionally spreading itself widely across networks; a DHT tends to concentrate on a few nodes. It becomes much easier to attack a portion of the blockchain, if it were stored as (hash,block) key-value pairs as commonly suggested. If an attacker may DoS even a single (hash,block) pair, you prevent the entire world from downloading or verifying the entire bitcoin blockchain, because the chain is thus broken. The time spent looking up each hash across a worldwide DHT would be quite slow; that is the equivalent of downloading 234,831 different torrents, not one big torrent. Storage via DHT is a fun toy idea, but it's stupid, slow and insecure as a primary method. Massive replication is far more secure and decentralized. Hard drive technology has no problems keeping up with blockchain growth. Network technology is probably the same, though I think there will be some amount of balancing on-chain versus off-chain transactions. It is also thought that the nodes bearing the brunt of the blockchain downloads in the future will be a few professional and volunteer "archive nodes", that store the entire blockchain. And certainly the blockchain torrent will continue to exist as an alternate method. [1] Remains an active area of DHT research, and several mitigation mechanisms are deployed in the field. Even with these new techniques, the DoS-a-block, DoS-all-of-bitcoin implications make DHTs an inferior solution. |
|
|
|
Miners already have the ability to decide which transactions they include in a block based on a fee, now I find it correct that as a user I have the ability to choose what I forward and what I don't.
Correct, though I must add that users already choose what to forward, or not. Most notably, the client will not relay transactions outside of a very narrowly defined set of "standard" transactions. The vast majority of possible transactions are not relayed by default. This policy has been in place for years. |
|
|
|
In the end of the day if you are not a significant miner you have no say whatsoever in how much to charge for any transaction and whether it is better to patch and recompile bitcoind to get what you want or to use some command line switches. All you can decide on is whether you prefer a higher fee for quicker transaction or not. This is so by design. It always was so. It always will be so. If you are not happy with it go and create a fork where users decide how much miners are to charge for finding blocks.
Close. It is true that miners choose which transactions get into blocks. However, every client chooses what to relay, or not. |
|
|
|
1) I note the distinct lack of discussion surrounding https://bitcointalk.org/index.php?topic=130450.0 and its pull request. 2) This issue certainly deserves better communication, but think the trolling (reddit/bitcointalk) by @johndillon was premature and exaggerated, because there is still plenty of time and opportunity in the release cycle for comments. Usually the time prior to -rc1 release is used to write the communications that appear in -rc1. The -rc1 release announcement then describes the changes, including rationale and impact. -rc1 release initiates a phase of public testing and comment. If the community really dislikes a particular change, this testing phase is yet another opportunity to make that known. 3) Most importantly... The vast majority of remote workers (miners) do not seem to care at all about mining policies, in practice. Pools' mining policies are incredibly opaque, few miners show deep interest in mining policy, and few pool operators show much interest in deep thinking about mining policies, transaction selection, and various economic incentives. Even a lot of smart, engaged pool operators wind up preferring unmodified (or close to it) bitcoind for reasons of reduced complexity. Therefore, just wanting -- quite rationally -- to get paid for mining, it is the sad reality that the block subsidy (currently 25.0 BTC) reduces transaction fees to the economic equivalent of statistical noise. The long term cost of generating and storing economically worthless transaction outputs is simply not transmitted to users or miners. Nor, really, is the short term cost. The economic signalling of the block subsidy drowns the rest out. The cost is currently borne entirely by "the cloud", the all-volunteer P2P network of full nodes. The only modicum of behavior signalling we see there is a decreasing number of full nodes, and an increasing amount of P2P traffic. What does all this add up to? The answer is lies in the free market. Move transaction fees away from hardcoded limits, and towards something more dynamic, with economic feedback between merchants, users and miners. These hardcoded anti-spam limits have existed for years, originally starting out at 0.01 BTC. Transactions have always been filtered. Anything outside a small set of "standard" transactions are deemed "non-standard", and will be filtered (not relayed). Again, policy has been in place for years. The fee limits were lowered over time, but still hardcoded. This latest change makes this limit configurable, moving one step closer to the goal of users being able to react rapidly to changes in miner policy or bitcoin value. One step closer to a freer market. Also introduced is an anti-spam rule that avoids relaying transactions whose value is below that of the transaction fee required to send it. This rule self-adjusts over time, as the "tx fee required to send" changes over time. In a dynamic fee market, it might change a lot. It is unavoidable that tiny transactions worth fractions-of-a-penny may be easily abused for data transmission and storage. We have already been burdened with megabytes worth of wikileaks data, GPG encrypted data, and the PGP fingerprint strong set, so this is not a theoretical problem. These files are stored as bitcoin transactions with values around 0.00000001. |
|
|
|
Why not just make a fork? I think it's just one or two lines of code, so should be easily done.
It's open source. Fork away. Though the consequence is that you remain at a higher, hardcoded fee level, and people will still dump megabytes worth of non-currency data into the blockchain (wikileaks cables etc.). |
|
|
|
If this isn't a protocol change, but merely a CLIENT change, then this is essentially a non-issue.
This is not a protocol change. This is a client change. |
|
|
|
So, a hardcoded magic number has been made configurable. Except most do not like the new default magic number.
Yes. Though I argue that most are just not familiar with the system, and reacting without learning. As it currently stands, the new default magic number is lower than in prior versions. So fees are getting lowered -- and user configurable to be easily lowered again (or raised, if that is what the user desires). |
|
|
|
Please read the patch. This pull request is the first step towards a market between miners (who want higher fees) and merchants/users (who want lower fees, but also want their transactions confirmed). Miners can already control what fees they accept, this pull lets users control (very clumsily, improvements on the road map) the fee they are willing to pay.
Previously, these limits were simply compiled-in constants. Now they are configurable. |
|
|
|
This is bullshit.
If you do this, you kill any credibility Bitcoin has.
It's not Gavin's place to DICTATE what transactions should be allowed and what transactions should not be allowed.
The beautiful mathematical design of Bitcoin just makes sense. This does NOT make sense in the same theoretical, effortless way. This is arbitrary.
The software has always dictated which transactions are relayed, or not. This change makes it easier to change that limit, in fact. |
|
|
|
This is about changing the fundamentals of bitcoin. Transactions should not be limited..... PERIOD. This goes against everything bitcoin has said it stood for.
Transactions have always been limited. In the past, the limit was far higher than it is today. |
|
|
|
NO transactions should be blocked,
Then spam clogs the network. and currently no transaction have been blocked,
False. Anti-spam relay rules have been blocking transactions since the first days of bitcoin. In the past, you might get dropped for sending 0.01 BTC, instead of the much-low levels of today. |
|
|
|
|
Show Posts
