Actually it could be done with a soft-fork. (This is only for academic discussion. I don't think we will ever need to divide a satoshi)
I think people are forgetting what you said here about "academic discussion" Your idea is clever and says a lot about your understanding of the Bitcoin protocol, regardless of whether or not we'll ever use it or whether or not it'd be easier to do a hard-fork. (though by the time we do need to start thinking about sub-satoshi's it may very well be the case that hard-forks are impossibly impractical and clever/ugly hacks are required) |
|
|
|
isn't that the purpose for test net 3 bitcoins? why not try it out on them~~~
That sounds reason. Re-enable all the opcodes for testnet? Testnet has to match mainnet, so the removed opcodes are still removed. By all other transaction types are valid - testnet doesn't use the IsStandard() tests. If you want to test new opcodes on testnet, go right ahead. It'll just mean you get forked by the rest of testnet, not a big deal. |
|
|
|
For instance, look at the last point release. I've known for years you could add extra data to the end of a tx message and have it be relayed. Anyone who read that code carefully knew it. And it's obvious that by doing so, you could fill up the memory pool with garbage quite quickly. This was not worth reporting or discussing because we knew for a long time that mempool management requires a rewrite, such that it's got a limited size and low priority transactions that don't fit get dropped.
You're the only person on the dev team who seems to have noticed that you could add extra data; it's not all that obvious. You ever considered you might actually just be a shitty programmer when it comes to security? All those other ways of filling up the memory pool (that we know of) cost thousands of dollars in fees, or don't actually fill it up very fast because we rate-limit free transactions. The nLockTime screwup wasn't anywhere near as bad as it was because even at $5/BTC it would have required the attacker to have about $100k worth of bitcoins to cause even just a 10KB/sec of extra traffic on the network. These days with the price at $100 memory exhaustion is the worry, and costs the attacker about 1mBTC/KB, or $10,000/GB. Someone who actually understood security would have realized that the extra data attack created an attack thousands of times cheaper than existing ones. It's just a variant of that wider problem that was already well known and has never been solved because .... nobody wrote the code to do it! Instead now we have a stupid hack that makes the code even more complicated (the right quickfix would have been to store transactions in mapRelay instead of byte buffers, thus removing the feature and simplifying the code).
Anyway, rather than complaining about the stupid fix, why didn't you write a better one? I mean, heck, I wrote that fix while the main network was being actively attacked by it, and had the bad luck to wind up in hospital for a few days right after. Fortunately the fix has the side-effect of inoculating the rest of the network (small tx's propagate faster than large ones) except for directed attacks, so there was time to improve it. tl;dr - research isn't the bottleneck for making Bitcoin hard to DoS, writing code is. Someone needs to actually implement a real anti-DoS strategy that will work, write tests to prove it works, and so on. This is all a long hard slog.
"fundamentally for SPV clients an attacker only need to outspend whatever limited resource the sum of all SPV client users are willing to spend to connect to the network" <- speaking of making Bitcoin hard to DoS, what limited resource(s) you are willing to see SPV clients spend in exchange for using up node resources? You know, fundamentally we're still learning what features Bitcoin can support without being vulnerable to attack - that's the real reason we keep on disabling stuff. But I see you spending a lot more time writing about "death spirals" of disabled features then I do you writing about ways to make those features DoS resistant. I also see you wasting people's time arguing for features to be enabled before we figure out ways to make them DoS-resistant, as you did with tx-replacement itself. |
|
|
|
|
"merkelized abstract syntax tree" == "abstract syntax tree + hashing"
You only provide the parts of the tree actually executed, take advantage of that.
Making transactions as statefull as you suggest - depending on external data for the scripts - has many severe drawbacks due to the non-determinism and complexity. Anyway with MASTs that step can be just a matter of optional blockchain compression.
|
|
|
|
|
TierNolan: learn about merkelized abstract syntax trees.
|
|
|
|
Alerting people is what the alert system is for - not to mention the media.
That is a centralized solution. Any emergency hard-fork will involve centralization; a big part of why hard-forks are so strongly discouraged is the centralization they imply; bitcoin still has never experienced a hardfork. |
|
|
|
|
Alerting people is what the alert system is for - not to mention the media.
|
|
|
|
You know OP_CHECKCOLORVERIFY can be implemented more usefully by adding op-codes to let scripts analyze the txouts of the transactions spending them. It'd be useful for a lot more than colored coins, and frankly there is no way in hell you are going to get a colored-coin-specific opcode included in Bitcoin.
I'd suggest you think about how a more general solution could work.
Thanks for your comment. I will think about it. At least, does my proposal technically work? Probably, though I didn't look at it in detail. The issue is it trades off small scripts for a whole lot of effort creating code for colored coins; this code will need to be duplicated across many different bitcoin implementations. Frankly that's just not worth it. re: OP_META, have you heard of merkelized abstract syntax trees? |
|
|
|
|
You know OP_CHECKCOLORVERIFY can be implemented more usefully by adding op-codes to let scripts analyze the txouts of the transactions spending them. It'd be useful for a lot more than colored coins, and frankly there is no way in hell you are going to get a colored-coin-specific opcode included in Bitcoin.
I'd suggest you think about how a more general solution could work.
|
|
|
|
|
Right, and an AP may have a clever way of dodging the fraud issue, but it won't be easy.
|
|
|
|
|
Point is, when you are dealing with a huge block of bitcoins you can afford to spend a lot more money on very carefully auditing and verifying the transaction. I'm sure the large redemptions will have a complex procedure involving a lot human involvement to be absolutely sure everything is happening as expected.
The more interesting question is will the Bitcoin ETF use techniques like merkle sum trees to cryptographically prove to investors that the ETF really owns the bitcoins they claim to and that customer shares are backed 1:1 by those bitcoins.
|
|
|
|
|
Nothing surprising there. To enable shares to be easily redeemed in Bitcoins they would have to make the security of the accounting systems keeping track of who owns what shares just as good as Bitcoin itself or they'd be getting fraudulent share redemptions left right and center in exchange for Bitcoins. It's just another example where the security of banking sucks and the only way banks get away with it is because any transaction can be reversed after the fact.
|
|
|
|
|
Please do keep posting - if SatoshiDice is losing popularity we want to see the stats showing the decline.
|
|
|
|
|
Your idea doesn't work because you can't assume that clocks are synchronized; if anything the current 2 hour window is too short.
If you don't require the timestamp to be set 10 minutes ahead of the previous block you've effectively just reduced the time between blocks; mining is a random process so if you find a half-difficulty block why wouldn't you broadcast it to the network?
If you do require the timestamp miners have every reason to always mine with a timestamp >= 10 minutes ahead of the previous block just in case they find a half-difficulty block. Eventually they'll get close enough to the 2 hour window that network consensus is impacted, likely for clients first because clients have the most difficulty and least incentive to make sure their clocks are really accurate.
If you decide that a half-difficulty block gets less than half the reward, again, mining is a random process so why bother at all? If fees are sufficient to make up the difference, then you are back to having incentives to make fake timestamps and will soon run into consensus problems.
Finally a large miner also has an incentive to mine blocks close together because it increases the orphan rate of their competitors more than it increases the orphan rate for them, thus reducing competition over time, and making available more transactions for them to mine and collect fees from.
Moral of the story is that it's really dangerous for there to be incentives in Bitcoin for miners to make inaccurate timestamps, yet it's also really dangerous for nodes to tighten the 2 hour rule for accepting timestamps that appear to be in the future due to the risk of forking the network. It's quite possible that widespread use of Bitcoin for timestamping could create such perverse incentives. It's also possible that the nLockTime feature could do that too, because if a miner knows of a high-fee transaction with a time-based nLockTime they have an incentive to set their block timestamp sufficiently far ahead for the transaction to be finalized even if that means faking the block timestamp; if miners start running code to do this automatically an attacker could provoke a fork by just creating lots of transactions with nLockTime in the future and getting those transactions to miners.
|
|
|
|
...
What we are going to have to do is require peers to either do something useful, like relay valid fee-paying transactions and valid blocks to us, or expend some kind of limited resource, like perform a proof-of-work or just pay directly via micropayment. That'll make widescale DoS attacks prohibitively expensive, but it also impacts SPV nodes too that don't contribute to the health of the network. Of course, obviously if such an attack happens this code will be written and deployed very quickly, so don't get any ideas...
'Something useful' could be, among other things, being verifiable situated in a domain which is underpopulated. The domain could be geographical, political, implementational (meaning it works in particular way such as implementing an underrepresented overlay messaging protocol) or whatever. Indeed - that's what we try to achieve with the current system of trying to connect to nodes with ip addresses in a varied set of /16's. Varying implementations is an interesting idea too, although one that's harder to actually verify. If you can come up with ways to do more than that we'd love to know, but be warned it's a really, really difficult problem. |
|
|
|
Having said that, remember that if you want to keep the contents of your wallet private, you have to be careful with SPV mode. Because your node doesn't relay transactions, any transaction you do relay is obviously from you. In the future the payment protocol will help, but for now assume that by using an SPV wallet your peers can figure out what coins you own. The other issue is that to scan for new transactions you have to tell your peers what addresses are in your wallet. Fortunately we can use a trick called bloom filters, which is kinda like telling a peer "give me all transactions paying addresses starting with 1ab, 1ar, 1a5 and 1w2", but combined with other information that may be enough to track you down. Edit: Bloom filters have been found since I wrote that to have almost no privacy. You should be connecting over Tor, or at least over a proxy, if you want to maintain your privacy. Unfortunately as far as I know right now most SPV clients don't make it easy to connect over Tor, but it is possible. Full nodes don't have anywhere near as serious a privacy problem even without Tor because they do relay transactions, so unless someone is watching every node out there they can't know if you were the one who broadcast the transaction first. Of course while in the short term finding peers to connect to for your SPV node is free, but that won't be true forever: I think Gavin has alluded to possibly rewarding those who run full nodes, which I think is the way to go. I don't see any reason why miners should get rewarded, yet those who run full nodes and eat the bandwidth/disk space get nothing.
When running a node becomes expensive enough that people can't do it for free you'll still be able to find full nodes willing to accept incoming connections. You'll pay for that service in a variety of ways: 1) Transaction fees: You connect directly to a miner who lets you do so because they want your transaction fees. They may require some # of transactions per unit time, and part of the agreement may be that you only send transactions to them. (easily verified) In return they'll run your bloom filter against incoming blocks, although don't be surprised if they force you to give them a bloom filter specific enough to identify exactly what addresses are in your wallet as part of the deal. 2) Pay-for-service: You pay for the service directly. In return they resend your transactions to miners to get them mined, possibly with preferential deals (kickbacks) that may or may not be public knowledge. They also run your bloom filter against the blockchain, and again, they may or may let you do so in a non-specific manner. Given AML regulations I wouldn't be surprised if the services that operate out in the open only allow you to tell them what addresses you are interested rather than a bloom filter obscuring that information. (AML rules apply to case #1 too) 3) Datamining: Google and other search engines already provide a lot of services purely in return for the data they can gather. The blockchain itself is a rich source of transaction data, made richer by figuring out the real identities behind the pseudonymous addresses on it. Just like #1 and #2 if you can determine who is sending what transactions and owns what addresses you can integrate that into a rich dataset to do things like get real-world information on what vendors are actually popular, which in turn can feed search engine results and other services. It'll be interesting to see how AML regulations apply to all these services in the future. I suspect they'll eventually be subject to the same know-your-customer rules as any other financial service provider to help authorities link identities to Bitcoin addresses. This doesn't have to be very intrusive: in case #3 that might be as simple as using your Google login to authenticate with Google's Bitcoin servers. There's also the issue of DoS attacks which we will need to solve soon - anyone with access to around 125 or more ip addresses from a similar number of /16 subnets can currently DoS attack the entire network by simply filling up every node on the network's incoming connection table. (finding the ip address of every Bitcoin node that accepts incoming connections isn't hard) We limit that to 125 right now. Such an attack wouldn't use very much bandwidth, and is actually pretty easy to carry out. A small botnet with a few hundred or thousand hijacked desktop computers could definitely pull this attack off. At the very least SPV nodes would become unusable, and after a few hours to days the whole network would probably collapse aside from miners and the like who have made manual connections to each other. What we are going to have to do is require peers to either do something useful, like relay valid fee-paying transactions and valid blocks to us, or expend some kind of limited resource, like perform a proof-of-work or just pay directly via micropayment. That'll make widescale DoS attacks prohibitively expensive, but it also impacts SPV nodes too that don't contribute to the health of the network. Of course, obviously if such an attack happens this code will be written and deployed very quickly, so don't get any ideas... |
|
|
|
|
Protagonus: excellent post.
I hadn't realized just how little thought Satoshi had put into ensuring true decentralization or the economics of Bitcoin, or even how these lite nodes would work exactly. (Bitcoin is severely lacking when it comes to For instance the idea of just assuming transaction fees will become the main compensation for nodes is nuts, because it both assumes nodes are run by miners - dangerous given Bitcoin depends on a jam-proof network - and easily results in the situation where the funds going to miners are spent on non-mining expenses. Then again, Satoshi doesn't seem to have foreseen the development of mining pools, which indicates he wasn't thinking hard about the the economics in general; investing effort in mining is crazy if the varience is so high that the expected time to find a block is months or years.
Probably your usual example of someone inventing something really clever, and having all their thought processes locked into their original idea rather than thinking about alternatives, or even just admitting that it's uncertain if the system will work in the future as it scales upwards.
|
|
|
|
|
This whole PKI discussion misses the bigger issue: the first users of the payment protocol are highly likely to be websites, which means you already depend on SSL security and thus the SSL PKI system. In that circumstance putting all your eggs in one (flawed) basket is perfectly reasonable - better PKI's can be developed later.
Anyway the payment protocol has support for adding additional PKI systems in the future.
|
|
|
|
|
Show Posts
