Solution:
cooperate with other miners and connect directly to each other. then you know as soon as a block comes out. and you would be surprised how fast information propagates in the network. i normaly never wait longer than 5 seconds to see a transaction, but i also have over 60 connections at any given time.
That is an excellent idea. Perhaps we could even come up with some sort of relay system for the miners to use to automatically convey this information around so that we don't have to directly manage the connections ourselves. |
|
|
|
This guy is an idiot. He actually said this. the idea is to make something unforgeable as cheaply as possible. This is why all modern currencies are fiat currencies instead of being made out of gold. Currencies aren't fiat instead of gold because of forgery. To make such an asinine and ill-informed statement says to me this guy don't have a clue. Are you sure? I always figured that we used paper money (and database entries) because it takes a lot of work to print a dollar bill, while counterfeiting gold only requires that you find another metal with the same color, density, specific heat and electrical resistance. How hard could that be?  |
|
|
|
The block explorer reorg log is showing 15 reorgs in the last 8538 blocks. We generally assume that about half the forks lead to a reorganization in a given node*, so that is about 30 forks. That is about one fork per 284 blocks, which is close to my estimate of 300 blocks per fork. So, I would expect a two block fork every 90 thousand blocks or so, maybe every 80 thousand using the block explorer data. That is every year and a half, by the way. A three block fork should show up under honest circumstances about once every 450 to 500 years. A shorter block time target would probably lead to more frequent forks, measured in blocks per fork, but it isn't obvious what the function would be. Halving the block time target, for example, would lead to probably more than double the forks per year. It could probably be simulated, but hasn't that I know of. * The best predictor of which block will win in a fork is the fraction of the network seeing that block. If we assume that the distribution is more or less random, they should both average out to around 50%. |
|
|
|
aha! you get it now, great.
Yes it sounds impossible at first, but I think it's naiive to immediately dismiss it as a non-starter. There can be very clever ways to do things.
In particular, the "break ties using TX fee" approach I described IS a solution; whether it is the best is what I was asking, perhaps there is a better one. Note that you can think of my scheme as trading paying to secure with hash power for paying to secure with already existing bitcoins.
In fact, a "bidding war" is actually not much of an issue here because the auction will end up being an ALL PAY auction, where even the losers pay.
In other words, this scheme allows an auxilliary block chain to literally pay miners/"transaction builders" for securing their chain with bitcoins, rather than by contributing hash power.
This is actually quite nice! It means you could do merged mining without requiring the pool owners/miners to update their software at all. Instead, namecoin enthusiasts would just be paying TX fees for the "winning" namecoin root.
Note also you could essentially simulate the existing system with my system. The "merged miners" would basically set the TX fee in such a way that it costs them an expected value of zero: because they are mining, they have some chance of getting that massive TX fee, while on the other hand otherwise they just pay a small portion of it (the namecoin root TX would have many inputs so many would pay).
Except that your scheme will never catch on because it won't work for reasons that I think you've pointed out. I mean, essentially, you are describing a system that does not exist and is in no danger of actually getting built, and then knocking down your own straw man. So, yeah, you can make whatever transactions you want, even encoding hashes for other systems, and miners will blindly include whatever garbage you put into the script and "work for free". But you can't turn that into a useful system that other people will use because the thing that would make it useful would also make your hypothetical problem impossible. |
|
|
|
If there are 21 Million bitcoins potentially and someone lends someone 1 million bitcoins with .5% interest, 20,000 bitcoins are the interest. In fiat currency the interest would be stolen off, in bitcoins, it cannot really be taken anywhere, so the question is semi-redundant and a joke in fact. It's a trick question of sorts.
The situation you describe is not a problem at all. Even (taking this to absurdity) if you borrowed all 21 million bitcoins at 5% interest and had to pay back 22,050,000 bitcoins, more than there exist, this would not be a fundamental problem for the monetary system. You would just have to present goods and services to holder(s) of Bitcoins at an agreed upon value of BTC22,050,000. This is how the COMEX continues their long running fraud, and always will be able to. Also, see the term "evergreen" in relation to gold leases. |
|
|
|
|
The official rationale is that 10 minutes is a round number.
There is a trade off between traffic/storage/etc and confirmation latency. As far as I know, there is no way to objectively measure the goodness or badness of either of those, so there is no optimal choice. 10 minutes seems to be "pretty good" so far.
|
|
|
|
You need to think this scenario through a bit more. Ask yourself what circumstances must occur for a node to be unable to rejoin the world after a network split. I'll give you two hints. For the network to get stuck, there needs to be mining power on both sides of the split. And the duration necessary for the split to become permanent is directly related to the split ratio in a way that makes an honest split of sufficient size and duration to be extremely unlikely.
I need to research this more, yes. But what I had in mind is a targeted attack against a particular node, trying to isolate it from the network and feeding it blocks distinct from those known to the rest of the network. I think it's possible to do that, and while I don't know if such an attack can be lucrative, the victim node can never recover if it adheres to your protocol rigorously. But if it turns out to be a viable means for increasing security of large transfers (for which a day of waiting would be acceptable) then by all means, proof of stake won't be needed. We don't care about one node, we care about the network. If one node gets screwed, the operator of that one node can just delete the block chain and start over. Or at least just the bad blocks. And a node can protect itself by having lots of connections. |
|
|
|
And I've softened slightly in my criticism of stakeholder signature schemes. I can see how they could be useful, in theory, but only as an addition to the current header hashing system. But as a standalone system, it is still pointless. Oh, and there are horrible operational problems that will turn up if you ever try to implement it. For starters, it requires the largest wallets in the world to be online, and they are exactly the sorts of wallets that you want to keep offline. And the problem of gathering, distributing, and verifying signatures corresponding to 3.5 million BTC (and growing every day) is hardly unsolvable, but still immense.
I also prefer a mixed hashing-stakeholder system, but don't agree that the standalone system is pointless. I agree with you about the large wallets online issue. However, this in itself is a serious flaw that needs to be addressed. To solve the problem, why not allow users to specify txn limits on their wallets? For example, I create a wallet that has a user-specified send limit of 1 BTC per block. The wallet also has a user-specified emergency address where the money can be sent without limit. The wallet-specific txn limit and the safety address are recorded in the blockchain. If I detect unauthorized txns, I can empty my remaining coins into the emergency wallet. If I'm really securing a lot of money, I can create a 'safety' chain of wallets with txn limits. To steal a reasonable amount of money, the attacker would have to control every single wallet in the chain. Voila, a large wallet can be stored online safely. As far as gathering, distributing, and verifying... You only really need information from people with a relatively large amount of coin. You could just place a limit on the minimum investment necessary to mine. Smallholders would not need to participate in verification. Voila, the network is much smaller. Transaction limits (roughly) triple the size of the blocks. First, someone sends you money, then you send it to yourself again, but this time with your wallet policy information included. Not a big deal today, but in the future... One other objection to the stake idea. Whatever function we make that system do is power that we are granting to major coinholders over the minority network. The smaller the number of entities involved, the easier it will be to abuse, and without recourse. Extreme care must be exercised. |
|
|
|
That 51% attack is really easy for countries/large companies. I bet that Google/Amazon could easily take over the network if they wanted to.
I think we would notice if Google or Amazon diverted enough of their power to the problem. They have a lot of computers, but they aren't idle, they are doing things. Profitable things. Public things. Things that everyone would notice if they stopped doing. |
|
|
|
I should point out, yet again, that it would be trivial to change the attack protection function from a multiplier to an exponent. If nodes refused to revert the block chain unless the change in difficulty was more than 2^(n-5) times the current difficulty when n>6, a vendor could wait a few of hours for a big transaction and be sure that all of the computing power in the galaxy would be unable to reverse it.
This throws away exactly what the "longest chain" rule was supposed to prevent - a node being unable to catch up with the rest of the network after a period of isolation. You'll want some way to recover by checking which branch is the real one... From a "trusted" source, whose signature you'll want. So might as well make it part of the design. You need to think this scenario through a bit more. Ask yourself what circumstances must occur for a node to be unable to rejoin the world after a network split. I'll give you two hints. For the network to get stuck, there needs to be mining power on both sides of the split. And the duration necessary for the split to become permanent is directly related to the split ratio in a way that makes an honest split of sufficient size and duration to be extremely unlikely. For starters, it requires the largest wallets in the world to be online, and they are exactly the sorts of wallets that you want to keep offline.
As I mentioned you don't need the private key required to sign proof-of-stake to be the same one needed to send coins. You'll keep your sending key well hidden offline, while the stake key will be online doing signatures. If someone steals your stake key, you just move the coins to a new address. So, just add a second hash to each script with a stake signing key in addition to the existing spend signing key? I'm not a big fan of that, but I can see how it would nullify that particular objection. And the problem of gathering, distributing, and verifying signatures corresponding to 3.5 million BTC (and growing every day) is hardly unsolvable, but still immense.
Given the distribution of bitcoins, I don't think 3.5M BTC is that many addresses. I bet it would be a lot more than you think, if you consider the fraction of bitcoins held in wallets that are unlikely to participate. At any rate, like I said, hardly unsolvable either way. |
|
|
|
...
Overall if a govern wants to kill bitcoin, it's still a small investment to do.
Is there a thread essentially wargaming scenarios required to take over bitcoin? searched "51%", "takeover blockchain" etc. Not a single thread, no. But thousands of them are here, as each new person makes their obligatory post describing whichever of the 5 or 6 well known potential/imaginary weaknesses they happen to notice first. Also, see the Weaknesses page on the wiki. |
|
|
|
This can happen sometimes, it just means who ever found those blocks decided not to include those transactions, it will most likely be in the next few blocks.
I keep reading this over and over... Now, million bitcoin question: How the hell do they decide which transactions to include? Or does this question need another thread?  Priority is calculated from the size of the transaction (in kb) and the length of time the sending account has been idle. This is necessary to prevent transaction spam. If your transaction is low priority, the client should suggest a fee Be included. If it's an algorithm that calculates the transaction priority and decides if it's included in the block or not, people should stop saying that whoever finds the block is the one to decide to include transactions(or not). If it's like you say, miners don't decide s***. The software does, without any input from them. The big pools actually do customize their rules. BTC Guild never pays fees on their own payouts, for example, because their node software will always accept them, even if other pools do not. And I think that slush will automatically accept any and all transactions without regard to fees paid, but don't quote me on that. |
|
|
|
The reality is that Unicode already has the de-facto BTC symbol B⃦ and that both new "proposals" are simply more or less font-specific variations of that. No action needs to be taken, and probably Unicode will not take it, because the glyph is already part of Unicode. All that needs to be done, is for people to optimize fonts for displaying it nicer.
Ahh, begging the question. How rarely do I get to use that phrase correctly. 42 + 20E6 is not de-facto anything. This thread, and the many clones of it, are prima facie evidence of non-de-facto-ness. It is something that a few people have used, one option out of many with no clear majority that I've seen. Having a single glyph, rather than an overlay, would be very handy. Also, the proposals so far are both wildly different from the overlay combination. |
|
|
|
I know that this will in all likelihood will never happen. but i like the idea better where you just keep a tab or account at each restaurant you go to. an opensource app could be developed that could be run on a simple webserver that would handle the basic needs of a fast food place like McDonalds. amounts like 20$ or 1BC as of now would be safe to use after only 1 or 2 confirmations. so you could order your food on a smartphone or just add money to your account before you go, then once you arrive you tell them some information about your account or use a card or something and they make your food or you order it.
Another situation, a mall
you go to the mall and at the entrance is a bitcoin terminal. you put coins in the terminal and it shoots out a cheap card that can be recycled. by the time you walk to the first store yo buy somthing 10 minutes would have passed and you could have your merchandise. when you leave you put your card in and it releases any unspent coins.
With these ideas, bitcoin would still be decentralized, or more so than if we just all dumped our money into 1 company, which i do not think the good solution is.
Some day, I expect to see VISA and MasterCard as the big players in these systems. It will be easier for users to only have to track a few services like that, rather than one for each store/chain/mall. But at least with Bitcoin, everyone has the choice, and since the software for it should be dead simple, choices will be abundant. |
|
|
|
The fact that you are dealing with lots of fraud is perhaps the best reason to look into Bitcoin. Zero percent chance of chargebacks and "fake cards." Bitcoin is more safe than other forms of online payment.
Exactly. Just ask Allinvain or MagicalTux about how secure Bitcoin is! That's really a different issue. And if someone is concerned about that, they can cash out more or less instantly. |
|
|
|
|
If there had been more than a month's notice, I would have made it happen. I haven't been to NYC since I was a little kid, I have family in CT, vacation time at work that I must burn before the end of the year, and I would love to have gone to the first one.
But this was just too short notice.
|
|
|
|
|
I should point out, yet again, that it would be trivial to change the attack protection function from a multiplier to an exponent. If nodes refused to revert the block chain unless the change in difficulty was more than 2^(n-5) times the current difficulty when n>6, a vendor could wait a few of hours for a big transaction and be sure that all of the computing power in the galaxy would be unable to reverse it.
That is a slight exaggeration. It would really take a day or two for that level of security, particularly considering that we are unable to estimate non-human computing power. But 2 hours would require an attacker to have about 64 times as much power as the rest of the network combined, and 3 hours would boost it to around 4096 times as much.
And I've softened slightly in my criticism of stakeholder signature schemes. I can see how they could be useful, in theory, but only as an addition to the current header hashing system. But as a standalone system, it is still pointless. Oh, and there are horrible operational problems that will turn up if you ever try to implement it. For starters, it requires the largest wallets in the world to be online, and they are exactly the sorts of wallets that you want to keep offline. And the problem of gathering, distributing, and verifying signatures corresponding to 3.5 million BTC (and growing every day) is hardly unsolvable, but still immense.
|
|
|
|
When a single entity has 51% everyone is informed by their client and Bitcoin spending stops, the moment the attacker breaches 51% everyone using Bitcoin is told not to spend or accept until such a time as the attack ceases. Blocks are anonymous. How do you propose to figure out the distribution of hashing power? take a look at http://bitcoinwatch.com/ they have a hash rate distribution monitor right on their page, its live. By keeping an eye on the rate of block production with a known difficulty they can estimate the total network power, by looking at the blocks produced by any one pool in a given period with a known difficulty they can estimate that pools hashing power, since all major pools report his information (and even if they did not they have to tell miners when they found a block) we can accurately know what portion of the total hashing power is controlled by whom. So, the attacker is going to publish a data feed showing their hashing power prior to the attack? Or are you suggesting that we shut down the network whenever we can't account for at least half of the network power? |
|
|
|
good points, ttk2
I believe with a desire any chip manufacturer could overtake blockchain in their backyard, so almost any country could do it too then. this way you wont even know that they are setting up chip plants before it hits the network. don't need to wait for hi-end cards put up for distribution or even care about it. just build chip production plant targeted for hashing and or various processing tasks in clusters. little bit more expensive but certainly is doable still.
BTW I read somewhere that AMD produces somewhere in the range of 10-20mil chips a year for a specific GPU series architecture
The suboptical fabs are documented, reported, published and analyzed in gruesome detail by anal retentive mutual fund accountants. No major capacity is available for a clandestine project. |
|
|
|
|
Show Posts
