Block size – In Blockchain, Mining, Bitcoin, 1Mb, 2Mb ...

Common misconception/myth that seems to be being pushed right now.

There is a common misconception/myth being pushed in the community right now that states something along the lines of; "Block reward is decreasing over time therefore individual transaction fees must increased to cover the missing block reward". This is incorrect and incomplete for two reasons. The first reason is that although the block reward is decreasing in bitcoin terms it has been increasing in real terms due to bitcoins increase in value in real terms. If bitcoin continues to succeed this will continue to be true for some time.
Even without that argument, there is a second argument that is relevant to BIP101. Bitcoin was originally designed so that the total transaction fees would increase over time and replace the block reward, not the individual transaction fees. Below I have outlined how this works with BIP101 in numbers.
Block Size TPS TP(Block) TP(Day) Fees per Block $.05 Fees per Day ($.05)
1MB 3 1800 259,200 $90.00 $12,960.00
8MB 24 14400 2,073,600 $720.00 $103,680.00
16MB 48 28800 4,147,200 $1,440.00 $207,360.00
32MB 96 57,600 8,294,400 $2,880.00 $414,720.00
64MB 192 115,200 16,588,800 $5,760.00 $829,440.00
128MB 384 230,400 33,177,600 $11,520.00 $1,658,880.00
256MB 768 460,800 66,355,200 $23,040.00 $3,317,760.00
512MB 1536 921,600 132,710,400 $46,080.00 $6,635,520.00
1024MB 3000 1,800,000 259,200,000 $90,000.00 $12,960,000.00
2048MB 6000 3,600,000 518,400,000 $180,000.00 $25,920,000.00
4096MB 12,000 7,200,000 1,036,800,000 $360,000.00 $51,840,000.00
8192MB 24,000 14,400,000 2,073,600,000 $720,000.00 $103,680,000.00
For comparison, even with the 25btc block reward that is current given to miners each block, this is only roughly $10,000 per block. What this shows is that within about 7-8 years (roughly the age of bitcoin right now) we can have the same amount of money pouring into miner's pockets through transaction fees alone with only an average $0.05 fee per transaction. That's without any efficiency improvements to the network to fit more transactions in per Megabyte. I don't think free transaction should last any longer as they have been subsidised for 7 years now and we are now in a very strong position without them. But it is is important that we keep the utility of bitcoin as peer to peer payment system as it was designed.
submitted by singularity87 to Bitcoin [link] [comments]

21% attack possible against BIP100?

If I interpret BIP100 correctly, the top and bottom 20% of votes are discarded, and the minimum is chosen.
Doesn't this mean that a miner with 21% of the hashing power can drop the block size to the minimum that can be specified by the votes, i.e. 1B? If the block size is calculated on entire blocks, wouldn't this permanently destroy Bitcoin unless recovered with a hard fork?
Now, of course, one could argue that a miner would not want to do that since it would destroy the value of his mining equipment, but I think that's a weak argument. A year worth of Bitcoin mining is worth
25 BTC/block * 6 blocks/h * 24*365 h/year * 230 USD/BTC 
which is roughly $300 million. eBay bought PayPal for five times this amount in 2002, so this is not an unrealistically large amount of money. If you can't amortize your equipment over more than a year, the price of mining will surely be higher than that, but not that much higher, I suspect (since miners do become obsolete quite fast anyways) - and besides that, the mining still pays for itself, at least before the attack becomes obvious, if you sell the coins immediately.
Assuming a block size limit of 1 MB, and a voting cycle of 3 months (the BIP doesn't seem to specify it, but it can be implied from the initial voting cycle), 1 year of mining would "only" allow you to drop the block size four times, e.g. from 1 MB to 500 KB, 250 KB, 125 KB, and finally 62.5 KB. That wouldn't irreversibly destroy Bitcoin on a technical level, but probably make it unaffordable to transact on it and destroy it on an economic level.
Did I miss something, or should we consider some changes to BIP100 to prevent this (e.g. using the median instead of the 20th percentile)?
Note: I'm in support of a block size increase, be it through BIP100, BIP101, or otherwise. My aim is to help fix an issue if one exists, understand why if it isn't an issue, but not to delay or prevent the implementation of one of these BIPs.
Edit: Possible solution here - a majority of miners can always declare a certain size unacceptable and start treating all blocks that vote beyond the arbitrarily chosen limits as invalid (soft fork).
submitted by aaaaaaaarrrrrgh to Bitcoin [link] [comments]

The Bitcoin community is talking. Why isn't Core/Blockstream listening? "Yes, [SegWit] increases the blocksize but BU wants a *literal* blocksize increase." ~ u/lurker_derp ... "It's pretty clear that they [BU-ers] want *Bitcoin*, not a BTC fork, to have a bigger blocksize." ~ u/WellSpentTime
I've been telling them to go and create their fork for over a year now.
They just want to disrupt Bitcoin, create FUD, and slow technical progress while then invest in competing systems.
~ u/nullc Greg Maxwell - Bitcoin ExpertTM
It seems like half the posts on btc is just about you [u/nullc]. This is barely even about SegWit anymore. A lot has reached the conclusion that Core is bad for Bitcoin and are looking at any argument that will support that conclusion, even if it means blocking the same thing they were asking for.
~ u/GanjaFarmer23
I'm not on either side in this debate, but your argument is the same as saying "Why don't core just fork btc so they can have segwit adopted?"
It's pretty clear that they want bitcoin, not a btc fork, to have a bigger blocksize.
Also, isn't this exactly the point of signaling, that different entities can have different opinions like in a democracy? It's not hard to understand why you guys are not getting along considering the line of argument you are displayed here, which implies: "If you don't agree with core, create your own fork. We are going to do what we want with bitcoin regardless of what you think".
This type of reasoning displays an arrogance and clearly implies that for core, reaching a consensus is just a necessary inconvenience that you'd rather be without. In contrast to a true democracy, where all opinions are respected. Surely, a democratic government wouldn't ask citizens with a different political opinion to move to a different country.
~ u/WellSpentTime
Regardless of whether or not core wants bitcoin to be a democracy, you are stuck with democracy-like features, and therefore forced to cater to the majority. It has been clear that core is not taking the strategy of accepting and working together with entities that have different opinions during the scaling debate and implementation of segwit. When you completely reject the idea of a democracy, even when used in the context of being accepting of different opinions, there cannot be much hope of even an attempt of reconciliation. It is then to be expected that all your proposals are fought tooth and nail by everyone with different opinions.
On a more personal note, I think it's sad to see that core is so adamantly refusing any compromise, even in their rhetoric, toward uniting the community and finding common ground for progress and scaling. I hope you are successful in implementing segwit, but I'm saddened by the divide and conflict in the community that your strategy and unyielding rhetoric has caused.
I hope that you in the future will consider changing your strategy and working toward amending the rifts in the community. Personally I think you will find that progress will come much easier.
~ u/WellSpentTime
I know a few people supporting BU and can attest that their motives are genuine. In fact they assume you want to keep blocks smalls either because blockstream would make money out of it (for the less intelligent ones) or because they think you are out of touch engineers engineering for the sake of engineering and that you lost or can't comprehend the big picture (for the smarter ones, not saying they are right, I'm personally undecided on the matter).
~ u/Taidiji
The reason they haven't hardforked yet is because they are trying to achieve overwhelming support so their Bitcoin fork can quickly dominate the current Bitcoin. Nobody wants to lose money. They don't FUD bitcoin, they fud Bitcoin core (To raise support for alternatives)
~ u/Taidiji
You [u/nullc] obviously don't understand BU. The whole point is that when they do fork, it will be precisely because the network is ready to make it bitcoin. Not a moment before.
~ u/_Mr_E
They [BU supporters] don't want to just disrupt bitcoin. That is such a stupid thing to say. This is why I don't trust segwit because people are lying too much.
~ u/elfof4sky
It [BU] does fork the network when there's support.
~ u/tcrypt
/bitcoin mods had a large part in forcing both sides into their respective echo chambers. I don't know if things are too far gone for consensus now, but the original issue that split the community has never been addressed or acknowledged.
~ u/Rxef3RxeX92QCNZ
Well ... hold on. I've been bouncing back and forth between /btc and /Bitcoin for a little bit now, and I'll try to draw some analogies but might go down a rabbit hole or two. Read it, and let me know your thoughts:
1) Yes, this increases the blocksize but BU wants a literal blocksize increase. They want on-chain transactions, not off-chain potential transactions in the future. They don't want extra code to perform this blocksize increase just the simple code that switches the 1MB to XMB. There's a lot more to their arguments but really I don't want to delve into that.
2) I think there might be a general fear about some ulterior motive by blockstream which maybe isn't obvious to everyone else, whether it's suffocating bitcoin or some other money making plans
In my mind either Segwit happens and we're open to a shit ton of other awesome possibilities that takes us to the next level, or, /btc was right and Segwit happens and next thing we know our txs are being siphoned off to blockstream & their cronies. Worst case scenario, like I said before, everyone switches off the Core software and moves to BU, problem solved - unless of course I'm missing something I'm not thinking about that might actually jail your coins to core and not allow you to move off that everyone in both of these subs are missing.
~ u/lurker_derp
Some oppose segwit for other reasons. These reasons are being repeated over and over since sipas presentation, but you don't want to hear that. And then you deduct from that they don't want a blocksize limit increase and must have malicious intent? That's some sick logic.
~ u/moleccc
it [SegWit] is a short term gain and a long term reduction. In the short term segwit will allow more transactions, but long term it is a reduction because of the asymmetric nature of how it allows 4X as many transactions in certain scenarios but 2X as many in typical usage. That means that any block increase in the future will suffer from attack vectors greater than the actual increase whereas a simple block size increase wouldn't.
~ u/specialenmity
You realize that SegWit doesn't actually increase the block size right? Using some tricky math you can come up with a sequence of transactions that almost hits 1.8 megs if you were to do it in non-SegWit transactions, but it has yet to be seen how much it will improve real world transaction data. The blocks are still going to be a megabyte.
I'm all for activating it, but it required massive code changes, and likely won't be as effective as a one line fix would have been.
~ u/px403
They just want to disrupt Bitcoin, create FUD, and slow technical progress while then invest in competing systems. ~ u/nullc
It's worrying that after all these discussions you still do not understand the position of Gavin and Myke. They simply followed their interpretation of Satoshi's vision for Bitcoin.
~ u/Hermel
They just want to disrupt Bitcoin, create FUD, and slow technical progress while then invest in competing systems. ~ u/nullc
it's funny how each side in this (fabricated?) conflict say the exact same thing about the other side.
~ u/moleccc
Why are you [u/nullc] so heavily against a small blocklimit increase?
You have said it yourself that 2mb, 4 or 8mb blocks aren’t going to hurt Bitcoin...
~ u/-Hayo-
Why are you [u/nullc] so heavily against a small blocklimit increase? ~ u/-Hayo-
I'm not-- segwit increases that size of blocks to about 2MB and I support that!
~ u/nullc
Isn't the block size still 1MB and the extra data gets added to the "block weight"? If so, why do you keep repeating this bullshit statement?
~ u/viners
This is the source of the rift in the community. No one believes core will actually increase the blocksize. Moreover, most were expecting SegWit as a HF with the 2x blocksize increase, not shell games creating more block space for SegWit data, giving that data a 75% discount vs. other transaction space (without any discussion with the broader community), and calling that a blocksize increase. We already had trust issues, making the paper napkin sketch of blockstream come true with this 75% discount isn't helping!
Core should fully commit to a 2MB HF next. Not MAST, not other crap, a straightforward, no tricks, blocksize increase. That would be the best next step for everyone involved. Better yet, scaling that automatically just happens, similar to BIP101.
~ u/permissionmyledger
It looks like a compromise is the only way out of this civil war. Segwit or the HF will both never happen on their own without a compromise. So doing both segwit and raising the blocksize limit at the same time, seems inevitable at some point. Hopefully sooner than later. But probably later.
~ u/bitfuzz
I'm starting to believe the conflict isn't over how to scale, but the when we scale.
More specifically, to scale before or after we allow a fee market to develop.
Sure a fee market always existed, but it had no real pressure, until we let blocks fill up recently in this massive and arguably risky experiment.
Core's plan was to wait forever to scale and that seems to be the main stress factor for many. SegWit takes forever to get developed, tested, activated, and actually start helping the block size. I get it, half of that is done, but it wasn't yet when people wanted an immediate fix. Other fixes on the road map for scaling are super far off and questionable.
People weren't pushing for large blocks so hard because they thought it would work better than SegWit, they were pushing for large blocks because it could be done quickly, before fee market pressure started.
Once profit driven miners get a taste of that pressured fee market, it will be hard to let go. If the pressure has raised the fee too much, when the scaling issue is fixed, the fees will fall and cut the legs out from underneath the profit driven miners. We may lose hash rate.
Fees were to prevent spamming, they were never intended to supplement mining rewards until the mining reward schedule ran out and the currently meager fees are worth something more considerable.
An experiment in creating fee market pressures is arguably experimenting with breaking the ~15 year mining reward plan and thus its quite elegant plan to slowly bring scarcity up, and with it the value, to ensure that when the mining reward schedule is complete, the value is high enough to sustain Bitcoin's security while only paying miners fees.
~ u/SoCo_cpp
Screw promises.
Bundle the change [bigger blocks] they [BU supporters] want with segwit, then it will activate.
That's how it works: give, not promise.
~ u/moleccc
I would prefer a small blocklimit increase combined with Segregated Witness. It would also be a great political move.
~ u/-Hayo-
submitted by ydtm to btc [link] [comments]

