Interesting. However, I don't see how one satoshi can be a transaction with dust limit of 546 satoshis.
If each share will be represented by 546 satoshis, nasdaq will need 546x[2.1bil shares]=~1.1trillion satoshis daily=11 thou bitcoins daily (three times more than daily production).
If each transaction is represented by 546 satoshis, then 546X2.5 mil daily=~1.1 bil satoshis=100 bitcoins daily-more doable.
However, once these satoshis are associated with shares, they will not be able to be associated with newly traded shares, so a constant flow of satoshis will be directed toward shares and these will be removed from daily circulation (until those shares are traded), hence a pool of available satoshis will be constantly depleting.
You are also forgetting transaction fees. Especially when the transacted amount is so small, the fee will be required in order to ensure it gets included in a block. So you would have to add 0.0001 BTC per transaction on top of that (10,000 satoshis). Now those numbers get much, much bigger. (ref: https://en.bitcoin.it/wiki/Transaction_fees) The fast majority of that daily volume are HFT algorithms holding onto securities for very brief periods of time. This type of use case does not need a colored coin solution. A colored coin solution is more appropriate for real investors who purchase and hold a security for some real period of time. I could imagine the NASDAQ creating a 2 tier system, where there is an in-NASDAQ market for short lived HFT trading usage, and also a colored coin market where securities can be traded and withdrawn onto the block chain. Trading and withdrawing onto the block chain would be marginally more expensive, but would make sense for real investors buying and holding. The HFT volume would stay on the current system centralized since that would be cheaper and HFT does not need blockchain security. I think if you took HFT type trades out of the transaction volume, you would now have something reasonable for a colored coin market. |
|
|
|
|
Every dollar you have that is not invested in bitcoin and kept in USD, is in effect a short against bitcoin.
|
|
|
|
Gold is tangible asset. Hard to convince older generation to hold bitcoin.
The need to convince the older generation about anything is highly overrated. The people we need to worry about convincing are the people who will be producing new wealth in the future - not those who are already (for the most part) done producing. I don't know about that. Just look at the money Soros and Buffet spend on various NGO's to "educate" us dumb plebs. Would be useful is some of that went towards reality and not Keynesian fantasy. |
|
|
|
@rocks, the chart already assumes rewards of 25 BTC/block. It will, however, need to be adjusted (down) when we hit 12.5 BTC/block.
Yeah, saw that after skimming the paper this afternoon. Am curious to re-run the numbers if I have time in a bit to see how the results look with a 12.5 BTC/block reward and other future expected rewards. If I get around to that will post back. |
|
|
|
Wow, what a skeptical bunch. Decentralization is the way to go. I think decentralization will be huge over the next couple of years. Continue giving your money to Facebook then I suppose.
Mainstream people have absolutely no interest in bitcoin as an alternative currency. They need an incentive, this gives them that.
You're right. Bitcoin has a multi billion dollar market cap, and over a billion dollars in cash invested in VC backed firms and other services. We should scrap all of that and dedicate the whole project to your decentralized messaging app. Go away with your spam nonsense. |
|
|
|
Meni Rosenfeld does something similar to what you're suggesting in his "Analysis of hashrate-based double-spending" paper from December 2012. I haven't looked into this paper in detail, but this table from Section 6 caught me eye. It allows you to figure out how many confirmations you should wait depending on how large the transaction is in addition to the attacker's hash rate.  I'd be interested if you can think of ways to extend this work. That is interesting, thanks. Will have to take a deeper look. It seems the main remaining variable is what is the current average block reward. I assume this was calculated when rewards were 50BTC and these numbers probably will adjust for a 25BTC/block reward. Adding the average/expected block reward to the mix would enable one to determine how secure a confirmation chain is when block rewards are determined by variable fees & usage, and not a static inflation rate. If anything, these numbers show that even if an attacker gets into the 30% range, 6 confirmations still secures a significant amount of value. It is only when an attacker approaches 50% that you need longer confirmation chains, but if a determined attacker has the resources to push 40%, they should be able to reach the fabled 50% where it doesn't matter anymore. that's kind of a weird chart b/c it is denominated in BTC. even Meni says so:
These values should be taken with a grain of salt, because of the many modeling assumptions made
"value" will vary greatly depending on whether 1BTC buys you a loaf of bread vs an island.
Denominating in BTC probably makes the most sense because: 1) Bitcoin is a closed system and 2) Mining will always tend towards a given equilibrium given the current $/BTC and the current BTCreward/block. To look at it another way, if 1BTC buys you an island you can be sure that there is a massive amount of mining power behind the network and any attacker trying to achieve 20% of the hash rate would need to spend proportionally just as much more effort to reach that 20%. |
|
|
|
I think there's two ways to look at it:
1. Clearly, if an attacker has 50.0001%, then he has a 100% chance of eventually forging the longest chain. If the attacker has 49.9999% instead, it makes sense that he'd have almost 100% chance, but not quite (why would it suddenly drop to less than 50%?).
2. It's the attacker who gets to choose when to broadcast the attack chain. Just by random luck, there's a good chance that at some point the attacker will hit a lucky streak and mine several blocks in quick succession. When he hits this lucky streak and pulls ahead of the honest chain, he broadcasts his attack chain.
Thanks for the explanation guys. OK, now understand that the equation calculates how likely it is that at some point after 6 confirmations an attacker will gain the longest chain, publish it, and get the rest of the network over to that chain. This is just the odds though, not the cost. It would be interesting to see the expected cost of such an attack though. If an attacker with 45% hash rate has a 96% chance of eventually gaining the lead for a moment, then a good portion of that probability is most likely in the long tail of many blocks from now. There should be an equation that calculates the average or expected cost of such an attack, such as by 50 blocks the attacker has x probability of succeeding, by 100 blocks y chance & by 10000 block z chance. And of course there is the possibility that the attacker has spent months without gaining the lead, and has lost all of those block rewards. I think we'd see that the expected cost is quite high, even for a 45% attacker. i.e. Even if you knew that the counter party to your bitcoin transaction had 45% hash rate and would use it against you, then 6 confirmation would still be enough for the value of a car or house, since an attack would cost more than that, half a day of confirmations would be enough for a skyscraper, and a day of confirmations for an island. This seems OK to me. |
|
|
|
BTW, it is also a myth that >50% is needed to successfully double-spend with a "51%-attack". It is needed to guarantee success, but with a substantial share <50% you still have a significant probability of success for whatever finite number of confirmations is considered "enough" by the recipient. If the payoff is high enough this can easily be worth it.
This is where the 6 confirmation rule comes from. Even if someone had 49% hash power it, the probability that they could role back 6 blocks is negligible. So if you have 6 confirmations the odds that a high but less than 50% attacker could reverse a payment is too low to matter. But once you have 51%, you can always determine the longest chain and could eventually roll back any number of blocks. No! 6 confirmations comes from the assumption of the attacker having 10% hash rate or less (represented by q in the quote below) Solving for P less than 0.1%...
P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340
As the attacker's share of the the hash rate approaches 50% the situation gets much, much worse. At 45% in his example you need >340 confirmations for the attack to succeed less than 1/1000. At 49% the odds of reversing 6 confirmations may not be 1/1000, but they are still quite low probability, low enough that it is not a reliable attack. An attacker with 49% of the hashpower will succeed in double-spending a 6-confirm transaction 96% of the time:  I understand the probability equations, but am trying to understand the logic in how they are being used and how an attacker with less than 50% could have an almost 100% chance of forcing a new longer chain. I would expect that no matter what the probability of being successful would be less than 50%. Let's say I had 49% of the hash rate. I then made a payment (transaction A) to someone, who after 6 confirmation would consider the transaction valid and would then transfer something else over to me. I also immediately construct a different transaction B that double spends and invalidates transaction A. Transaction A broadcasts to the network, and 51% of the hash rate starts hashing on that transaction. Simultaneously I dedicate my 49% of the hash rate on creating confirmations on transaction B. I also have to keep my chain a secret, so that the P2P network will only see the chain with transaction A and at some point acknowledge 6 confirmation on transaction A. After this happens the other person transfers something to myself (lets say a title to a car). Once I have received my counter payment (the title) my goal is to now reverse the original transaction A, by announcing a new longer chain containing transaction B to the network. In order to reverse this, I now have to have a longer chain (i.e. 7 or more) in order to make the the network reorg and switch to my chain (if I only announce a new chain of 6, the network will continue to use the first chain of 6 it received). Since my hash rate is 49%, and the rest of the network has 51%, it seems that the odds of the secret chain I've been working on (with 49%) being longer than the chain the rest of the network (51%) has been working on is less than 50/50. And again since my chain needs to be longer to force a reorg, the odds are less. I'm not saying that a 49% attacker cannot reverse 6 confirm transactions, but it seems it has to be a bit less than 50% of the time. |
|
|
|
BTW, it is also a myth that >50% is needed to successfully double-spend with a "51%-attack". It is needed to guarantee success, but with a substantial share <50% you still have a significant probability of success for whatever finite number of confirmations is considered "enough" by the recipient. If the payoff is high enough this can easily be worth it.
This is where the 6 confirmation rule comes from. Even if someone had 49% hash power it, the probability that they could role back 6 blocks is negligible. So if you have 6 confirmations the odds that a high but less than 50% attacker could reverse a payment is too low to matter. But once you have 51%, you can always determine the longest chain and could eventually roll back any number of blocks. No! 6 confirmations comes from the assumption of the attacker having 10% hash rate or less (represented by q in the quote below) Solving for P less than 0.1%...
P < 0.001
q=0.10 z=5
q=0.15 z=8
q=0.20 z=11
q=0.25 z=15
q=0.30 z=24
q=0.35 z=41
q=0.40 z=89
q=0.45 z=340
As the attacker's share of the the hash rate approaches 50% the situation gets much, much worse. At 45% in his example you need >340 confirmations for the attack to succeed less than 1/1000. At 49% the odds of reversing 6 confirmations may not be 1/1000, but they are still quite low probability, low enough that it is not a reliable attack. |
|
|
|
BTW, it is also a myth that >50% is needed to successfully double-spend with a "51%-attack". It is needed to guarantee success, but with a substantial share <50% you still have a significant probability of success for whatever finite number of confirmations is considered "enough" by the recipient. If the payoff is high enough this can easily be worth it.
This is where the 6 confirmation rule comes from. Even if someone had 49% hash power it, the probability that they could role back 6 blocks is negligible. So if you have 6 confirmations the odds that a high but less than 50% attacker could reverse a payment is too low to matter. But once you have 51%, you can always determine the longest chain and could eventually roll back any number of blocks. |
|
|
|
The discussion is not necessarily about performing an attack, it is about incentives and concentration of voting power. If the big pools want lower fees and/or a higher soft limit, because they are at a competitive advantage in providing the infrastructure required for it, then they get it, regardless of what the rest want. Likewise it has always been the prerogative of pools which transactions to include, so if they want to block some (as eligius does, I understand) then they will do that too. Neither of these rise to the level of an attack that causes the pool to be viewed as hostile and shunned by the community, but it gives disproportionate influence to a few actors.
Increasing blocksize increases the # of transactions allowed, which in turn increases the usage of bitcoin and the # of fee paying transactions, and this is how miners and pools will increase their fees. Increased fees lead to more monetary incentive to mine, which increases the hash rate and also the # of independent miners. This increases the bitcoin security mechanism. gmaxwell on the other hand just suggested that we should lower the blocksize below 1MB in order to increase fee pressure. http://sourceforge.net/p/bitcoin/mailman/message/34090559/This is frustrating; from a clean slate analysis of network health I think my conclusion would be to _decrease_ the limit below the current 300k/txn/day level.
This is simply absurd. His suggestion of limiting bitcoin to less than 1tps, as a means to increase the value of the bitcoin ecosystem is simply wrong. To put it simply, a bitcoin that most people can not use directly and where blocks only contain 1000 transaction each, will generate a much smaller amount of economic value in fees than a bitcoin that is widely adopted by people and where blocks contain billions of transactions each. |
|
|
|
C'mon that's totally unfair to the majority of developers (again). It is not simply a 'sacred cow' and that totally over-simplifies the problem while casting negative aspersions against most of the developers.
These guys have worked themselves to the point of mental exhaustion in some cases to keep this thing scaling up to handle the transaction growth rate thus far and have made huge advances. They would all simply agree (ya know, a consensus) to raise the limit if it was such an obvious 'fix', it is not and there are no obvious fixes, that is just wishful thinking by the unthinking majority. Raising the limit is the last ditch 'suck it and see' hail mary pass when everything else has been optimised as much as possible ...
If the limit gets raised substantially above the technological improvements growth rate I'll be pulling the vast majority of my investment out because it is not going to be operating like we thought it would, i.e. it won't be a clearing and settlement digital gold network but a paypal2.0, fun internet googlesque reversable, traceable payments network
If the limit is raised to 20MB tonight, nothing would break. The reason is because the average blocksize would not magically jump to the max. It would stay exactly where it is today (~400kB/block). What would happen is the average blocksize would slowly continue to scale up over a matter of years, and as the average blocksize slowly scaled up, development on the core would continue to improve bit by bit to enable continued scaling. This is how SW development works. If you keep the 1MB blocksize limit, then there never is any pressure on the code to encourage scaling improvements. Scaling improvements are done in real time as issues are discovered or anticipated, but this only happens if the blocksize continues to increase. Google is a good example here. In the 2000s they completely rewrote their search engine from scratch something like 5 times in 7 years. Not revisions, but rewrites. You might say that was bad planning, but the reality is scaling problems and their solutions can only be discovered by scaling up usage and discovering them along the way. Bitcoin is about market based solutions to problems. Unlock the barriers and let the market find a way. |
|
|
|
from gmax:
"So far the mining ecosystem has become incredibly centralized over time."
i totally disagree.
I guess it is in the eye of the beholder. I still see 3 pools with >50%. The other tiny little slices don't matter at all as long as the top 3 agree and if even two of them agree, the tiny slices still hardly matter at all. Is it better, worse, or about the same as in the past? Maybe some people are complaining about centralization when they actually mean they are disgruntled about competition making mining at home less lucrative than it was in the good old days. This |
|
|
|
from gmax:
"So far the mining ecosystem has become incredibly centralized over time."
i totally disagree. the trend has been back towards decentralization since ghash and ghash has been punished accordingly by the market down to a measly 3.6%. what i see in this graph is a normal, expected distribution gradient from large to small share. btw, gmax has been complaining about mining centralization since at least 2012 but yet here we are. why do we accept his arguments on this when there hasn't been one major incident of a 51% attack?:
What people seem to keep missing in this "mining is centralized" claim, is that pools are not miners. They are services with ZERO barriers to entry and exit from the mining community. As long as there is ONE honest P2P node who would publicly flag that a pool was behaving badly (an assumption I believe will always be true), then the pools can not abuse their position. If any corrupt pool, or collection of corrupt pools, tried to falsify the record, it would immediately become public and that pool would lose most of it's miners in a matter of hours. Miners could simply switch to another honest pool, and there will always be an honest pool to switch to. This would completely destroy the future profit stream for an established pool. Why the heck would anyone try this, especially given that it would be a futile effort? |
|
|
|
These guys have worked themselves to the point of mental exhaustion in some cases to keep this thing scaling up to handle the transaction growth rate thus far and have made huge advances. They would all simply agree (ya know, a consensus) to raise the limit if it was such an obvious 'fix', it is not and there are no obvious fixes, that is just wishful thinking by the unthinking majority. Raising the limit is the last ditch 'suck it and see' hail mary pass when everything else has been optimised as much as possible ...
If the limit gets raised substantially above the technological improvements growth rate I'll be pulling the vast majority of my investment out because it is not going to be operating like we thought it would, i.e. it won't be a clearing and settlement digital gold network but a paypal2.0, fun internet googlesque reversable, traceable payments network
You are doing the same thing you are accusing others of doing. There is no consensus or even an easy answer, whether Bitcoin should be a "clearing and settlement digital gold network" or a "payments network" (I don't think too many want it to be reversible and traceable but you are injecting that as a form of commentary). If there were an easy answer, it would already be accepted as consensus, but there isn't and it isn't. Implicitly, decentralised => clearing and settlement digital gold network centralised => reversable, traceable payments network (without thinking that is not well-known by now). The only thing that needs to remain decentralized is the mining process. As long as mining remains decentralized bitcoin will continue as a "clearing and settlement digital gold network". The P2P network can become a more centralized pool of services that run in AWS, but it is the miners that determine the longest chain and the official record. Since most mining is done through pools already, miners are not exposed to the blocksize. It could be 1MB or 1TB, the work presented to a miner is the same and the security model is the same as what we have today. This is all that matters. Additionally, most users today already use SPV wallets. These rely on trusting the P2P network peers and not on your own verification. This seems to be OK with most people. In SPV mode whether the P2P network has 100K nodes or 1000 nodes, the security model is the same. I fail to see how the security model changes as the blocksize scales up and P2P nodes become more like professional services. The mining security model and the SPV usage model are the same. |
|
|
|
from gmax's response this morning:
"Thanks Matt; I was actually really confused by this sudden push with
not a word here or on Github--so much so that I responded on Reddit to
people pointing to commits in Gavin's personal repository saying they
were reading too much into it.
So please forgive me for the more than typical disorganization in this
message; I've been caught a bit flatfooted on this and I'm trying to
catch up. I'm juggling a fair amount of sudden pressure in my mailbox,
and trying to navigate complex discussions in about eight different
forums concurrently."anyone who is even half aware of his surroundings could see that Gavin' proposal was coming. wasn't i on this thread talking about this immediately after this video last month?: https://www.youtube.com/watch?v=RIafZXRDH7wbut even way before then it was entirely clear that there was a schism developing btwn Gavin, who has been pushing for an even more radical progressive block size increase, and the rest of the Blockstream devs looking to continue capping at 1MB while at the same time pushing their version of SC's. it was clear, to me at least, that he would have to pull rank at some point. and that is not a bad thing; that is what leaders do. he is the lead dev after all. gmax is exhibiting typical behavior when someone suddenly finds their back up against the wall defending what clearly is a minority opinion. "poor me, they suddenly sprung this upon me with absolutely no warning!" We have an interesting situation here where a majority of developers seem to be against the blocksize increase, but a clear large majority of users seem to support it. If this is the case, bitcoin will likely go with what the majority of users prefer to do. The devs do not control it. This is opposite BTW to our FED system. Think of the FED board of directors as the same as bitcoin developers. Only here the FED's BoD are able to assert their views on users against their will. This blocksize debate demonstrates very clearly how the motivations of those in "charge" are often opposite to the needs of those not in charge. The US has ceased to do what the majority of it's users (the people) have wanted for a while. But Bitcoin is a true democracy, it will ignore it's developers, and follow a clear majority of users. |
|
|
|
Let's say for example I am a Snowden sympathizer and the government has outlawed payments to Snowden and the government also suspects that I might want to illegally give Snowden payments. In such an environment identifying the creation of a payment channel to Snowden might be enough for the government to determine guilt, regardless of whether or not they identified the actual payments. So if they knew my payment code and Snowden's payment code, could scanning the blockchain history result in identifying the payment channel (not the actual payments).
I understand this situation is a bit of a reach, just trying to understand it though. An observer will see that Snowden received a payment code, but they won't be able to read whose payment code it is. The only way they learn it was you who set up the channel is if they have some other way to trace the coins you used to do it. A good client would be sure to use mixed coins for notification transactions. OK I think I got it. So both parties can individually control their anonymity then. If Alice only uses mixed coins for a notification transaction she can be confident that she can not be tied to the payment channel. Similarly if Bob correctly handles the received notification transactions he can be confident that he can not be tied to the payment channel. Thanks for the explaination |
|
|
|
Both Alice's and Bob's payment codes are known since they are public and in addition the time frame of the notification transaction is also known. Couldn't such an agency then look for all transactions in that specific time frame that might be a notification transaction and try them until finding one that matches? Does such an attack gain information for Eve, or are there reasons this isn't possible or useful? If an attacker already expects Alice and Bob to transact, then seeing a notification transaction doesn't tell them much. The attacker won't be able to connect the notification transaction with the actual payments. See: https://www.reddit.com/r/Bitcoin/comments/34prd6/i_made_a_3d_printed_stainless_steel_bitcoin/cqy16lrIf an attacker knows that certain UTXOs are associated with a particular individual (Bob), and if the attacker then sees those outputs used as inputs to a transaction which creates an output at a known notification address (Alice's), then the attacker can assume a probability that the Bob will send some bitcoins to Alice at some point in the future.
Bob might have sent a decoy notification to Alice, so the attacker can never be sure. All the attacker knows that Bob will sent Alice somewhere between 0 and 232 payments to Alice between the time of the notification transaction and forever.
The attacker might assume that any payments appearing in the mempool immediately following the notification transaction are a payment between Bob and Alice, but that's a problem that tends to solve itself as the transaction rate increases and can be addressed by intelligent clients which make sure to put a random amount of temporal separation between the notification transaction and the first payment. OK, thanks that helps. So this is saying that the only knowledge gained is that Bob and Alice setup a payment connection, but even with that an attacker couldn't identify what payments happened in the future (or even if any payments happened at all for that matter). So if Bob inadvertently used the notification payments incorrectly, the only information lost is that a payment channel was established between Alice and Bob. Is that right? If an attacker already expects Alice and Bob to transact, then seeing a notification transaction doesn't tell them much.
I'm not 100% sure on this. Let's say for example I am a Snowden sympathizer and the government has outlawed payments to Snowden and the government also suspects that I might want to illegally give Snowden payments. In such an environment identifying the creation of a payment channel to Snowden might be enough for the government to determine guilt, regardless of whether or not they identified the actual payments. So if they knew my payment code and Snowden's payment code, could scanning the blockchain history result in identifying the payment channel (not the actual payments). I understand this situation is a bit of a reach, just trying to understand it though. |
|
|
|
Thanks for the diagrams, they were helpful. Quick question. If I understand the notification transaction correctly, in order to maintain privacy on future payments, payments to the notification address can not be associated with Bob's payment code, and so Bob has to make sure that payments to this notification address are never associated with him. And if they were then the privacy is lost. If this is the case (and I may be wrong) I was wondering about potential attacks here. For example are timing attacks possible? i.e. imagine the situation where a government agency monitoring the internet knows that Alice intended to initiate a payment to Bob for an online purchase at exactly 8:52pm. Both Alice's and Bob's payment codes are known since they are public and in addition the time frame of the notification transaction is also known. Couldn't such an agency then look for all transactions in that specific time frame that might be a notification transaction and try them until finding one that matches? Does such an attack gain information for Eve, or are there reasons this isn't possible or useful? |
|
|
|
|
If there is one silver lining to the block size increase arguments, it is that it shows how difficult it is to get a majority of participants in a decentralized system to agree to anything. Overall this is a good thing, since the default is to keep bitcoin the way it is which makes it harder to push in regulatory changes that are against it's purpose.
|
|
|
|
|
Show Posts
