Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
Yes, if you are on a slow network then you are at a (slight) disadvantage. So? Chun mentioned that his pool is on a slow network, and thus bigger blocks give it an disadvantage. (Orphan rate is proportional to block size.) You said that no, on contrary those who make big blocks have a disadvantage. And now you say that yes, this disadvantage exist. Did you just lie to Chun? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: Block Size Increase Requirements
That orphan rate increase will go to whoever is producing the 20MB blocks, NOT you. This depends on how miners are connected. E.g. suppose there are three miners, A and B have fast connectivity between then, and C has a slow network. Suppose that A miners a block and B receives it in 1 second. C receives it in 6 seconds. This means that blocks mined by C during these ~5 seconds will be orphaned because B gets A's block first. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase Requirements
Stop trying to dictate block growth limits. Block size will be determined by competition between miners and availability of transactions, not through hard-coded limits. Do you even game theory, bro? It doesn't work that way. Mike Hearn described the problem in this article: https://medium.com/@octskyward/hashing-7d04a887acc8 But the solution he's proposing is ridiculously bad and unsound: he expects business owners to donate large sums of money towards mining. If it comes to this, what sane business owner will donate, say, 100 BTC to miners instead of seeking some alternatives? Proof-of-stake coins are already there. I'm well aware of theoretical issues with PoS security, but those theoretical issues aren't as bad as donation-funded cryptocurrency security. But you know what works? Mining fees + block size limit. Users and merchants are interested in their transactions being confirmed, but block size limit won't allow it to turn into a race to bottom. This is actually game-theoretically sound. I see now the temporary 1MB limit was a mistake. It should have gone in as a dynamic limit that scales with average block size. This means that miners will control it, and miners couldn't care less about things like decentralization and about problems of ordinary users. This means that in this scenario Bitcoin will be 100% controlled by few huge-ass mining operations. Possibly a single operation. We already saw GHASH.IO using 51% of total hashpower. Is that what you want? Miners are NOT benevolent. This was already demonstrated. They are greedy. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
With POW, a new node only needs to know the genesis block (and network rules) to fully determine which of two chains is the strongest. But this matters if a new node has access to the globally strongest chain. If attacker is able to block connections to legitimate nodes, a new node will happily accept attacker's chain. So PoW, by itself, doesn't give strong security guarantees. This problem is so fundamental people avoid talking about it. In practice, Bitcoin already embraces weak subjectivity e.g. in form of checkpoints embedded into the source code. So it's hard to take PoW purists seriously. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
Let's consider a concrete example: 1. User wants to accept Bitcoin payments, as his customers want this. 2. He downloads a recent version of Bitcoin Core, checks hashes and so on. (Maybe even builds from source.) 3. Let's it to sync for several hours or days. 4. After wallet is synced, he gives his address to customer. 5. Customer pays. 6. User waits 10 confirmations and ships the goods. (Suppose it's something very expensive.) 7. Some time later, user wants to convert some of his bitcoins to dollars. He sends his bitcoins to an exchange but they never arrive. He tries to investigate, and after some time discovers that his router (or his ISP's router) was hijacked. His Bitcoin node couldn't connect to any of the legitimate nodes, and thus got a complete fake chain from the attacker. Bitcoins he received were totally fake. Bitcoin Core did a shitty job and confirmed some fake transactions. User doesn't care that *if *his network was not impaired, Bitcoin Core *would have *worked properly. The main duty of Bitcoin Core is to check whether transactions are confirmed, and if it can be fooled by a simple router hack, then it does its job poorly. If you don't see it being a problem, you should't be allowed to develop anything security-related. If a node is connected to 99 dishonest nodes and 1 honest node, it can still sync with the main network. Yes, it is good against Sybil attack, but not good against a network-level attack. Attack on user's routers is a very realistic, plausible attack. Imagine if SSL could be hacked by hacking a router, would people still use it? Fucking no. A 3 month reversal would be devastating, so the checkpoint isn't adding much extra security. WIthout checkpoints an attacker could prepare a fork for $10. With checkpoints, it would cost him at least $1000, but more likely upwards of $10. That's quite a difference, no? I do not care what do you think about the reasons why checkpoints were added, but it is a fact that they make the attack scenario I describe above hard to impossible. Without checkpoints, you could perform this attack using a laptop. With checkpoints, you need access to significant amounts of mining ASICs. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Long-term mining incentives
I don't really see how you can protect against total isolation of a node (POS or POW). You would need to find an alternative route for the information. Alternative route for the information is the whole point of weak subjectivity, no? PoS depends on weak subjectivity to prevent long term reversals, but using it also prevents total isolation attacks. The argument that PoW is better than PoS because PoS has to depend on weak subjectivity, but PoW doesn't is wrong. Any practical implementation of PoW will also have to rely on weak subjectivity to be secure against isolation attack. And if we have to rely on weak subjectivity anyway, then why not PoS? Again, it is part of the security model that you can connect to at least one honest node. This is the security model of PoW-based consensus. If you study PoW-consensus, then yes, this is the model you have to use. But people use Bitcoin Core as a piece of software. They do not care what security model you use, they expect it to work. If there are realistic scenarios in which it fails, then this must be documented. Users should be made aware of the problem, should be able to take preventative measures (e.g. manually check the latest block against sources they trust), etc. The problem is that if everyone uses the same check, then that source can be compromised. Yes, this problem cannot be solved in a 100% decentralized and automatic way. Which doesn't mean it's not worth solving, does it? 1. There are non-decentralized, trust-based solutions: refuse to work if none of well-known nodes are accessible. Well-known nodes are already used for bootstrapping, and this is another point which can be attacked. So if it's impossible to make it 100% decentralized and secure, why not make it 99% decentralized and secure? 2. It is a common practice to check sha256sum after downloading the package, and this is usually done manually. Why can't checking block hashes against some source become a common practice as well? Also it's worth noting that these security measures are additive. Isolating a node AND hijacking one of well-known nodes AND hijacking a block explorer site user checks hashes against is exponentially harder than defeating a single measure. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed alternatives to the 20MB step function
Adaptive schedules, i.e. those where block size limit depends not only on block height, but on other parameters as well, are surely attractive in the sense that the system can adapt to the actual use, but they also open a possibility of a manipulation. E.g. one of mining companies might try to bankrupt other companies by making mining non-profitable. To do that they will accept transactions with ridiculously low fees (e.g. 1 satoshi per transaction). Of course, they will suffer losees themselves, but the they might be able to survive that if they have access to financial resources. (E.g. companies backed by banks and such will have an advantage). Once competitors close down their mining operations, they can drive fees upwards. So if you don't want to open room for manipulation (which is very hard to analyze), it is better to have a block size hard limit which depends only on block height. On top of that there might be a soft limit which is enforced by the majority of miners. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Block Size Increase
Just to add to the noise, did you consider linear growth? Unlike exponential growth, it approximates diminishing returns (i.e. tech advances become slower with time). And unlike single step, it will give people time to adapt to new realities. E.g. 2 MB in 2016, 3 MB in 2017 and so on. So in 20 years we'll get to 20 MB which ought to be enough for anybody. But if miners will find 20 MB blocks too overwhelming, they can limit it through soft work, based on actual data. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack and mempool might get out of sync with that of the border router. Why don't you use getrawmempool RPC call to synchronize mempool contents? -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Your scorched earth plan is aptly named, as it's guaranteed to make unconfirmed payments useless. Scorched earth makes no sense by itself. However, it can be a part of a bigger picture. Imagine an insurance service which will make sure that merchants are compensated for every scorched-earth or double-spend transaction, as long they pay 0.1% premium from their revenue. Merchants won't really care how it works as long as it does. All they know is that they need to use a particular open-source wallet, and they will receive a payment no matter what. You won't need a TTP to process each payment. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
The approach is how Bitcoin has always worked. Mike, you're making it worked before, and thus it will work in future kind of an argument. It is an extremely shitty kind of an argument. And it can be used to justify any kind of bullshit. E.g. any scamcoin which haven't yet collapsed will work forever. As I mentioned, it depends on scale. Highly sophisticated attacks are only feasible when scale is sufficiently big. I.e. when you have millions of dollars transacted each day it is one thing, but if you process billions of dollars, it becomes a whole another matter. The best way to profit from zero-confirmation payment disruption is through derivatives: short-sell Bitcoin while performing this attack. But this kind of an attack depends on a number of conditions: 1. highly liquid and reliable derivative market 2. sufficiently stable exchange rate 3. significant attack impact: lots of merchants relying on zero-confirmation payments, and lots of customers paying this way 4. significant amounts of capital available to the attacker These conditions are not yet met, and were never met in the Bitcoin's history so far. This is why I wrote 5 years from now, I believe that we might reach those conditions around that time. Direct impact of an attack might actually be low (but even if it is just 0.1%, 0.1% of 1 billion is 10 million, which isn't bad), but attacker might profit from the panic it causes. Note that I'm talking about situation where Bitcoin-aware PoS solutions are deployed on a big scale, so cost of upgrade might be huge. So anyway, in my opinion, it is actually great that Bitcoin is still relatively small: we have an opportunity to analyze and improve things. But you seem to be hostile to people who do that (and who do not share your opinion), which is kinda uncool. Also, you do not bother to back your intuition with rigorous reasoning, while also attacking people who offer alternatives with non-rigorous slipper-slope kind of arguments. Which is doubly uncool. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Miners are *not* incentivised to earn the most money in the next block possible. They are incentivised to maximise their return on investment. This would be right if you assume that all Bitcoin miners act as a single entity. In that case it is true that that entity's goal is to maximize overall ROI. But each miner makes decisions on his own. Are you familiar with a concept of Nash equilibrium, prisoner's dilemma, etc? The fact that nobody is using this kind of a behavior right now doesn't mean that we can rely on it. For example, Peercoin was horribly broken in 6 months after its release (e.g. people reported that they are able to generate 50 consecutive blocks simply by bringing a cold wallet online) and yet nobody bothered to exploit it, and it managed to acquire non-negligible market cap. So we have an empiric evidence that proof-of-stake miners are motivated to keep network secure. So, maybe, we should switch to proof-of-stake, if it was demonstrated that it is secure? There are good reasons to not switch to proof-of-stake. Particularly, the kind which is used in Peercoin is not game-theoretically sound. So even if it works right now, it can fail in a big way once attackers will really get around to it. An attack requires significant knowledge, effort and, possibly, capital, so it might be only feasible on a certain scale. So, well, anyway, suppose Peter Todd is the only person interested in maintaining replace-by-fee patches right now, and you can talk him into abandoning them. OK, perhaps zero-confirmation payments will be de-facto secure for a couple of years. And thus a lot of merchants will rely on zero-confirmation payments protected by nothing but a belief in honest miners, as it is damn convenient. But, let's say, 5 years from now, some faction of miners who own soon-to-be-obsolete equipment will decide to boost their profits with a replace-by-fee pool and a corresponding wallet. They can market it as 1 of 10 hamburgers are free if they have 10% of the total hashpower. So would you take a responsibility for pushing the approach which isn't game-theoretically sound? -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
Secure and client side validation don't really belong in the same sentence, do they? Well, client-side validation is mathematically secure, while SPV is economically secure. I.e. it is secure if you make several assumptions about economics of the whole thing. In my opinion the former is transfinitely more secure than the later. But it's more of a philosophical question, sure. The good thing about PoW-based consensus is that it is robust against version inconsistencies and various accidents of this nature up to a certain degree. But you hardly can depend on that: You know, The Great Fork of 2013 was resolved through human intervention, Bitcoin nodes were not smart enough to detect that something is going awry on their own. Naive proof-of-publication is very fragile in that respect, but you can easily bring back robustness. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication
I think what Gareth was getting at was that with client-side validation there can be no concept of a soft-fork. And how certain are you that the consensus rules will never change? Yes, it is true that you can't do a soft-fork, but you can do a hard-fork. Using scheduled updates: client simply stops working at a certain block, and user is required to download an update. In Bitcoin we can operate with some assurance that hard-forks will almost never happen, exactly because extensions are more likely to occur via soft-fork mechanisms. In such a case, old non-updated clients will still generate a correct view of the ledger state. But this is not so with client side validation! You assume that an ability to operate with zero maintenance is very important, but is this a case? There was a plenty of critical bugs in bitcoind, and in many cases people were strongly encouraged to upgrade to a new version. So, you urge people to keep their clients up-to-date, but at the same time claim that keeping very old versions is critically important. How does this make sense? Is this an exercise at double-think? An alternative to this is to make updates mandatory. You will no longer need to maintain compatibility with version 0.1 (which is impossible) and you can also evolve consensus rules over time. It looks like people make a cargo cult out of Bitcoin's emergent properties. -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=164703151iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] side-chains 2-way pegging (Re: is there a way to do bitcoin-staging?)
For those following this thread, we have now written a paper describing the side-chains, 2-way pegs and compact SPV proofs. (With additional authors Andrew Poelstra Andrew Miller). http://blockstream.com/sidechains.pdf Haven't seen any material discussion of this paper in this mailing list, so I'll start. (Otherwise, I've seen Peter Todd's reaction on reddit.) This paper fails to demonstrate that sidechains are anything more than a wishful thinking. It can be distilled down to this: We want such and such features, hence we'll use DMMS, the same thing Bitcoin uses, thus it will be secure! Um, no. Alt-coins also use DMMS, but aren't as secure as Bitcoin. So DMMS does not work by itself, it is a mechanism to secure a blockchain using economic incentives. The sidechains paper does not mention this, as far as I can tell. In my opinion, this is not acceptable. If you're making a proposal, you need to describe what conditions are required for it to work. Authors are clearly aware of the problem and mention it in section 6 Future directions 6.1. Hashpower attack resistance. The problem is they do not make it clear that the proposal just makes no sense until this is solved. In the discussions on reddit I've noticed that pretty much everybody believes that release of sidechains paper implies that the proposal is complete and now we are just waiting the implementation. It doesn't help that the paper itself tries to sweep the problem under the rug and has misleading statements. Particularly, I'm talking about section 4.2. Fraudulent transfers: Reorganisations of arbitrary depth are in principle possible, which could allow an attacker to completely transfer coins between sidechains before causing a reorganisation longer than the contest period on the sending chain to undo its half of the transfer. ... If the attacker is allowed to return the transferred coins to the original chain, he would increase the number of coins in his possession at the expense of other users of the sidechain. Before discussing how to handle this, we observe that this risk can be made arbitrarily small by simply increasing the contest period for transfers. Wow, really? Is this risk stochastic? The first sentence implies that attacker is able to cause a reorganization of an arbitrary depth, but the rest of the section implies that reorganizations are a naturally occurring phenomenon. All in all, I find this paper really disappointing. It's going to be influential (9 co-authors, many of which are regarded as Bitcoin core developers, must be good!) and hyped, and thus might focus research on an area which is fundamentally flawed. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] side-chains 2-way pegging (Re: is there a way to do bitcoin-staging?)
From the introduction [...]Because signers prove computational work, rather than proving secret knowledge as is typical for digital signatures, we refer to them as miners. To achieve stable consensus on the blockchain history, economic incentives are provided where miners are rewarded with fees and subsidies in the form of coins that are valuable only if the miners form a shared valid history, incentivising them to behave honestly.[...] This isn't applicable in case of sidechains: anybody with sufficient hashpower will be able to unlock a locked coin on the parent chain by producing an SPV proof. Only if the miners form a shared valid history isn't a requirement here, as miner will get bitcoins which aren't in any way connect to sidechain he have wrecked. Thus there is no incentive to behave honestly. Thus sidechains, in principle, reward their miners with the same Bitcoin will use in the future: only transaction fees. Since some people claim that won't be enough Whether it is enough depends on a variety of factors, including existence of other chains miner can mine. You cannot assume that it is the same situation as with a simple single-chain model. E.g. imagine 1000 BTC were moved to a sidechain. Miners can keep mining bitcoins as usual, and in parallel work on an SPV proof to claim these 1000 BTC. (I assume that merged-mining is allowed.) In this case the amount of fees which miners could collect by honest mining on the sidechain is irrelevant, as long as it is smaller than 1000 BTC. This is quite different from attacks which can be performed on vanilla Bitcoin (see below), so I don't think you can say that the security model is the same. Also says Given our assumption that p q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases. Yes, but that doesn't apply to reorganizations which attacker might cause intentionally. Hence I think it was disingenuous to include these two very different treats into one section: it sounds like you claim that attacker-induced reorganizations are unlikely, while it isn't the case. So the longer the contest period is, the harder it is to succeed with a fraudulent transfer. Yes, but harder isn't same as unlikely. Another problem with this section is that it only mentions reorganizations. But a fraudulent transfer can happen without a reorganization, as an attacker can produce an SPV proof which is totally fake. So this is not similar to double-spending, attacker doesn't need to own coins to perform an attack. I hope this clarifies our assumptions. Yep, thanks. It looks like you assume that sidechain security will be similar to Bitcoin security in the long term. Now quite the assumptions I've been looking for, but OK... I'm sorry for the harsh tone, but I just find it hilarious that people who explained that proof-of-stake is not going to work because an attacker might collect everybody's past signing keys to rewrite the whole history (I'm referring to this: https://download.wpsoftware.net/bitcoin/pos.pdf ) didn't bother to mention that miners can collude to wreck a sidechain and get an awesome reward, basically for free. something something the mote in thy brother's eye something something -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: death by halving
This thread is, in my opinion, a waste of time. It's yet again another perennial bikeshedding proposal brought up many times since at least 2011, suggesting random changes for non-existing(/not-yet-existing) issues. There is a lot more complexity to the system than the subsidy schedule. Well, the main question is what makes Bitcoin secure. It is secured by proofs of work which are produced by miners. Miners have economic incentives to play by the rules; in simple terms, that is more profitable than performing attacks. So the question is, why and when it works? It would be nice to know the boundaries, no? -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] death by halving
# Death by halving ## Summary If miner's income margin are less than 50% (which is a healthy situation when mining hardware is readily available), we might experience catastrophic loss of hashpower (and, more importantly, catastrophic loss of security) after reward halving. ## A simple model Let's define miner's income margin as `MIM = (R-C_e)/R`, where R is the total revenue miner receives over a period of time, and C_e is the cost of electricity spent on mining over the same period of time. (Note that for the sake of simplicity we do not take into account equipment costs, amortization and other costs mining might incur.) Also we will assume that transaction fees collected by miner are negligible as compared to the subsidy. Theorem 1. If for a certain miner MIM is less than 0.5 before subsidy halving and bitcoin and electricity prices stay the same, then mining is no longer profitable after the halving. Indeed, suppose the revenue after the halving is R' = R/2. MIM = (R-C_e)/R 0.5 R/2 C_e. R' = R/2 C_e. If revenue after halving R' doesn't cover electricity cost, a rational miner should stop mining, as it's cheaper to acquire bitcoins from the market. ~~~ Under these assumptions, if the majority of miners have MIM less than 0.5, Bitcoin is going to experience a significant loss of hashing power. But are these assumptions reasonable? We need a study a more complex model which takes into account changes in bitcoin price and difficulty changes over time. But, first, let's analyze significance of 'loss of hashpower'. ## Catastrophic loss of hashpower Bitcoin security model relies on assumption that a malicious actor cannot acquire more than 50% of network's current hashpower. E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Based Double Spending_ paper which shows that as long as the malicious actor controls only a small fraction of total hashpower, attacks have well-define costs. But if the attacker-controlled hashrate is higher than 50%, attacks become virtually costless, as the attacker receives double-spending revenue on top of his mining revenue, and his risk is close to zero. Note that the simple model described in the aforementioned paper doesn't take into account attack's effect on the bitcoin price and the price of the Bitcoin mining equipment. I hope that one day we'll see more elaborate attack models, but in the meantime, we'll have to resort to hand-waving. Consider a situation where almost all available hashpower is available for a lease to the highest bidder on the open market. In this case someone who owns sufficient capital could easily pull off an attack. But why is hashpower not available on the market? Quite likely equipment owners are aware of the fact that such an attack would make Bitcoin useless, and thus worthless, which would also make their equipment worthless. Thus they prefer to do mining for a known mining pools with good track record. (Although hashpower marketplaces exist: https://nicehash.com/ they aren't particularly popular.) Now let's consider a situation where mining bitcoins is no longer profitable and the majority of hashpower became dormant, i.e. miners turned off their equipment or went to mine something else. In this case equipment is already nearly worthless, so people might as well lease it to the highest bidder, thus enabling aforementioned attacks. Alternatively, the attacker might buy obsolete mining equipment from people who are no longer interested in mining. ## Taking into account the Bitcoin price This is largely trivial, and thus is left as an exercise for the reader. Let's just note that the Bitcoin subsidy halving is an event which is known to market participants in advance, and thus it shouldn't result in significant changes of the Bitcoin price, ## Changes in difficulty Different mining devices have different efficiency. After the reward halving mining on some of these devices becomes unprofitable, thus they will drop out, which will result in a drop of mining difficulty. We can greatly simplify calculations if we sum costs and rewards across all miners, thus calculating average MIM before the halving: `MIM = 1 - C_e/R`. Let's consider an equilibrium break-even situation where unprofitable mining devices were turned off, thus resulting in the change in electricity expenditures: `C_e' = r * C_e`. and average MIM after the halving `MIM' = 0`. In this case: r * C_e = R/2 C_e / R = 1/2r (1 - MIM) = 1/2r r = 1/(2*(1-MIM)) Let's evaluate this formulate for different before-halving MIM: 1. If `MIM = 0.5`, then `r = 1/(2*0.5) = 1`, that is, all miners can remain mining. 2. If `MIM = 0.25`, then `r = 1/(2*0.75) = 0.66`, the least efficient miners consuming 33% of total electricity costs will drop out. 3. If `MIM = 0.1`, then `r = 1/(2*0.9) = 0.55`, total electricity costs drop by 45%. We can note that for the before-halving MIM0, r is higher than 1/2, thus less than half of total hashpower will drop
Re: [Bitcoin-development] death by halving
For the sake of argument, lets assume that somehow (quite unlikely) Why is it unlikely? Do you believe that the cost of electricity cannot be higher than expected mining revenue? Or do you expect miners to keep mining when it costs them money? half the mining equipment gets shut off. The amount of hashes/second is such that it is currently, lets just say, quite secure against any takeover. The equipment won't be simply turned off, it will be up for grabs. Please check this web sites: https://nicehash.com/ https://www.multipool.us/ One can use them in the same way he uses normal mining pools, and they switch between different chains. Say, multipool.us can switch between BTC and PPC (Peercoin). Mining BTC will be less profitable after a halving, so a miner who is willing to maximize his profits might use multipool to auto-switch to something more profitable. Which might be attack-on-Bitcoin. E.g. if 60% of bitcoin's total hashrate is available via multipools, one can try to pull of a double-spending attack. Your document makes a long series of assumptions about how this can turn out bad with each individually is implausible, together are just fiction. It sounds like you failed to grasp even basics. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] The Bitcoin Freeze on Transaction Attack (FRONT)
I've heard about this idea from TierNolan. Here's some quick an dirty analysis: Suppose the last known block claimed a large tx fee of L. A miner who owns 1/N of the total hashrate needs to choose between two strategies: 1. Mine on top of that block and win usual reward R with probability 1/N. 2. Mine on top of the previous block, trying to make two blocks in a row, might get reward L with probability 1/N^2. Thus for the first strategy expected payoff is R/N, and for the second the expected pay-off is L/N^2. Second strategy is viable if R/N L/N^2, R L/N. Now suppose the miner who claimed the unusually large reward will share it with the next miner, for example, using coinbase output with OP_TRUE. If that shared reward Rs is higher than L/N^2, then the next miner will be better off mining on top of that block. This doesn't require protocol changes(*) and can be simply incorporated into a piece of code which decides what to do when a transaction with unusually large fee appears. (I.e. it will automatically share the fee, and others will recognize that). And if the biggest miner has 25% of all hashrate, sharing 25% of your loot doesn't sound that bad. (*) Except one problem: coinbase maturity rules won't allow one to share the fee with the next miner. So some protocol changes are required. But changes which affect coinbase maturity and sharing are probably going to be simpler and smaller than what Sergio have proposed. -- Slashdot TV. Videos for Nerds. Stuff that Matters. http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] deterministic transaction expiration
A distinction there is that they can only become invalid via a conflict— replaced by another transaction authored by the prior signers. If no other transaction could be created (e.g. you're a multisigner and won't sign it again) then there is no such risk. You need to check transaction's dependencies up to a certain depth to know whether it is safe: If one of inputs depends on transaction which is signed by parties with unknown trustworthiness, then it isn't safe. It now introduces chance events (act of god) into the mix where they they didn't exist before. You need to check transaction's dependencies up to a certain depth to know whether it is safe: If one of inputs depends on transaction time-locked script (or other unrecognized script), then it isn't safe. Situation is identical, you might need several extra lines of code. I think it would matter only if we had deterministic, reliable mempool and reorganization behavior. But it's not something we can depend on. -- Infragistics Professional Build stunning WinForms apps today! Reboot your WinForms applications with our WinForms controls. Build a bridge from your legacy apps to the future. http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proof-of-Stake branch?
I can't remember who I saw discussing this idea. Might have been Vitalik Buterin? Yes, he described it in an article a couple of months ago: http://blog.ethereum.org/2014/01/15/slasher-a-punitive-proof-of-stake-algorithm/ but it is an old idea. For example, I've mentioned punishment of this kind in discussion about PPCoin when it was released in 2012, and, I think, it was described in Etlase2's Decrit design. Also, I and Iddo did some research on pure proof-of-stake, and it seems to be feasible, in the sense that there are no obvious problems like nothing is actually at stake. (Unfortunately I can't refer to it now as it isn't published yet.) -- Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free. http://p.sf.net/sfu/SauceLabs___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP - Hash Locked Transaction
It is also useful for betting: an oracle will associate a hash with each possible outcome, and when outcome is know, it will reveal a corresponding preimage which will unlock the transaction. This approach has several advantages over approach with multi-sig script: 1. oracle doesn't need to be involved in each specific transaction 2. resolution is same for everyone who makes a bet on a specific event outcome 3. no need for two-way communication 4. no need for a special protocol: oracle might publish unlocking preimage on a web page, and participants will manually enter it into their clients -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
This is outright ridiculous. Zero-confirmation double-spending is a small problem, and possible solutions are known. (E.g. trusted third party + multi-sig addresses for small-value transactions.) On the other hand, protocol changes like described above might have game-theoretical implications which are non-trivial and hard to understand. The above approach works as long as the majority of hashpower is honest, defined to mean, working to stop double spending. This is the same security property as described in the white paper, thus this introduces no new security assumptions. No. Bitcoin should work if miners are merely individually rational, i.e. they try to maximize their pay-offs without colluding with others. I guess word honest might have different meanings, that can be a source of confusing. 1. Honest -- not trying to destroy bitcoin 2. Honest -- following rules which are not required by the protocol -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
And it still would. Non-collusive miners cast votes based on the outcome of their own attempts to double spend. Individually rational strategy is to vote for coinbase reallocation on every block. Yes, in that case nobody will get reward. It is similar to prisoner's dilemma: equilibrium has worst pay-off. In practice that would mean that simple game-theoretic models are no longer applicable, as they lead to absurd results. I'm using it in the same sense Satoshi used it. Honest miners work to prevent double spends. That's the entire justification for their existence. Miners that are deliberately trying to double spend are worse than useless. Miners work to get rewards. It absolutely doesn't matter whether they are deliberately trying to double-spend or not: they won't be able to double-spend without a collusion. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks
These sorts of proposals are all just ways of saying block chains kind of suck and we should go back to using trusted third parties. No. Different approaches have different trade-offs, and thus different areas of applicability. Proof-of-work's inherent disadvantage is that it takes some time until transaction becomes practically irreversible. On the other hand, it has advantages like neutrality, censorship-resistance, high degree of security, etc. TTP can be very efficient, but doesn't have advantages mentioned above. It is possible to combine several different approaches into one hybrid systems. For example, classic Bitcoin PoW blockchain can be used for settlements, large transactions, savings and so on. While TTP-based payment system will be used for small-value transaction like buying coffee. In this case you get benefits of both approaches. Censorship-resistance is irrelevant when one buys a cup of coffee with his pocket money, isn't it? For some reason, instead of considering these hybrid solutions (which can also address scalability problems), you want to make PoW-based system more complex to be applicable for real-time transaction too. This will, likely, weaken advantages provided by PoW, and also it won't provide any hard guarantees, and, if implemented, will undermine development of alternative solutions. -- Start Your Social Network Today - Download eXo Platform Build your Enterprise Intranet with eXo Platform Software Java Based Open Source Intranet - Social, Extensible, Cloud Ready Get Started Now And Turn Your Intranet Into A Collaboration Platform http://p.sf.net/sfu/ExoPlatform___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Feedback request: colored coins protocol
At this point, I don't think what you are doing is even colored coins anymore. You might want to look into Counterparty or Mastercoin. Nope, it's still colored coins. The difference between colored coin model and Mastercoin model is that colored coins are linked to transaction outputs, while Mastercoin has a notion of address balances. The implications of this is that in colored coin model explicit dependencies allow us to rely on SPV. (Assuming that one can fetch the dependency graph to link txout in question to genesis.) While it is not the case with Mastercoin. While it's pretty far from the original colored coins model, what Flavien have described is identical to it in majority of aspects. This is an interesting approach, but OP_RETURN size limitations can be a significant problem for some kinds of applications. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets
1) It's more private. Bloom filters gives away quite accurate statistical information about what coins you own to whom ever you happen to be connected too. An attacker can easily use this to deanonymize you even if you don't reuse addresses; Tor does not help much against this attack. There is also an option to download everything, but do only a very basic surface validation (without keeping track of UTXOs). You do not need a full node for that. -- Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