Attacking Bitcoin in the UK: Offences under the Computer Misuse Act 1990

The Computer Misuse Act 1990 in the United Kingdom makes it an offence to deliberately cause disruption to computer systems with intent
The recent and planned "stress test" attacks by not only cause disruption, they cause nodes to crash and make services unavailable.
I would caution CoinWallet.EU against their "stress tests" are at risk of breaching UK law and probably cyber crime laws elsewhere. Any individual or business affected may contact the police and the evidence of the attacks is burned into the blockchain forever and various publications who have covered the story with direct contact from representatives.
It seems there is a bit of confusion, so I'll cover some of the concept here.
There is a concept in most legal jurisdictions that abuse or unauthorised use of computer systems/networks is an offence. In the case of abuse, if one intends to cause disruption and then attempts to do so, then an offence has been committed. Whether a computer system is vulnerable to attack is not the point and is not a defence.
Penetration testing is illegal without explicit permission from the owner of the computer system in question. Many people have conflated the Bitcoin network with nodes. If an attacker executes a denial of service it affects bitcoin nodes. There are two specific examples: DOS attacks against nodes, as it happening with XT, and the transaction attacks that have been executed by
In both examples the DOS attacks have a negative impact on the computer running the full node, as well as the functionality of the full node. The XT attacks consume bandwidth and the transaction attacks fill node mempools and cause nodes to crash.
This post is not about political values, it's about the law, as it stands. The attacks on XT nodes and the "stress tests" are illegal actions and those performing them should think twice. Of course getting caught is a different matter, certainly the XT attackers have not come out publicly, so hunting them down may pose a challenge. Coinwallet on the other hand has made no attempt to hide their intentions and I assume there is a trail leading right back to them. As a matter of law, I urge attackers to cease operations.
I'm quite shocked that some of the reddit community would condone these illegal actions or chose to politicise the matter.
I know I am not alone in my feelings and I would like to thank mike_hearn for actually bringing up the matter of the legality of attacks a few days ago on the XT mailing list. Unfortunately for him, the attackers of XT nodes are pretty well hidden. While I do not remotely support XT, or BIP101 (I'm quite vocal against them), I absolutely do not condone the illegal actions, however so motivated. I think there are better ways to let the Bitcoin ecosystem decide it's future. In any case, this post it not about XT or the blocksize debate, but about the illegality of the recent and planned attacks.
Further clarification of the law in the UK can be found here under "Section 3 CMA - Unauthorised Acts with Intent to Impair"
submitted by btcdrak to Bitcoin [link] [comments]

Could we please make a stronger attempt to bridge this divide in the community and get more insight into the thought processes of the Core Developers?

I'm making this post in what may be a futile attempt to bridge this ever widening gap in the Bitcoin community. This is mostly going to be from the perspective of a small-time investor, not a technical guy at all. I may not be the most qualified person to make this post, but I'd like to see more posts like this so that it may be possible for us to move past this current quagmire as a more unified community. I'm posting in this subreddit even under the fear that it may get removed because I want this to be seen by more than just the people that have been pushed out of this community.
Having said that, I think the first thing that we should acknowledge is that an extremely significant portion of the Bitcoin community HATE the core developers. I know that many don't care that this happens to be true, but this really should be cause for alarm. I'll spend most of this post addressing the reasons I think this is the case, then perhaps in the comments others can chime in, and we can hear from the Core developers as well.
I'd like to see more polls done within the community so that we can find a better sense of the thoughts of everybody. I'm not sure where the majority of support lies but I think we need to make a better effort to address the concerns of everybody, so that we can move forward as one, stronger unit. Every one of us have invested into Bitcoin in some way, and collectively, we are what make Bitcoin worth $414 dollars. If a significant portion of us get fed up and leave, we can expect price drop, which is bad for everybody. (Unless of course you have decided to short Bitcoin.) But the people that leave are probably not going to leave Crypto altogether. Personally, I've started putting more and more of my money into alt-coins that seem better equipped to fulfill the potential which Bitcoin may not be able to with the current development team. If enough of us decide that, it's possible that another coin could take over.
While this is unlikely, I think it's undeniably true that many have liquidated their Bitcoin holdings because this loss of faith in developers, and I think there are far more people that would like to invest, but think that Bitcoin is too risky with its current development team.
To that end, let's restore confidence in the current team by delving into their thought processes. I think everything unfortunately comes back to the blocksize debate. It's exhausting, but it needs to come to a conclusion if we want more people to invest in Bitcoin. And I think we all want as many people to invest in Bitcoin as possible.
  1. Core Developers don't seem to have any urgency to get this block size thing resolved. I think most people see this as the number one problem with bitcoin right now, and would like to see is all effort being put into a permanent solution before we see the developers work on less critical things. A lot of talk has been thrown around about a temporary, small increase to buy more time, but many want this blocksize issue to be in Bitcoin's rear-view mirror. The reason being that as long as this uncertainty exists, there are a lot of investors that simply won't get into bitcoin, and to foster the network effect, we need to get as many people in as soon as possible. We have a halving coming up shortly, which brings with it a potential price increase, and I for one would like to see how much it can go up if we don't have this blocksize cloud hanging over investors. So the question for Core Developers is, how much do you feel the same? How committed are you to putting out a permanent solution as quickly as is safe?(This, by the way, is why BIP101 is so appealing to so many people. It may not be the best solution, but it is A solution. One that has been tested, and can resolve this debate once and for all.)
  2. The Core Developers don't seem to be willing to compromise much. It's great that we had those scaling Bitcoin conferences, but what did we get out of them? When the major exchanges came out this summer in support of BIP101, the Core developers quickly issued a letter saying that they've heard our concerns, and asked us to wait until the Scaling Bitcoin conferences were over. Many were hoping for a clear path forward and a clear alternative to BIP101 upon the conclusion of the second one, but the second one has concluded and we do not have that. We have a lot of promising ideas, but nothing that would be an alternative to BIP101. (That is, something that would conclude this block size debate once and for all.) We don't even have a timeline or a plan for one. It seems to me that a golden opportunity was missed to compromise on BIP101. I didn't see anything come out of the conference that would last us more than a couple of years. BIP101 supporters want a clear path forward and they still do not have that from Core. So the questions is, how willing are you to compromise with the people that want BIP101? Would you be willing to compromise on a version of BIP101 that started at 4MB, or doubled slower?
  3. The Core developers aren't very good at communicating with their detractors. I think this is in part because they have little interest in communicating with people that don't understand the technical side of things. There is a sense that they see themselves above everybody else, and that they do not answer to the people that give their project value. Contrast this with the simple, thorough, and easy-to-understand, blog posts of Gavin and Mike. Gavin made a series of blog posts addressing every single one of Core developers concerns about raising the block size. As a casual investor, I really get the sense that he knows what he's talking about, and I trust him to lead us forward. The core developers didn't really do an adequate job explaining to us why that trust would be misplaced, and didn't adequately address his points about raising the block size. So the question is, will Core Developers make a better effort to communicate with us, and make us feel that our concerns are being heard? (This would of course include publicly denouncing the censorship which runs through some of the main Bitcoin channels, instead of pretending like it doesn't exist, or that it's not a problem.)
  4. It feels like core developers have framed the argument about raising the block size in a bad way. They have presented this as a matter of centralization vs. decentralization. Could you help us better understand why supporting BIP101 is necessarily synonymous with centralization, and why that would be a bad thing. It seems to me that the biggest concern is that if the block size gets too high, then it will be too cost prohibitive for an individual to run a full node, and it may lead to transactions not being broadcast because those transactions go against the interests of the small number of node operators that can afford to run them. (If I understand the argument correctly.) However, I'm not really too concerned about it. It seems that no matter how big Bitcoin gets, there will always be a significant number of early adopters that care about Bitcoin's decentralization, and will be able to afford to run a full node. This makes some sense, right? If we're maxing out 8GB blocks, it's difficult to imagine that bitcoin is going to continue to be worth $414 dollars. Most likely they will be worth tens of thousands of dollars, and given how much more affordable memory, disc space, and bandwidth are each and every year, I have a really hard time imagining a scenario where a full node would be so costly to operate that they there wouldn't still be plenty that are are willing to broadcast any valid transaction. So where am I wrong here? Why should I be more concerned about this than I am? (Also, when it comes to centralization, why is it okay for the future of Bitcoin to rely on Blockstream's ability to put out a functional Lightning network? If we had to rely on such a network to continue to make transactions affordably, wouldn't that be centralization as well?)
  5. It feels like the core developers are abandoning some of the potential that Bitcoin has to offer. When I was first looking into Bitcoin, I was told about all the potential the the blockchain could offer. This is one of the reasons I invested. We could use bitcoin for normal peer-to-peer financial transactions, but also micropayments, smart contracts, remittances, a distributed public ledger, colored coins, etc. It seems like if we want our currency to have the most possible value, shouldn't we try to do everything in our power to maximizes it's potential uses? Shouldn't we be inviting people to use our blockchain to use as they please instead of pushing them toward private blockchains? Do we still want Bitcoin to remain peer-to-peer? There seems to be a debate over whether Bitcoin should be merely a settlement layer. Can't it be both? Wouldn't it be more useful as both? Wouldn't that drive more people to invest?
This is getting long, and I know this isn't an exhaustive list of complaints, but I think it hits at the biggest ones. I also realize I may be showing my ignorance here as well, so please do correct any misunderstandings. I have a significant portion of my total wealth tied up in this currency, and I would like to be reassured that this remains a good investment with Core developers in charge. I believe that they do want what's best for Bitcoin, but their words and actions have been confusing, and fostering a greater divide in the community. It certainly feels like they aren't too concerned about Bitcoin as an investment for a lot of people, and I'd like to see that changed. Thank you for reading all this, and thank you for your thoughts and opinions. Lets keep this friendly, even if it ends up getting sorted by most controversial.
submitted by hotdogsafari to Bitcoin [link] [comments]

Compromise: start BIP101 at 4MB and agree to merge segregated witness ASAP.

Segregated witness (SW) can work relatively quickly. Removing signatures from the blockchain is an easy way to cut 60% of its size.
SW isn't a solution right now, but there is far less in the way of SW working than lightning or sidechains. I see SW as a practical and quickly implementable solution for scaling that doesn't appear to modify the properties of the network in a meaningful way, or have any unanswered security or centralization concerns. It's simple and effective, a real "no brainier". Really great work.
So... knowing this, what if we cut BIP101 to start at 4MB, but merge segregated witness asap?
This makes China's mining community happy for years and years, but allows bitcoin to scale, and we still get a 60% efficiency in the near future. This allows the bitcoin network effect to kick back in, the price to rise, and we all win.
Too simple? Maybe rename BIP101 to something else for political neutrality with the lower starting value and sing kumbaya? Thoughts?
submitted by MrMadden to btc [link] [comments]

On decentralization: Why I think increased blocksize will aid decentralization, even if it increases network burden.

Posted this a long, long time ago when BitcoinXT was leading the fight, and BIP101 was a thing. Figure I'd post here so people are better informed whenever they encounter cries of "but what about muh decentralization? Big blocks bad!".
There are several aspects of Bitcoin that need "decentralization", and I think growth will actually improve them, not harm.
Looking narrowly: If we only look at one aspect - network decentralization - under a narrow assumption: That adoption remains exactly the same as today, the amount of stakeholders and commerce remains frozen, then indeed bigger (filled) blocks will lead to a worse centralization. That I can see, and is what your guys have been warning all along.
However, in reality adoption is not staying static, number of stakeholders and amount of commerce is not staying static, and are all in fact heavily affected by expectations resulting from the blocksize limit. Decentralization of the following, as I see it, has the potential to be improved by increased adoption that's made possible by higher tps:
In short, I don't think we should trade a path to much greater resilience (as described above), that's only possible with greater adoption made possible by increasing blocksize, for a short-term, narrowly-defined network "decentralization" that will not even be relevant if other aspects above are compromised. That, and it's highly doubtful that 8MB/16MB blocks are even gonna hurt network decentralization that much in the short term. (Edit: now proven correct via Bitcoin Cash) My two cents.
submitted by imaginary_username to btc [link] [comments]

BIP101 is the best scaling proposal for Lightning Network.

Forced expiration of many transactions may be the greatest systemic risk when using the Lightning Network. If a malicious participant creates many channels and forces them all to expire at once, these may overwhelm block data capacity, forcing expiration and broadcast to the blockchain. The result would be a mass spam on the bitcoin network. The spam may delay transactions to the point where *other locktimed transactions become valid. *
This may be mitigated by permitting one transaction replacement on all pending transactions. Anti-spam can be used by permitting one transaction replacement of a higher sequence number by an opposite of an even or odd number. E.g. if an odd sequence number was broadcasted, permit a replacement to a higher even number only once. Transactions would use the sequence number in an orderly way to replace other transactions. This mitigates the risk assuming honest miners. There may be some further consensus mining optimizations, as well. This attack is extremely high risk, as incorrect broadcast of Commitment Transactions entail a full penalty of all funds in the channel.
Additionally, one may attempt to steal HTLC transactions by forcing a timeout transaction to go through when it should not. This can be easily mitigated by having each transfer inside the channel be lower than the total transaction fees used. Since transactions are extremely cheap and do not hit the blockchain with cooperative channel counterparties, large transfers of value can be split into many small transfers. This attempt can only work if the blocks are completely full for a long time. While it is possible to mitigate it using a longer HTLC timeout duration, a better method is to use a blocksize soft-cap.
If this type of transaction becomes the dominant form of transactions which are included on the blockchain, it may become necessary to increase the block size and run a soft-cap
[...] If all Bitcoin transactions were conducted inside a network of micropayment channels, to enable 7 billion people to make two channels per year with unlimited transactions inside the channel, it would require 133 MB blocks (presuming 500 bytes per transaction and 52560 blocks per year). Current generation desktop computers will be able to run a full node with old blocks pruned out on 2TB of storage.
Lightning network white paper
It seems clear that BIP101 look like the best scaling proposal for lightning network.
A LN worldwide use would produce 133MB block and as explain in chapter 6.2. Ligtning Network is less secure on saturated blocks.
LN will therefore need a much bigger block limit than 133MB to prevent forced expiration SPAM attack. Only BIP101 is offering block size big enough for worldwide use of LN in the long term.
The BIP101 higher block limit will also be useful to operate "soft cap" the SPAM attack protection proposed in the LN white paper.
All decentralised scaling proposal require much bigger block (over the long term).
PS: This also show that creating an artificial fees market (by block space scarcity) can make LN much more expose to attack.
Edit: typos, format, clarity
submitted by Ant-n to btc [link] [comments]

Watch out: the issue is not Core vs. XT, it is small blocks vs bigger blocks.

People should keep in mind that the "block size issue" is strictly technical, "small blocks versus bigger blocks". It should not be conflated with the political issue "Core vs XT" or "Blockstream vs Gavin and Mike".
How the fork will develop depends on one parameter only: how many miners will be accepting big blocks at some time in the future. It does not matter much which version each miner is running. The preferences of the "economic majority" may influence the decision of the miners, but once a substantial majority of the miners has decided to accept big blocks, the "economic majority" is forced to accept them too.
I will consider first the case of just two block sizes "small" and "big". (For today's dilemma, "small" would be to 1 MB, and "big" woule be anything more than 1 MB but not more than 8 MB. But other sizes may apply in other occasions.) Later I will comment what happens when there are three or more values of the block size limit "competing" at the same time (e.g. 1 MB, 2 MB, and 8 MB; or a fixed limit against a dynamically adjusted limit).
The fork
The chain will (theoretically) split once the first big block B(N) gets mined. There will be a "big-block" branch that grows on top of that block, containg perhaps other big blocks; and a "small-block" branch that starts with an alternative small block C(N) with the same block number and contains only small blocks.
If, at that moment, more than 50% of the miners are accepting big blocks, the big-block branch (mined by them) will eventually grow faster than the small-block branch (mined by the rest of the miners). Apart from some unlucky initial accidents, the split will be persitent and the big-block branch will grow faster.
On the other hand, if, at that moment, less than 50% of the miners are accepting big blocks, the small-block branch will eventually grow longer. Then the big-block miners will stop mining their branch, which will be orphaned, and they will start mining the small-block branch too. If someone mines another big block, the chain will split again. This "stuttering" situation will repeat over and over, every time some miner happens to mine a big block. There will be a single small-block chain with recurrent big-block side branches that are orphaned sooner or later.
Sharp and messy forks
Ideally, whenever a big block is actually solved and posted, either almost all miners (counted by hashpower) should be accepting big blocks, or almost all miners should be rejecting them.
If, at some point, 75% of the miners suddenly start accepting big blocks, the other 25% had better start accepting them too. Ditto if, after every miner is accepting big blocks, 75% suddenly decide to start rejecting them.
More generally: if the miners are mostly in agreement about accepting or rejecting big blocks, but a majority changes their mind, in either direction, they had better all change together, before someone posts another big block.
As long as all miners are mostly in agreement, it is safer for all clients to accept big blocks than to reject them.
If the miners ever get into a messy state, with significant percentages of both big-block acceptors and big-block rejectors, all clients had better stop using bitcoin until the mess gets cleared up, and almost all miners have again converged to the same policy.
How miners should get consensus
Miners should not rely on the block version stamps to figure whether other miners are accepting or rejecting big blocks. Those tags may be mistaken, ambiguous, or misunderstood. Moreover, there may be idiots or malicious miners lying about their intentions through the tags.
Instead, the largest miners should talk to each other and make sure that at least 70% of the total hashpower is really commited to accept big blocks, or 70% is committed to reject them. Then those miners should announce publicly their intention to change (or not) their big-block policy at some block number. The rest shoulfd then follow, by self-interest.
Multiple block size limits
If there are m ≥ 3 distinct values S(1) < S(2) < ... < S(m) of block size limit competing for adoption (e.g. 1 MB, 2 MB, and 8 MB), and miners are divided between them, the analysis is not much more complicated. There will be m branches in general, each branch Ch(i) associated to a given candidate limit S(i). The branch Ch(i) will contain blocks with sizes up to S(i), and at least one block with size greater than S(i-1). Miners who accept blocks of size up to S(i) will mine the longest of the branches Ch(1), Ch(2), ..., Ch(i). Depending on how the miners are distributed, some branches will be repeatedly orphaned and restarted, others will grow at different paces. If Ch(i) is the fastest-growing branch, it is hoped that all miners will quickly change their size limits to S(i).
So, Core or XT?
As observed above, it does not matter which version each miner is running -- Core, XT, or something else. (In fact, that information cannot be determined by analyzing the miner's behavior. Note that any version can be patched to insert any version stamp on the block.) It does not even matter what precise formula each miner is using to determine the maximum block size (BIP100, BIP101, or any ad-hoc rules) and whether it is fixed or will increase in some distant future.
A software that rejects big blocks can be the current Core version, or XT minus the 8 MB patch, or any other independent code with a 1 MB block size limit. A software that accepts big blocks may be the current XT (with or without the other patches), or the current Core with an 8 MB patch (by repentant Blockstream devs, or by someone else), or any other version that accepts 8 MB blocks.
In fact, any client or node could take the Core implementation, change the line "MAX_BLOCK_SIZE = 1000000" to say "MAX_BLOCK_SIZE = 8000000", and start running that version now. There will not be a significant risk in that, unless the chain splits is a messy way; but then the most prudent attitude for a client is to stop using bitcoin until the splits resolves with the death of one chain.
Even a miner could do that, as long as he avoids creating big blocks until it is "safe" to do so, and promptly reverts to the smaller limit in a messy split dominated by small blocks.
That is the main point: the "Core vs XT" and "Blockstream vs Hearn&Gavin" issues are red herrings. Again, the only thing that really matters is how many miners will be accepting big blocks at some point in the future.
submitted by jstolfi to bitcoinxt [link] [comments]

Why are miners supporting a development team who is actually working against their interests?

The core dev's plan, which they have purposely obfuscated, is to turn bitcoin into a high cost, low speed settlement network, with highly layer protocols on top for handling other functionality.
This is logically impossible though.
Lets say it costs $5 to get a transaction published to the blockchain.
The above scenario is true for any non-neligible transaction cost. What it shows is that, instead of bitcoin becoming a high cost, low speed settlement network where everyone transacts on layers above, transactions will simply overflow into non-bitcoin payment networks. As other cryptocurrencies gain more users the network will become more and more fragmented, lowering their combined value proposition due to a weaker security model. This will be reflected in the price and the number of transactions that happen via cryptocurrencies. This ultimately means miners (and everyone in the cryptocurrency industry) will make less money (although obviously, in the short term altcoins will benefit, which pretty obviously why certain people support core).
Miners supporting a development team who is actually working against their interests and I feel the community needs to make this very clear to them. It seems right now that miners are being intellectually lazy by simply deferring to blockstream core rather than assessing how blockstream core's plan will affect their income.
Scaling bitcoin via BIP101 or Bitcoin Unlimited will allow miners to earn income from transaction fees that will dwarf their current income via the block reward subsidy. By the time we get to 8GB blocks, with only an average transaction fee of $0.05, miners will be earning $120,960,000 per day and $44 billion per year in transaction fees alone. $44 billion per year is currently what miners are saying no to. We need to change that.
Edit: I should add that to compete with a directly scaled bitcoin, the transactions fees of a settlement layer bitcoin would need to be in the hundreds to make miners the same amount of money. The larger the miner fee the weaker the security model of LN and the lower utility of bitcoin.
submitted by singularity87 to btc [link] [comments]

BIP99½ - An Optimized Procedure to Increase the Block Size Limit

BIP: 99½
Title: An Optimized Procedure to Increase the Block Size Limit
Author: Jorge Stolfi jstolfi
Status: Crufty Draft
Created: 2015-08-30
EDIT: Changed the critical block number from 385000 to 390000 (~2016-01-02).
EDIT2: Slight wording changes ("hopefully" "assuming" as per tsontar).
EDIT3: Changed again critical block number to 395000 (~2016-02-06). Note that the traffic has increased faster than expected, so all predictions would have to be updated.
This BIP proposes setting the maximum block size to 8 MB starting with block number 395000.
This proposal aims to postpone by a few years the imminent congestion of the Bitcoin network, which is expected to occur in 2016 if traffic continues to increase at the present rate. It also aims to reduce the risk of a crippling "spam attack", that could delay a large fraction of the legitimate traffic for hours or days at a relatively modest cost for the attacker.
The current average traffic T is ~120'000 transactions issued by all clients, per day (~1.38 tx/s, ~0.45 MB/block, ~830 tx/block assuming ~530 bytes/tx).
The maximum network capacity C with 1 MB blocks, revealed by the recent "stress tests", is ~200'000 tx/day (~2.32 tx/s, ~0.75 MB/block, ~1390 tx/block). Presumably, the main reason why it is less than 1 MB/block is because certain shortcuts taken by miners often force them to mine empty blocks. Note that the traffic now is 60% of the effective capacity.
Since the traffic rate has weekly, daily, and random fluctuations by several tens of percent, recurrent "traffic jams" (when T is higher than C for several tens of minutes) will start to occur when the average daily traffic is still well below the capacity -- say 80% (160'000 tx/day) or even less. For transactions issued during a traffic jam, the average wait time for first confirmation, which is normally 10-15 minutes, will jump to hours or even days. Fee adjustments may change the order in which individual transactions are confirmed, but the average delay will not be reduced by a single second.
Over the past 12 months, the traffic has approximately doubled, from ~60'000 tx/day. The growth seems to be linear, at the rate of 5000 tx/day per month. If the growth continues to be linear, it should reach 160'000 tx/day in ~8 months (before May 2016). If the growth is assumed to be exponential, it should reach that level in ~5 months, in February 2016.
If the maximum block size were lifted to 8 MB, assuming that empty and partial blocks would continue to be mined in about the same proportion as today, the effective capacity of the network should rise in proportion, to ~6 MB/block (1'600'000 tx/day, 5.90 tx/s). Based on last year's growth, the 80% capacity level (1'280'000 tx/day) will be reached in ~19 years assuming linear growth, and ~3.4 years assuming exponential growth.
Spam attacks
An effective spam attack would have to generate enough spam transactions, with suitable fees, to reduce the effective capacity of the network to a fraction of the legitimate traffic. Then the fraction of the traffic that cannot be serviced will pile up in the queues, forming a growing backlog until the spam attack ends; and the backlog will then clear at the rate limited by the free capacity C - T.
With the current capacity C (200'000 tx/day) and traffic T (120'000 tx/day) a spam attack that blocks half the legitimate traffic would require a spam rate S of at least C - T/2 = 140'000 tx/day (1.62 tx/s, 0.52 MB/block). The fee F per kB offered by those transactions would have to be larger than all but the top ~420 transactions in the queue. If that fee were to be 1 USD/tx, the attack may cost as little as 140'000 USD/day. The backlog of legitimate transactions would grow at the rate of T/2 = ~2500 tx/hour, and, when the attack stops, will be cleared at the maximum rate C - T = ~3300 tx/hour.
With 8 MB block limit, assuming that the effective capacity C will be 1.6 M tx/day and traffic T at 60% of the capacity (like today; expected to be the case 3 years from now), a spam attack that blocks half the traffic would require C - T/2 = 1.12 M tx/day of spam (8 times what an attack would require today). If the required fee F were to be 1 USD/tx, the attack would cost 1.12 million USD per day (ditto).
The maximum block size would be programmed to be 1 MB until block number 394999, and 8 MB starting with block 395000; which, at 144 blocks/day, is expected to be mined around 2016-02-06.
On the test network, the increase will start with block 390000, which is expected to be mined around 2016-01-02.
In the interest of a quick and uneventful passage through that block number, major miners should publicly state their approval or rejection of it as soon as possible.
If and when the plan is approved by miners comprising a majority of the hashpower, all miners and clients should be alerted and urged to upgrade or modify their software so that it accepts blocks up to 8 MB after the stated block number.
If and when the plan is rejected by miners comprising a majority of the hashpower, all miners and clients shoudl be alerted and warned that this BIP will not be implemented.
The proposal should have a good chance to be approved and implemented, since the five largest Chinese miners (who have more than 50% of the total hash rate) have already stated in writing that they would agree to an increase of the limit to 8 MB by the end of the year, even theough they did not approve futher increases (in particular, the doublings specified by BIP101). Several major services and other miners have expressed approval for such an increase in the net.
There have been claims that increasing the block size beyond 1 MB would have negative consequences for the health of the network. However, no serious effects were demonstrated, by argument or experimentally. There are worrisome trends in sme parameters, such as the number of full nodes and and the centralization of mining; but those trends obviously are not related to the block size limit, and there is no reason to expect that they would be halted or reversed by imposing a 1 MB cap on the block size starting next year.
It should be noted that the increase is only on the block size limit; the actual block sizes will continue to be determined by the traffic. Even with optimistic forecasts, the average block size should not exceed the 1 MB limit before the end of 2016. If any harmful effects of larger blocks are demonstrated until then, the limt can be reduced again by decision of a majority of the miners.
It has been claimed that netowrk congestion would be beneficial since it would create a "fee market" whereby clients would compete for space in the blocks by paying higer transaction fees. It has been claimed that those fees would compensate for the drop in miners revenue that will follow the next reward halving in 2016. It has also been claimed that the higher fees will inhibit spam and other undesirable uses of the blockchain. However, the "fee market" would be a fundamental totally untested change in the client view of the system. It proposes a novel pricing mecanism that is not used by any existing commercial service, physical or internet-based. There is no evidence that the "fee market" would work as claimed, or that it would achieve any of its expected results. (Rather, there are arguments that it would not.) Congestion would defintely put a cap on usage of the protocol, reduce its value as a payment system, and drive away much legitimate traffic. Congestion, and the unpredictable delays that result from it, are also unlikely to make bitcoin attractive to high-value non-payment uses, such as settlements of other networks or notarization of asset trades. And, mainly, there is no reason to expect that the fee market will generate enough fees to cover the 500'000 USD/day that the miners will lose with the next halving.
If this change to the Bitcoin protocol gets implemented by a majority of the miners, all players will have to replace or modify their software so that it accepts blocks up to 8 MB after block 395000.
Miners who fail to do so may soon find themselves mining a minority branch of the blockchain, that grows at a much slower rate, will probably be congested from the start, and will probably die soon. That branch will probably be ignored by all major services, therefore any rewards that they earn on that branch will probably be worthless and soon unspendable.
Clients who fail to upgrade or fix their software will not "see" the majority-mined chain once someone creates a block with more than 1 MB. Then, those clients will either be unable to move their coins until they fix their software, or may see only the minority branch above. Transactions that they issue before the fix may get confirmed on the main branch, but may appear to remain unconfirmed on the minority chain. Useof tools like replace-by-fee or child-pays-for-parent while in that state may give confusing results.
The author has never owned or used bitcoin, and has a rather negative view of it. In fact, he is a regular contributor to /buttcoin. While he sees bitcoin as a significant advance toward its stated goal ("a peer-to-peer payment system that does not depend on trusted third parties"), and finds bitcoin interesting as a computer science experiment, he is quite skeptical about its chances of widespread adoption. He also deplores the transformation of bitcoin into a negative-sum pyramid investment schema, which not only has spread much misery and distress allover the world, but has also spoiled the experiment by turning mining into an industrial activity controlled by half a dozen large companies. He hopes that the pyramid will collapse as soon as possible, and that the price will drop to the level predicted by the money velocity equation, so that the aberrant mining industry will disappear. (However, he does not think that this BIP will help to achieve this goal; quite the opposite, unfortunately.)
submitted by jstolfi to bitcoin_uncensored [link] [comments]

Stephen Pair, CEO of Bitpay, on BIP 101, node decentralisation and bitcoin as a settlement layer

Now my question: What are you doing to help mold consensus around BIP101 (or if not that, some other block size solution)? Are you flying out to meet with miners? Are you calling up other people in the ecosystem? If you have been doing this, how have those conversations been going? What sort of counterarguments are you getting?
We've been talking to other companies, miners and core developers about it. I also went to the Scaling Bitcoin conference in Montreal (which I thought was one of the best Bitcoin conferences I'd ever attended). We had hoped that a consensus would be reached among core developers and we would follow that consensus, but it got to a point where we thought we needed to make our views known. The counter arguments are generally along the lines that if you increase the resource requirements on a node, less people will run nodes and bitcoin will become centralized. People also state that bitcoin can/should be used as a settlement layer. We of course agree that bitcoin must remain decentralized. While an increase in resource requirements for a node will discourage more nodes, an increase in throughput will accommodate more adoption, which will encourage more nodes. The economic decision to run a full node has to do with how much you value the ability to independently and trustlessly validate transactions. That ability is worth a lot if you assume Bitcoin enjoys widespread adoption. In addition, there is a lot of room for optimization that would reduce the resource utilization of a node. Regarding the settlement layer arguments, I don't think Bitcoin is compelling as a settlement layer unless it enjoys widespread adoption as a payment network. Bitcoin's utility as a payment system is its intrinsic value. If it's not useful for that purpose, it doesn't really have any value. If it doesn't have any value, it has no value as a settlement system. To put it in other words, if it cannot be practically used to pay people for things, then why would you have any interest in using it for settlement?
submitted by w0dk4 to Bitcoin [link] [comments]

Why not forking into two different permanent chains?

Since there are two groups with a completely different vision of what bitcoin should be (a payment system or an expensive settlement system), then why not lowering the bip101 mining activation threshold to a smallish value (say 30%) and allowing a fork into two permanent chains? There would then be two different cryptocurrencies existing in parallel, and everyone is happy...
submitted by madjophur to btc [link] [comments]

100,000 Transactions Per Second: How Do We Get There?

Who can pony up what?
Cryptocurrency Max Throughput comment
Bitcoin 3tps cough
Peercoin 3tps as far as I know
Litecoin 8tps rough, conservative estimates of theoretical current max
Dogecoin 20tps theoretical
Reddcoin 20tps theoretical
Nyancoin 20tps theoretical
So we've got 74tps of blockchain capacity so far. Little short yet.
Ripple: Hm, I didn't have the transaction rate for Ripple determined. There is debate over whether they "count". Sees reasonable to me, although I see reasonable arguments against. More than a year ago, I had them at 80,000 transactions in 24 hours, which of course, is relatively small in tps (<1), but that's the actual rate and I hadn't noted any limit. I suspect they may be a route to Visa-scale.
For transaction cost, it seemed to be less than a ripple but I didn't have a source. My wifi is bad right now, can't check.
Let's count Ripple as an "Ace-in-the-hole". I think it's technology worth considering for sure. It may have very complementary value or it may ultimately be superior.
Let's imagine some crazy growth rates. Nightmare scenario datacenter world for all the coins except for some hold-outs. Let's presume BTC as a holdout and look at what the throughput rates of various coins are. I have notes for some of these in my archives. For some of them I may have to look up some new information.
I'm not sure how to put LTC in our hypothetical. If we put it as expanding, I believe it becomes the leader. If we put it as following BTC in keeping the current throughput limit, then it doesn't really matter in our analysis here. Let's leave LTC and PPC with BTC as being conservative in our hypothetical consideration of throughput capacity. (However, shout-out to ProHashing with the BIP101 in LTC attempt; I do hope that's successful, just as I hope one of the hardfork blocksize increases on BTC will be successful. And PPC arbitrarily lumped in just for having a 10 minute block time from my notes.)
There's a trick I'm going to pull here now and explain: I'm going to use, in counting to our goal, the aggregate performance of 100 combined cryptocurrencies, arbitrarily. I think this is a pretty conservative estimate of the number of reasonable existing candidates. Let's assume that all coins have a minimum of the DOGE setup for current throughput: 1MB block cap (so far as I know; not aware of a clonecoin with enough foresight to have taken it out; worth double checking in the code of each reference (network most common) implementation), but with a 1 minute block rate target, which allows 10x the throughput capacity.
Between this lovely feature and that one neat trick, we already have a starting throughput capacity of 2,000 tps. Not bad as a starting point for a competitor to 3tps.
This seems like a good point to note that it should be patently obvious that there are far more important things to the market cap valuation than the single factor of throughput capacity. If it were not so, then Bitcoin could not have 88% of the cryptocurrency market. There is a very strong first mover advantage, network effect, and has been a strong history of buying Bitcoins to build confidence. This document is a thought-experiment sparked by the casual dismissal of the impossibility of Bitcoin ever passing or even reaching Visa-like capacities for throughput in a lauded post by a chief architect of the Core Bitcoin 1MB policy. I've had this general thought before, but I've never done the full-blown write-up before. And here we are. So this is a thought-experiment limited to throughput capacities for the sake of technical consideration, and deliberately excluding market-cap / financial implications of such changes in my analysis.
Now we need a 49x increase to get to 100,000 tps. We could spawn more coins, but I think we're all collectively exhausted by the number of coins in existence currently, so I'll put that as a second-choice option. So let's automagically presume the average blocksize hard-cap on the "100 clones" category, as I'll call it arbitrarily for no particular reason, has risen to an average of 50MB from its currently uniform 1MB. And there it would be: theoretically, a system which could transact on any of those 100 coins, considering the capacity of all the coins together, would in total have a maximum throughput of 100,000 tps (and presumably, like Bitcoin, sustained capacity essentially equal to burst capacity).
Could the current BTC code handle 50MB blocks reasonably? Frankly, I don't know but I doubt it. I think we're going to find out though. And I don't think it will be particularly difficult to reach that point ultimately when taking in upstream changes as well as any improvements which may develop among the 100 or others. Within the next 5 years I think this should be feasible, not merely for 1, but for 100 coins. That's how the blockchain scales to 100,000 tps. Blockchain: look ma, no Bitcoin!
This might seem like a rather crazy view to some. I know in the Bitcoin subreddits, it's heresy and uninteresting to speak of anything else, in particular, never those clonecoins! Those awful, awful clonecoins. There have been some slight cracks in that policy in some bitcoin communities, but in general, the position holds. But to me, the technology is interesting. And there's not really a lot of technological difference between a Bitcoin, Litecoin, Dogecoin, or Nyancoin transaction. There are significant financial differences in their implications, but the technology is basically the same, because LTC copies BTC and DOGE copied LTC (originally, then went and went to BTC base with Scrypt AuxPoW) and NYAN copied LTC. So it's really pretty basic that if one needs more BTC transactions, if it were possible to substitute the other networks for those purposes, then these independent networks which are technically almost-identical seem to be the obvious choice. And once that step has been made, the problem is more than half-solved already.
In fact, this is the way in which I agree with the BTC small-blockists: clearly the sky isn't falling yet. The transactions haven't truly spiked across the board and down the heap so far. Fidelity hasn't decided to build a 100 clone based system. But, for instance, I think it would be possible to build various "Layer 2", one might say, applications which were coin-agnostic. For instance, consider the purpose of a colored coin: transferring ownership of some particular external concept because of some external agreement about what this transaction represents. So as long as the protocol covers the variety of transfer, we don't really care necessarily if any of the underlying protocols recognizes what's going on. That is, for instance, a DOGE is transferred from Alice to Bob which represents some sort of mutex: now Bob can edit Resource without conflict. Bob then wants to transfer this mutex to Carol and sends a NYAN to an address Carol controls, where the transaction contains a signature for the particular DOGE received by BOB from Alice which represents the mutex.
Of course, there are obvious potential issues with this off-the-cuff example. The one which came to mind to me at the end was "what if Bob tries giving the mutex to Dan on RDD at the same time he gives it to Carol on NYAN?" I'm not sure how to resolve that at the moment. Perhaps the protocol would have ways of designating a type of resolution or hierarchy of coins for resolving that particular coin. It would be possible to switch chains safely if done with a blockchain action on the current chain, but if for some reason that weren't available, then perhaps the protocol could allow a mechanism where a person registers a claim on an alternate chain using a signature for the original as described, and after a certain period of time, if no conflicting signatures on any of the other 100 occur during 6 hours (or some long period) to ensure legitimacy (alternately shorter for less security-critical applications).
I think there could be interesting use and application for such a system. Regardless of its utility, I think it's clear that it's possible with incremental improvement on the existing code and the technology currently available.
Personal, non-technical statement: I would like to see this develop. I think this is more useful and decentralized than any single cryptocurrency "winning" everything. This is the cypherpunk dream outcome in my view. I have always expected and wanted Bitcoin to keep doing better and better, and perhaps it will continue to do so, but I also believe that having "reasonable" throughput capacity is also good. And having a lot just because you can is cool. This stuff is still experimental. What's the point if we don't push the limits a bit?
Edit: Ahh, the comments are a greatest hits of how to miss the point. I love it. No one refutes anything I said here though, because it's so painfully obvious they can't. 100 clonecoins could reach Visa-like capacity within a few years. This while "experts" wax eloquently about how impossible it would be for a blockchain to scale.
The point is not that this is the only way. The point is that there is at least one way, which ought to give some pause about how credible this "expert" is who claims this is impossible.
Just because Bitcoin chooses to cripple itself is no reason for the rest of us to do so.
But yeah, blather on some more about Lightning Networks. It's really relevant.
submitted by coinaday to CryptoCurrency [link] [comments]

Bitcoin traffic and capacity data

The following are approximate numbers, assuming 144 blocks/day, 500 bytes/tx[0] on average in normal conditions (outside of stress tests).
EDIT 2015-09-06: addded extrapolation to Jul/2016 with 8 MB limit.
Situation today
Demand T: 120'000 tx/day, 830 tx/block, 1.4 tx/s; 60 MB/day, 420 kB/block, 700 bytes/s
Capacity C[1] : 200'000 tx/day, 1400 tx/block, 2.3 tx/s; 100 MB/day, 700 kB/block, 1200 bytes/s
Clearance C − T[2] : 80'000 tx/day, 570 tx/block, 0.9 tx/s; 40 MB/day, 280 kB/block, 500 bytes/s
Saturation: 60% (C = 1.67 × T)
Situation by Oct/2010 (when the max block size was lowered from 32 MB to 1 MB)
Demand T:[3] 2300 tx/day, 16 tx/block, 0.027 tx/s; 1.15 MB/day, 8 kB/block, 13 bytes/s
Saturation: 1.2 % (C = 87 × T)
Predicted situation by Jan/2016 with 1 MB block size limit
Demand T[4] : 150'000 tx/day, 1040 tx/block, 1.7 tx/s; 75 MB/day, 520 kB/block, 870 bytes/s
Clearance C − T: 50'000 tx/day, 360 tx/block, 0.6 tx/s; 25 MB/day, 180 kB/block, 330 bytes/s
Saturation: 75% (C = 1.33 × T)
Predicted situation by Jul/2106 with 1 MB block size limit
Demand T[4] : 180'000 tx/day, 1250 tx/block, 2.1 tx/s; 90 MB/day, 625 kB/block, 1040 bytes/s
Clearance C − T: 20'000 tx/day, 150 tx/block, 0.3 tx/s; 10 MB/day, 75 kB/block, 160 bytes/s
Saturation: 90% (C = 1.1 × T)
Predicted situation by Jul/2106 with 8 MB block size limit (BIP101, BIP99½)
Demand T[4] : 180'000 tx/day, 1250 tx/block, 2.1 tx/s; 90 MB/day, 625 kB/block, 1040 bytes/s
Capacity C[5] : 1'600'000 tx/day, 11'000 tx/block, 18.6 tx/s; 800 MB/day, 5600 kB/block, 9600 bytes/s
Clearance C − T: 1'400'000 tx/day, 9800 tx/block, 16.4 tx/s; 710 MB/day, 4900 kB/block, 8200 bytes/s
Saturation: 11% (C = 8.9 × T)
[0] The average transaction size seems to have been near 500 bytes for most of the time since 2010 at least.
[1] The actual capacity of the network was revealed during the "stress tests" in early July, when the queues had a backlog that peaked at 200 MB (400'000 tx) and lasted for several days. The capacity is only 700 kB/block, not 1 MB/block, because miners often output empty or partially empty blocks, even when the queues are full. It is assumed that the capacity was the same in 2010, although the actual traffic never reached 2% of it.
[2] The clearance determines (a) how hard it is to create a persistent backlog on the queues, due either to natural traffic surges (at peak hours and days, or random fluctuations) or to malicious spam attacks; and (b) how fast a backlog is cleared after the traffic T returns to its normal average value.
[3] Actually 2300 tx/day was a peak demand observed in three short periods during 2010. Except for those peaks the demand was about 400 tx/day by the end of 2010.
[4] Those predictions for 2016 assume that the average demand will continue to rise linearly by 5000 tx/day every month,as it seems to have been doing over the last 12 months (when it grew from 60'000 to 120'000 tx/day). If the growth were to be exponential rather than linear -- i.e., doubling every 12 months -- then the demand would be 150'000 tx/day (75% saturation) by Dec/2015, and 180'000 (90% saturation) by Ma2016. Since the demand varies strongly with the day of the week (± 15% or more) and with the hour of day (± 30% or more), recurrent traffic jams, lasting several hours each, are expected to occur well before the network reaches 100% saturation.
[5] Assuming that the percentage of empty and partiually empty blocks, in a persistent backlog condition, will be about the same as seen in the recent stress tests.
submitted by jstolfi to Bitcoin [link] [comments]

No need to push bip101

Disclosure I favor bip101 as it is the only tangible solution with real code for "scalability" not just scale. Not just talk, theory or proposals.
However IMHO Better solutions are possible. More of which will become available last minute as we approach filled blocks. Whenever that may actually be.
If you are an economics geek like most of us in these subreddits, you should realize that demand for a fix increases as the block size gets close to what i believe a fictional breaking point.
it is in the majority* of everyone's interests of those that can implement changes (miners/exchanges/nodes/developers) to see bitcoin succeed. Which is why I don't think said breaking point exists. All of which are aware of bip101 as well as some other potential avenues of scaling.
In the end the solution that works best will win. Further education on bip101 to users at least is not really required at this point.
I personally think nullc is correct in fearing a fork. Forking Is the single most dangerous thing we can do the blockchain, even when properly tested.... there are still no guarantees about real world success in the long term.
The hate towards him is unjustified.
Even gavinandresen fears forks, he coded bip101 because as bad as forks are having no competitive options is a worse situation. A very valid position to have. While some of the others in core may disagree with said position, i am willing to bet they also value having competing opinions. despite what might be misrepresented here on this subreddit.
Is a soft fork solution possible? Some developers think yes others no.Universally agreed soft fork is optimal solution (if possible). Soft fork options will be investigated right up until the very last minute, but in the end there will always be a hard fork solution availible. Because it is there I don't fear the block size.
The speed of which miners can upgrade is very fast. Which means this can happen right at the very last minute... though i suspect will happen when we are very close to full capacity or about a week where full blocks are the majority.
Ideas and merits do and need to stand on their own, including bip101. No need to push bip101 or any other for that matter.
submitted by bitwork to Bitcoin [link] [comments]

Bitcoin traffic and capacity data

The following are approximate numbers, assuming 144 blocks/day, 500 bytes/tx[0] on average in normal conditions (outside of stress tests).
EDIT 2015-09-06: addded extrapolation to Jul/2016 with 8 MB limit.
Situation today
Demand T: 120'000 tx/day, 830 tx/block, 1.4 tx/s; 60 MB/day, 420 kB/block, 700 bytes/s
Capacity C[1] : 200'000 tx/day, 1400 tx/block, 2.3 tx/s; 100 MB/day, 700 kB/block, 1200 bytes/s
Clearance C − T[2] : 80'000 tx/day, 570 tx/block, 0.9 tx/s; 40 MB/day, 280 kB/block, 500 bytes/s
Saturation: 60% (C = 1.67 × T)
Situation by Oct/2010 (when the max block size was lowered from 32 MB to 1 MB)
Demand T:[3] 2300 tx/day, 16 tx/block, 0.027 tx/s; 1.15 MB/day, 8 kB/block, 13 bytes/s
Saturation: 1.2 % (C = 87 × T)
Predicted situation by Jan/2016 with 1 MB block size limit
Demand T[4] : 150'000 tx/day, 1040 tx/block, 1.7 tx/s; 75 MB/day, 520 kB/block, 870 bytes/s
Clearance C − T: 50'000 tx/day, 360 tx/block, 0.6 tx/s; 25 MB/day, 180 kB/block, 330 bytes/s
Saturation: 75% (C = 1.33 × T)
Predicted situation by Jul/2106 with 1 MB block size limit
Demand T[4] : 180'000 tx/day, 1250 tx/block, 2.1 tx/s; 90 MB/day, 625 kB/block, 1040 bytes/s
Clearance C − T: 20'000 tx/day, 150 tx/block, 0.3 tx/s; 10 MB/day, 75 kB/block, 160 bytes/s
Saturation: 90% (C = 1.1 × T)
Predicted situation by Jul/2106 with 8 MB block size limit (BIP101, BIP99½)
Demand T[4] : 180'000 tx/day, 1250 tx/block, 2.1 tx/s; 90 MB/day, 625 kB/block, 1040 bytes/s
Capacity C[5] : 1'600'000 tx/day, 11'000 tx/block, 18.6 tx/s; 800 MB/day, 5600 kB/block, 9600 bytes/s
Clearance C − T: 1'400'000 tx/day, 9800 tx/block, 16.4 tx/s; 710 MB/day, 4900 kB/block, 8200 bytes/s
Saturation: 11% (C = 8.9 × T)
[0] The average transaction size seems to have been near 500 bytes for most of the time since 2010 at least.
[1] The actual capacity of the network was revealed during the "stress tests" in early July, when the queues had a backlog that peaked at 200 MB (400'000 tx) and lasted for several days. The capacity is only 700 kB/block, not 1 MB/block, because miners often output empty or partially empty blocks, even when the queues are full. It is assumed that the capacity was the same in 2010, although the actual traffic never reached 2% of it.
[2] The clearance determines (a) how hard it is to create a persistent backlog on the queues, due either to natural traffic surges (at peak hours and days, or random fluctuations) or to malicious spam attacks; and (b) how fast a backlog is cleared after the traffic T returns to its normal average value.
[3] Actually 2300 tx/day was a peak demand observed in three short periods during 2010. Except for those peaks the demand was about 400 tx/day by the end of 2010.
[4] Those predictions for 2016 assume that the average demand will continue to rise linearly by 5000 tx/day every month,as it seems to have been doing over the last 12 months (when it grew from 60'000 to 120'000 tx/day). If the growth were to be exponential rather than linear -- i.e., doubling every 12 months -- then the demand would be 150'000 tx/day (75% saturation) by Dec/2015, and 180'000 (90% saturation) by Ma2016. Since the demand varies strongly with the day of the week (± 15% or more) and with the hour of day (± 30% or more), recurrent traffic jams, lasting several hours each, are expected to occur well before the network reaches 100% saturation.
[5] Assuming that the percentage of empty and partiually empty blocks, in a persistent backlog condition, will be about the same as seen in the recent stress tests.
submitted by jstolfi to bitcoin_uncensored [link] [comments]

Full English Transcript of Gavin's AMA on 8BTC, April 21st. (Part 3)

Part 1
Part 2
Raw transcript on Google Docs (English+Chinese):
Translators/Organizers: emusher, kcbitcoin, nextblast, pangcong, Red Li, WangXiaoMeng. (Ranked in alphabetical order)
34. Lory
Q: What is your relationship with Chainanchor project, or a similar project?
A: I have never heard of Chainanchor until this question. I don’t have any relationships with any projects that are working on digital identity.
35. xraysun
I found out this link:, Gavin, you said: [But even before stepping down as Lead I was starting to wonder if there are ANY successful open source projects that didn't have either a Benevolent Dictator or some clear voting process to resolve disputes that cannot be settled with "rough consensus."]. I think you are quite right. Wladimir’s roll is hard, huge responsibility with unfitting return. However, that’s not the reason for demanding unanimous support for changes to take place, allowing one-vote veto. What’s the different between having Wladimir and a robot then?
My question is: Other than trying to be “decentrilized”, is it also because that you found the leading dev roll with too much responsibility but too little return, so that you gave up your power? After that, realizing the 5-dev-group (the devs with commit access) need to be somehow centralized, have you ever tried to abolish one-vote veto, and change it to a majority rule. If it was changed to majority rule now, we might need another leading dev. Are you willing to lead the development again?
A: I think I am much better at writing and communicating and thinking about ‘the big picture’ than I am at managing and keeping track of hundreds of small details.
People have encouraged me to be “the Linus Torvalds of Bitcoin,” but I looked at what Linus actually does and I don’t think I would be very good at it or enjoy it. He spends a lot of time with the details of pulling in changes to the Linux kernel, and that is the kind of thing a lead developer needs to spend time doing. Wladimir is good at that.
Even if the Core project changed from “overwhelming consensus-- one or two people can veto a change” to “majority rule” I don’t think I want the lead developer role. If there was nobody else to do it, I would return, but I think there are now lots of people who would be good lead developers. Some of them are leading projects like Bitcoin Unlimited or btcd or Bitcoin Classic, and that is great!
36. ls-a
Q: Lots of people say that “Bitcoin is dead”. What’s your opinion on this? Does Bitcoin still have a future?
A: Bitcoin absolutely has a future. It has been declared dead dozens of time, and I am sure it will be declared dead dozens of times more before people get tired of saying that it is dead.
37. redl
Q: Bitcoin has been stably running for seven years, why not the core developers act like Satoshi, just watch it, so as to avoid development centralization?
A: Good developers always want to make things better!
And there are changes that must be made as more people use Bitcoin.
38. Ma_Ya
Q: What’s your opinion on Dogecoin? Is it possible that Dogecoin becomes one of Bitcoin’s sidechains, so that it can helps the traffic on Bitcoin mainchain?
A: I like the 21-million bitcoin limit. I think it makes sense for there to be a limited, predictable supply of money.
So I don’t like altcoins that create even more money; you can think of it as a sneaky way of increasing the 21-million coin limit. If Dogecoin was just a sidechain, without its own currency, then I would like it more.
39. Gladpay
Q: Gavin, what’s your opinion on Ethereum? Any comment on the trend that the industry started to talk about blockchain without mentioning Bitcoin?
A: I answered another question about Ethereum.
As for “we like Blockchain” instead of “we like Bitcoin” : I don’t have a strong opinion about that. I answered another question about private blockchains; I think they make sense for some things, and not for others.
40. frankf
Q: Can you explain why it is not possible to solve the congestion problem by reducing block generation time? Is reducing block generation time the same as increasing blocksize?
A: It would be even more controversial to reduce the block generation time than it is to increase the block size limit. It is technically more difficult to safely reduce the generation time, and would require more changes to more software. In particular, lightweight wallets that just download block headers might have to download many more headers, increasing their bandwidth usage.
41. ZhongBenCong
Q: Hi, Gavin, I‘m curious why you always change your idea in the size of block limit? Why not insist on one hard fork solution? I think you did not think about it carefully on how to increase the limit, what’s your opinion?
A: I have been trying very hard for a long time to find a solution that most people can agree on, and have made just two proposals (BIP101 and BIP109).
I have thought very carefully about how to safely increase the limit. Part of the problem is it can be done in many ways, and it really doesn’t matter which way is chosen-- it is more important that SOMETHING is chosen. Those are the decisions that are the hardest to make, because it is easy for people to have different opinions about what way is best.
42. FengFengZhongXuYaoNi
Q: Sure, I’m gonna ask something other than blocksize and Classic vs. Core. Gavin I just want to ask you a question as an ordinary trader. Do you believe that Bitcoin can serve as a good store of value? Because you said on bitcontalk that Bitcoin cannot become a significant instrument for storing value Do you still think so?
A: That feels like a very long time ago I said that…
I still think that the best store of value is in diversified investments that are investing in people that are working hard to make the world a better place. So the part of my personal savings that is not Bitcoin is mostly invested in diversified stock mutual funds.
Having some of your savings in a very safe investment makes a lot of sense; something like precious metals is probably the safest investment right now.
Hopefully some day Bitcoin will be safer than gold, and it will make sense to hold Bitcoin as part of your “safe from stock market craziness” money. Today, I think it makes sense to hold some Bitcon as part of your “high risk but maybe high future reward” money.
But please don’t invest all of your money in any one thing!
43. ShaSiBiEr
Q: I just want to ask that, Gavin, you have a title “Chief Scientist at the Bitcoin Foundation”, what does it mean? What’s the main responsibility, and who assigned it to you?
A: There was a meeting in Seattle where we created the Foundation. I don’t remember who suggested the “Chief Scientist” title, but it seemed better than the rest of the possible titles we were thinking of.
I am fortunate to have very few responsibilities. I am given the freedom to do what I think will be best for Bitcoin. I tell people I have almost no gray hair (I should have gray hair, I will be 50 years old at the end of the year) because I organize my life so that I do not need to manage people and almost never have to talk with lawyers.
44. pangcong
Q: How did you know Satoshi at the very beginning, did he come to you, or you were attacted by the Bitcoin project and contacted him?
A: I contacted Satoshi on the bitcointalk forums. Here is my first message to him:
Hey Satoshi:
I want to help make Bitcoin a success. I've started by creating, and plan on doing a couple of other small projects like it.
But I think I might be able to help in lots of other ways. I was the chief architect of the VRML 3D-graphics-on-the-web standardization effort (which is STILL a solution in search of a problem, unfortunately), and had the unpleasant experience of taking it through the ISO standardization process.
I've also written a lot of C++ code (I'm very proud of the code I wrote as part of the Open Inventor team at Silicon Graphics), although it's been a while (I've switched to Python).
I'm very curious to hear more about you-- how old are you? Is Satoshi your real name? Do you have a day job? What projects have you been involved with before?
Anyway, Bitcoin is a brilliant idea, and I want to help. What do you need?
-- Gavin Andresen
45. XiaoMaYi
Q: Gavin, last time when you were in Beijing, what did you say in that meeting?
*A: *The first and only time I’ve been in China was the end of last month (March).
The purpose of the trip was to meet with some of the mining pools and miners, to better understand what they are thinking about the block size limit, segregated witness, the halving, and anything else that is an issue right now.
I did not say a lot-- just made clear some technical points about BIP109, and explained what I have been hearing from large and small companies in the West.
46. Satoshi
Q: Gavin, what do you think is the best way to introduce / explain Bitcoin to an average Joe?
A: I usually start by saying that Bitcoin is one of those ideas that sounds crazy when you first hear it. And then I describe it as “money for the Internet, that is designed to be like the Internet-- with no single person or government or company in control.”
Then I let them steer the conversation and ask questions if they are interested. Some people want to talk about what governments think, some people want to know about the technology, some people want to know if they should invest or how easy it is to use… there are lots of things to talk about!
47. QiBuShangTianTang
Q: Gavin, you’re working for bitcoin as a career, is there anyone around try to deride or attact you about what you’re doing? How did you move on and continue your work? What do you think about the current situation of bitcoin development?
*A: *There are always people on the Internet who seem to like attacking other people. I don’t know if it is better or worse with Bitcoin; probably worse, because people care so much about it.
I get many more people thanking me for the work I do on Bitcoin than people attacking me, so usually it is easy to move on and continue my work. I am most hurt when I am attacked by people I have worked with in the past; that is discouraging.
I think overall Bitcoin development is stronger than it has ever been. There are more people contributing, not just to Core but to other projects, and more innovation happening.
But moving from there being just one implementation of the protocol to multiple competing implementations is necessary, but difficult. I wish developers did not see that transition as being some sort of personal attack.
48. kcb
Q: Hi Gavin, SegWig had a PR a couple of days ago, however, the blocksize limit is still 1MB, the amount of transactions can be processed are still the same per block. I really want to know that when we can benefit from SegWig, and when can we actually have blocks that can process more transactions?
A: If everything goes perfectly, we might see a significan number of SegWit transactions in three months. I would guess it will take six months for the miners to adopt segwit and then wallets to start producing segwit transactions, but it could take a year.
Unfortunately, transaction volume was growing more quickly than that, so even if Segwit helps, it will not help quickly enough.
49. ZhongBenCong
Q: Hi Gavin, you said in 2015 that having 1-minute block generation time is a good idea. Do you still believe so? If yes, can you share your strategy on dealing with the security issues and the higher orphan rate?
A: Yes, I still believe Bitcoin would work just fine with a one-minute block generation time.
I don’t think we should change that right now, though, because it would be a big change that requires changing lots of software.
I’m not sure what security issues you are talking about, perhaps you could be more specific.
As for higher orphan rates: if everybody has a higher orphan rate, then that is not a problem (unless orphan rates get very high-- say 5-10% or more). Even worries about larger miners having an advantage at higher orphan rates could be addressed with some protocol changes.
But, again, all of that is a much longer discussion that I don’t think we should have right now. Increasing or eliminating the block size limit is much simpler.
50. BiTeCui
Q: Hi Gavin, how many hours do spend on working every day? Do you still write code nowadays?
*A: *It depends on what you mean by “working” -- does answering email after dinner count?
I try not to work too much; I need to get more exercise, and like to spend time with my family (my children will be going to college in just a few years). I am usually at my office maybe seven hours, five days per week, and on good days I do get to still write code.
Q: Hi, Gavin, how many children do you have? :-D How do you balance between your life and bitcoin?
A: Two children, a girl and a boy, both teenagers. The trick to balancing life and bitcoin is to say “no” a lot (“no, I’m sorry, I cannot speak at your conference in Botswana”).
52. fermi
Q: Hi Gavin, I’m very worried about bitcoin may split to two coins, which is very bad. So I once posted on 8btc to discuss how to prevent bitcoin from splitting in future. Simply put, we just add all different opinions into one wallet, and the network automatically hard fork based on the vote result of the wallet. In this way, there would be no splitting ever happen. Do you think this idea would work out? (See above image as an illustration of the idea)
A: Agreeing how the vote would work would be hard (would transactions vote? For how long? 51% agreement or 75% or 95%?) Only transactions in blocks count as voting? (if not, then somebody could send lots of transactions to vote multiple times) And what if miners decide not to mine transactions that vote for something they disagree with?
53. BiTeCui
Q: Gavin, do you think large institutions wil join in Bitcoin ,like big fund or bank? There are news mentioned about safery regulations and risk factors in bitoin, may they be eliminated? Or will bitcoin be a game for ordinary people forever?
A: If Bitcoin continues to grow, then yes, I think large institutions will start to accept Bitcoin. We have already seen some big technology companies like Microsoft work with Bitcoin.
Most of the risk with Bitcoin is caused by new, immature companies (like Mt. Gox). The risk is smaller today, because larger, more stable, better funded companies with better engineers are involved, and I expect that will continue.
I hope Bitcoin will also be used by ordinary people forever!
54. baowj
Q: What are you most proud of since you've join in Bitcoin development?
A: All of the testing infrastructure that I put into place. My first contribution was the Bitcoin testnet, and if I remember correctly I also put the first unit tests in place and the first regression tests.
55. kcb
Q: Hi Gavin, do you mind further share some insights on why you think Bitcoin cannot replace the fiat system and become a true global currency?
Bitcoin is a better instrument as store of value, it has better liquidity, also better against counterfeiting, and can even truly make people's wealth inviolable to anyone! (no more confiscation and capital control.)
Therefore, Bitcoin obviously is a better currency comparing to fiat. When a better currency appears, people tends to adopt it naturally, and gradually abandon the old currency. (just like how people abandoned shells, when they realized that gold is better form of money with excellent monetary attributes.
*A: * It could eventually replace the fiat system, but I don’t think that will happen in my lifetime. I hope I am wrong about that!
Q: Hi, Gavin, welcome to 8btc!
I am a altlcoin dev ,do you like one or some altcoins? And what do you think of the coins developed by Chinese Teams, like the VPNCoin、Dacrs(SmartCoin)、Antshares or others projects(these are all high light shown on
Have you ever tried to understand such altcoins?
Best Regards!
Your fans
A: I don’t like altcoins that are created just to create more money, because I like the 21-million bitcoin limit.
Altcoins that have some innovative technology in them (like Ethereum or Zerocash) are more interesting, but I would rather they were done as sidechains to the Bitcoin blockchain. I think you should have a very good purpose for creating a new currency, and if you don’t have a good purpose, you should use the Bitcoin currency.
Gavin: Thank you very much for the great questions, and BIG thanks to the translators for their hard work!
kcb: Thank you Gavin!! It’s great to have you here!!
WangXiaoMeng: Thanks a lot Gavin!!!
submitted by kcbitcoin to btc [link] [comments]

What about a new bitcoin reference client?

I'll keep this short. Development values:
1) Increase the price of bitcoin.
2) Scaling without centralization - keep a reasonable limit on block size - use BIP101 (because, see 1)
3) Preserve privacy, without allowing mainstream to marginalize bitcoin (again, see 1)
4) No private money funding reference client development (yes, again, see 1)
5) Fund through community donations, non profits, or, as much as I complained about it, research funding, like MIT (as long as it is not tied to industry or private money, see 1)
6) Follow the same governance models followed by Linux (because it worked there, and see 1)
Right now, this is bitcoin core - RFB + BIP101. Then we take it from there. I think we need Gavin on this, and a few others that balance out any concerns, and we need to make the environment tolerable too, as much as this is possible.
submitted by MrMadden to btc [link] [comments]

Power distribution and policy decision. How can we, the users, have a vote in what options we are given to uphold the original ideology of bitcoin?

The recent scaling at HK was a eye opener for a lot of people. We had > 90% of hashing power via pool operators standing on one stage, answering questions.
One thing that was very clear, to many people who were present and those who watched, is that the miners were all consistent in their answers in regards to direction on blocksize:
They want the core maintainers of the software to make the hard decisions in regards to blocksize. They are essentially giving up their vote, saying "we want you to choose for us".
Let us look at the current distribution of power:
The power distribution is listed in a relevant order here. Everyone understands that the miners a key group in the power distribution. Without network security bitcoin is worthless, so the direction that miners take will be the winning software choice. They are much higher on the decision making chain, only a step beneath the maintainers from the Top down perspective of maintainers providing software, and then the voting mechanism to choose which software is run.
Its more so the miners that get to chose the software than the users, and it is important to understand this power dynamic. The miners will chose the majority as its in their economic interests, and if we only have one option from our core maintainers, there can only be one choice. Ignoring the power of the core maintainers in this position of authority is to appeal to delusion. Their vote counts more, as well as everyone knows, than a competitor. Add a mining power allocation and their vote becomes a dictatorship.
The core maintainers prefer to take a neutral stance, stating it is the users which decide which software is run. They stay out of economic decisions and leave that to the community at wide to decide.
But if the power distribution model has been disrupted, and the miners have allocated their voting power to the core maintainers, does that change the position of authority for the core maintainers? Are they not then in a position of dictatorship, knowing that the option they give is the option that will succeed?
In this event, I would state that the only way for the core maintainers to balance the power distribution is to provide multiple options for the community to decide upon. Any single solution they provide, given the context of the miners allocating their voting decision, is going to be the winning decision. This action cannot be ignored as it represents a cabal and takes away the decentralized nature of bitcoin. This is literally a point of failure within the ecosystem, one so large that we must hash it out and make our voice heard, otherwise this can be manipulated in the future to undesirable outcomes.
Can the core maintainers ignore this position and continue to provide only one solution? Currently we have reached a rough consensus that the way forward is going to be based on gmaxwell's plan, which calls for a implementation of SW as a softwork, and keeping the traditional blocksize at 1mb. You can see current voting here
In this, I wholeheartedly agree with jgarzik and his direction, which he has voiced publicly but this specific quote was mentioned in private:
"Maintainers should come up with a menu of possibilities and let the community have a voice in choosing. There needs to be more communication to users and more choices given."
I brought up the issue of contentious hardforks, and how core maintainers may have a moral and economic responsibility to not submit those to public in fear of forking the community at large. His response:
"IMO it is done in stages - try to measure consensus - roll out - measure adoption and have fallbacks (failure scenarios) plotted out. Each point - merge / release / initial adoption / wide adoption provides opportunity for feedback and further consensus measuring -before- a chain fork. All the block size increases require 80-90% hashpower lock-in, at a minimum and miners tend to be conservative, following, not leading, consensus. Miners want to stick with the economic majority, because that maximizes the value of their bitcoin income."
What this means, is that if we were given two options, say potentially:
This would allow the users to truly have a voice. So long as the core maintainers have a majority of authority granted to them, they cannot ignore that they have a over-wielding reach of power. The only way they can distribute that power is by giving the users more choices.
Since a hardfork would require a non-contentious event, then allocating a 95% activation threshold removes that argument. If there are multiple proposals out there in the wild, then it does not matter so long as all play by the same rules. And they will all play by the same rules so long as there is a 95% threshold on activation!
All this would do would be to grant users the choice of which software they wish to run, as initially envisioned by satoshi and continued by the bitcoin community at large. So long as the core maintainers ignore their position of authority and only grant one software choice, then AFAIK, then the decentralized model has failed and has instead become a cabal of priests dictating from a position of authority.
As a final note, to those who are going to say "You have always had a choice to run alternative software", you would not be incorrect. But you would be ignoring reality. You would be ignoring the power distribution model of the current dynamics of the core maintainers, and how miners have elected them to make choices. You would be ignoring the rampant censorship in this sub that has disallowed talk of competing software.
And look where that has landed us. Now, in a scenario where the core maintainers have a higher authority than what they even themselves admit is appropriate, we cannot even discuss alternative implementations. This to me further hardens the case that it is imperative for the core maintainers to provide more options to the users so that we may actually get to chose which software we run instead of the cabal deciding for us, and also for the moderators of this forum to discontinue this abhorrent censorship of an agenda that must be discussed.
Please understand that the core maintainers did not ask for this. They are not to be blamed for being put in this situation by the miners. But also by specifically choosing to not respond to the change of authority, they are allowing a power change to occur which is against the original ideology of the decentralized nature of bitcoin. If miners are no longer voting with their hash power on which software they will run, if they are saying "you choose and we will run it" then you cannot claim it is decentralized and action must be taken to prevent this redistribution of power.
submitted by GentlemenHODL to Bitcoin [link] [comments]

BIP1001: A hybrid belt-and-braces block limit. One directional miner voting within a ceiling ramping by 40% annually.

Existing proposals:
BIP100 (draft): miner voting every 12,000 blocks with the 20% extremes removed and the floor (or perhaps mode?) of remaining values used as block limit within 50%-200% of the previous limit, up to a max of 32MB.
BIP101 (live pending activation): one time step to 8MB then an incremental increase in block limit at the rate of 40% per annum for 20 years.
Both these have been debated in detail and it is apparent that miners strongly support (no surprise!) having a direct influence on the block limit.
Introducing: BIP1001, a hybrid of BIPs 100 and 101
75% mining vote activation + 2-week grace period (as per BIP101).
8MB ceiling and 40% per annum incremental ramp (as per BIP101).
1MB initial block limit after activation (as per BIP100) and 12,000 block voting but no reduction in the block limit is possible, (new!) votes will either leave the existing limit unchanged or increase it by up to 200% or up to the prevailing BIP101 ceiling - whichever is lower. Median value of the votes is used.
No 32MB cap for miner voting. (new! but follows with BIP101)
If miner votes are bought by payment processors or wealthy Bitcoiners then that is a plus, user community input is happening.
Summary & tl:dr
Miner determined block limit within a ramping ceiling, avoiding the risks of block limit compression by a rogue 21% miner, or a too rapid escalation to 32MB. Miners increase the limit based upon their collective circumstances, but within the 40% per annum scaling of BIP101 which attempts to track computing technology: the global improvement in broadband speeds.
submitted by solex1 to bitcoinxt [link] [comments]

Thoughts on hypothetical future LN impact on Bitcoin privacy

When I first heard about the Lightning Network concept, I thought it to be a neat idea whose value add to Bitcoin was obvious: microtransactions made possible etc.
With the recent debate surrounding the max block size increase, it was interesting to witness the emerging alignment w.r.t. BIP101 and XT.
With most of the Bitcoin Core devs being paid by Blockstream, and Blockstream's inherent interest in the success of the LN, the LN becomes an important piece of the puzzle with regards to the current politics (maybe the most important, at least to Blockstream).
Therefore, the whole LN concept merits a whole lot more scrutiny and deep thought beyond my initial enthusiasm. Like many here probably, I am attracted to Bitcoin due to the fact that if I wanted/needed to, it would be possible to get some degree of anonymity in its acquisition and transaction, preventing interference and retaliatory actions by established players (banks, governments, petty criminals, etc). In other words, the increased autonomy and decentralisation afforded by Bitcoin.
If LN becomes the dominant way to transact, with the Bitcoin blockchain being used only for settlements and perhaps with much larger fees, these benefits would largely disappear. Even worse, with LN "hubs" becoming a practically necessary "middle man", these hubs will gain de-anonymisation power over the users who wish transact using them.
They could be run by companies such as Blockstream, or large financial institutions licensing the LN technology, but it'd boil down to the status quo we already had before Bitcoin: others having the power over your financial transactions.
I'd appreciate your further thoughts about this, since there are a lot more knowledgeable people in this sub, and I may be overestimating the detrimental impact possible due to LN.
Thanks for your comments.
EDIT: typo
submitted by LovelyDay to bitcoinxt [link] [comments]

Bitcoin Wallet Recovery How to Choose your Bitcoin Wallet  Best Guide to Trade Bitcoins 2014 Bitcoin - YouTube Bitcoin - YouTube

Every BIP starts as a draft, submitted by one or several authors. (Although, even before a BIP is a draft, it’s typically discussed more informally on the Bitcoin development mailing list, Internet Relay Chat (IRC) channels and/or other venues.) As a draft, the BIP can be changed and improved by the author(s), based on community feedback. In ... r/Bitcoin 1.4m members. u/Peter__R • Nov 30, 2015. Visualizing BIP101: A Payment Network for Planet Earth. imgur ... With this BIP, Bitcoin wallets could maintain an "address book" that only needs to store each payee's public key. Adding an entry to one's address book could be done by using a Wallet Name, scanning a QR code, sending a URI through a text message or e-mail, or searching a public repository. When the user wishes to make a payment, their wallet would do all the work in the background to ... Brian Armstrong, CEO of record-funded Bitcoin wallet service and exchange Coinbase, plans a code update to allow for bigger blocks in the second week of December, and has indicated he prefers BIP (Bitcoin Improvement Proposal) 101.This makes Coinbase the latest Bitcoin industry heavyweight to endorse the proposal as adopted by alternative Bitcoin implementation Bitcoin XT, although the company ... How about some rich BIP101 supporter or group starts to subsidies BIP101 blocks by sending 1 BTC to the coinbase receiver of each BIP101 block...

[index] [37822] [20067] [18072] [51191] [27560] [49359] [4759] [3757] [46700] [37665]

Bitcoin Wallet Recovery

free bitcoin sites 2014 bitcoin price bitcoin mining bitcoin wallet bitcoin zebra bitcoin to usd bitcoinker bitcoins bitcoin mining calculator bitcoin faucet bitcoin شرح bitcoin address الب� - Get two-factor authentication (2FA) to protect your Bitcoin wallet. In this video, I'll show you how to: - Get a Bitcoin wallet using so that you have somewhere to put your bitcoins. Skip navigation Sign in. Search Skip navigation Sign in. Search Bitcoin Takes Value From Alt Coins & HBO Bitcoin Ransom - 043 by The Modern Investor. 13:31. Play next; Play now; Swiss Banks Use Bitcoin, Bitcoin To $15,000? And Ethereum Works On Legality - 045 ...