Bitcoin Forum

I guess another fork is needed(for those of you who don't know bitcoin was forked before)???

What do you all think about a hard fork? Better than a soft one?

EDIT UPDATE Oct 22nd 2014: Gavin makes an AMA(ask me anything) on Reddit. https://www.reddit.com/r/Bitcoin/comments/2jw5pm/im_gavin_andresen_chief_scientist_at_the_bitcoin/

EDIT: Gavin has posted some thoughts below, please see posts 69, 78, 80, 96, 216, 240, 243
EDIT: Also please see this from Gavin: https://bitcoinfoundation.org/category/chief-scientist/

Article from Coindesk:
http://www.coindesk.com/gavin-andresen-bitcoin-hard-fork/
 


"Bitcoin Foundation (Master) Chief scientist Gavin Andresen has proposed increasing the number of transactions allowed on the bitcoin network by raising the maximum block size by 50% per year.

Doing so would require a super duper hard fork and “some risk”, Andresen conceded in a new Bitcoin Foundation blog post, but he concluded that such proposals are ballin for the long-term viability of bitcoin as a global payments system."

So the model of huge difficulties is coming to roost is honestly how I see it. The difficulty is way too high for the reward that is going out now as one of the things, the second thing is that yes more transactions need to be included obviously in the future.


Gavin says """

“Agreeing on exactly how to accomplish that goal is where peepz start to disagree – there are lots of possible solutions. Here is my current favorite: roll out a barrel of hard forks that increase the maximum block size, and implement a rule to increase the size of a fork over time, very similar to the rule that decreases the block reward over time.”""

I would tend to agree with a solution that increases or decreases by itself honestly.


Obviously edited the above to be my goofy self hehe :)

I appreciate Gavin and everyone responding! Good discussion and the entire point of this forum..

Such wouldn't be needed if alts satisfied the myriad niches, only using Bitcoin proper as a means to record transaction by those desiring to convert to fiat, among only its other strong attributes.

"News" is not something that has been on the hard-fork wishlist for over two years: https://en.bitcoin.it/wiki/Hardfork_Wishlist

I'm no protocol know-it-all, but wouldn't increasing the maximum block size increase the number of "no fee" transactions?  As the block reward drops, the protocol relies on those fees to keep miners interested. 

I figured that a few hard forks would be required during the lifetime of Bitcoin. Its part of the game. You don't know what youll need or when youll need it. So, of course major edits, forks might be required.

it is obvious a necessary to do this
as bitcoin gets more popular its features need to be adapted to the situation,so this is the most logical next stop
great decissions of Gavin

Of course it is. It might be required but doesnt mean they need it.

This answers it, there will alway be an orginal bitcoin blockchain available. But the one most people use will be much faster and more efficient and lightweight. It will essentially be akin to cutting the umbilical cord which limits the amount of transactions each second. However it will allow the protocol to trim much older transactions that are not needs to verify if a coin is authentic or not. Once it has been created, spent, and confirmed, you do not really need much more info than that. But you can still decide to keep the previous 5 transactions, or 20 transactions..

The actually bitcoin protocol, as I was once described, would be perhaps only a few weeks behind from the trimmed version, and these other forks would have much more data than the "Visa Debit/Credit Card bitcoin."

But this would likely set it free.

In some sense the main argument made, is that once you fork bitcoin, it is no longer bitcoin, but rather some other alt coin.

If a different alt coin can work within the 21million btc mined and no more, than no they will not fill the gap. Bitcoin can do it on its own. Will the people understand, will they care. Perhaps those are the 'risks' "it comes with some risks"

ahhh very interesting point. I knew there were some draw backs to making changes but this was not one that I had considered. If a block size is doubled then it is very possible more junk and low transactions will be included per block. So what if we have someone spamming 1 satoshi again and the block size is 32 MB and 70% of that gets taken up by bs? That would be very interesting to see how that is dealt with.

I suppose another consideration is people operating nodes at an average internet speed would be disadvantaged eventually, which further makes an incentive to make some kind of centralized bitcoin node network. But hopefully internet speeds will be even better and cheaper by the time this would be an issue.

Not necessarily. Just because there is more space on a per block basis does not mean that the miners will be willing to fill that space for free. The miners very well could choose to keep the blocks "empty" rather then give away free space, as having a larger block does somewhat increase the chance that a block will be orphaned

Why do people say things like this as if the miners are helpless pawns, unable to decide what goes into their blocks or not?

Serious question.

Because it's easier for people to conceptualize miners as automatons. Them having their own volition and responding to incentives complicates the mechanistic view people tend to take on this issue. It's the same reason economics is so counterintuitive yet so many people have an opinion on it. "We'll just raise the minimum wage, then employers will pay the workers more."

The onus is on users to include fees, but they will have many options ranging from micropayments to discounted subscriber based transaction validation. Such services will form competitive coalitions. The miners that don't include transactions will simply be blocked from the subscribed whitelisted mining services. You will be able to make no fee transactions if you subscribe to these services. I suspect venders will have this option first, but consumers may opt for them as well. It will be their choice to become centralized selfish miners and thus have their blocks orphaned. After all, who would choose to reward selfish miners and risk their blockchain being forked?

There are enough miners so that it would be very difficult for them to work together to achieve the maximum TX fee per TX. If 90% of the miners were to only include TXs that include a certain fee but 10% of the miners include all unconfirmed, valid TXs (they can not include more because of the larger block size) then it would be possible to send a 0 fee TX, it would take longer to get confirmed but it would still be free. The result is that the miners have no reason to exclude low/no TX fees.

Basically I'm not against the idea of having a hard fork. We need to plan for long term solution and accept the fact that one day fees will be the one we'll need to rely on to continue to survive. The question is what the side effects are. Will hackers take advantage during the hard fork or ended up a mess considering the size of bitcoin

lets do it now and not in 1 year or so.

A "hard fork" can be planned in advance giving everyone the time to update the client.
Give it some rest. It's not the end of the world. Calm down, get some pills.

Best regards,
ilpirata79

I remain sceptical on any block size increase, because it promotes centralization of nodes. If Gavin's plan is implemented there will be progressively less full nodes being able or willing to participate in the network because bandwidth and storage requirements are too demanding. A non-conditional yearly 50% increase is a very bold figure. It's not even clear if technology will be able keep up with this rate longer term.

If block size increases really can't be circumvented through other measures, they should not be done in a static irreversible step-by-step increase (comparable to coin issuance) but instead in a dynamic way that allows for increases and decreases based on previous usage (comparable to difficulty adjustment). Doing it that way would allow systemic self-regulation, always providing as much bandwidth as necessary but not (much) more than needed. So some healthy competition between transactions (size, fees) remains in place and resources (bandwidth, storage) are much more likely of being used responsibly and not being wasted.

It is necessary to allow more transactions to be included in future if Bitcoin has to be used much more, but for now the blocks are filled only by about 20% in average, so I guess the increase doesnt need to be so huge (+50% every year)

Would not the best solution be a dynamic update?

With gavin suggestions we have that max blocksize will become

2014: 1mb
2015: 1.5mb
2016: 2.25mb
2017: 3.375mb
2018: 5.0625
2019: 7.59375
2020: 11.390625
2021: 17.0859375
2022: 25.62890625
2023: 38.44335937

Would it not be better to have something dynamic? I'm not sure how close we're to the current limit of 7tx/sec, but once that approaches, would it not be advised to increase the max blocksize slightly as to give room for the new demand, and then if demands for transaction bandwidth decreases, the max block size is adjusted accordingly?

Perhaps it could be a good idea to prevent the tiniest transactions on the network as well, and push these off to off-chain payment systems? For example, if youtube implemented bitcoin tips in their system, would it not be better that users could deposit a small amount with them, and then tip youtubers as they saw fit, instead of using the block chain to send tiny transactions all the time?

For example, the tiniest amount allowed to send could be 0.0001 BTC, about 0.05USD with today's prices. Would this help reduce the amount of  transactions currently being distributed on the bitcoin network?

Yes. And maybe an exponential moving average of previous usage.

How would something like this affect the 50% miner centralization control of Bitcoin?

:)

I think this is a good idea but it has other implications as far as network attacks. If no one really knows the size of a block because it is ever adjusting couldn't that be an attack vector?

The max block size is only the maximum, miners may continue to mine 200k blocks if they wish. So, transactions volume may never change. We might have to wait until the next reward halving before we see any real benefits of this fork.

Just because the max block size is larger does not mean that every block (or even any block) will be as large as the max block size. If the miners do not include enough TXs to make the block a larger size then the nodes will not need to use as much bandwidth as they otherwise would, therefore there is little reason why a node that operates today would cease operating tomorrow if the block size were increased tomorrow.

I think having the max block size change based on the last n block sizes would be too complicated and would add an unnecessary level of complexity to the protocol. 

why do you want increase block when the 7 transactions per second is not reach ?
http://btcaudio.tk/live = 0,7-0,9 transactions per second.

It's called vision. It's what some men have that's thinking ahead and not only looking at what they have in front of their nose.

OK, but why is the block size limited ... at the beginning ?  ???

Very good question! I don't have the answer. Maybe for the same reason that IPV4 address space became to small?

the blockchain is so bloated now, is there some way of reducing its size.

anyone got a link to info on the 7 trx per sec limit?

I thought the network limit was more reliant on number of nodes than a limit in the script?

There's work being done on this. If you read the bitcoin foundation post of Gavin where he talks about this proposed fork, he mentions this. Sorry no link.

Current block size limit is 1 Mb. An average transaction is 200-something bytes. One block every ten minutes, i.e. every 600 seconds.

You do the math ;).

Well if this were to be done, then the developers should look at the hardfork wishlist, and implement more stuff from that.
The less forks that we have, the better.
Although I do agree that this needs to be done.

Miners are leaving transactions out of blocks today because the blocks propagate faster (ie, have more odds of being confirmed) if they are <250K.  Odds on losing the block fee exceed the transaction fees available, and the miner leaves the transaction unconfirmed. 

Raising the size of the largest allowed blocks will not change that. 

Do we have an implementation yet of broadcasting only the block header, and then letting the nodes assemble the blocks out of transactions they've already received over the network?  That would reduce miners' disincentives for including transactions, so wouldn't that would be the more immediate means of increasing the number of transactions per block?

I agree that the block size needs to be increased; I'm just saying that increasing the allowed block size won't help if miners still have a financial incentive to limit the actual block size to 250K.

The limit is also written into the protocol. What you are implying is that the block size limit would prevent the average number of TX per second to be more then 7. Under this theory someone could broadcast 20 TX one second then as long as few enough other TX get transmitted they will all get included in the block, however this is not how it works. It is my understanding that the nodes will reject TXs if more then 7 are transmitted in a second

needs to be done.  bitcoin wasn't just built perfectly the first time.  it needs adjustments and this is one of them.

The block size was appropriate for it's early days when there were few transactions, and balanced the resources needed to run a node with maintaining the ability to have a lot of TX per block. 

As bitcoin has evolved into more of a payment method, more transactions will occur every second which  equals more space in each block

What script in the core has a hard limit written into it?

I think the transactions are more limited as to difficulty than any hard line core limit???

The first response was simple math, current blocks mined at X time and it contains Y trans.

So 'difficulty' in creating a new block is the limiting factor, is it not?

If there is a hard limit in the core somewhere, can anyone point out to what part of the core on Github is the file showing any hard limit?

My understanding right now is that the so-called difficulty in mining new blocks is the speed factor?

If 7 tranx a second is the real limit, then why not ease difficulty and let btc hit it's full 21M or whatever limit in bct there is, less difficulty mining should up tranx per second.

At 7 a second it's a 600k daily limit which is way too small.

Global Debit and Branded CC trans in 2012 were 40 Billion Debit cards and 18 Billion credit card trans, so 60 Billion is the global yearly transactions.

BTC at 7 trans a second can do 220 million a year

So to be equal to credit cards it would have to increase trans speed 100 fold, that's why some geeks have said the core needs to be done in Assembly and put on a network of major super computers to get to the level of the global CC system, thousands of low end computers can't compete with super computers and a sleek assembly level system.

So maybe a trusted core network of 10 super computers and the old system gets canned.

Right now btc has no need to try to compete with a network that can do 20 Billion transactions a year live visa/mc

But if btc is to keep growing, it has to do way more than 200M trans a year.

Debit and CC info from

http://www.creditcards.com/credit-card-news/credit-card-industry-facts-personal-debt-statistics-1276.php

As the block subsidy is reduced this will become less of an issue as a higher percentage of total block reward will be from TX fees.

Fore each additional second it takes for a block to propagate there is only ~1/600 chance (maybe more if the difficulty is increasing) that the block will be orphaned because of extra propagation time. If the amount of additional TX fees makes it worth the miners to take this risk then they will include the additional TXs and take the risk of their found block being orphaned

It's about 1 in 600.5001389 chance a block will be found within a second following another. However a block find faster than the network latency does not always result in an orphan - it is not an orphan if the same miner also found the following block.

That is the problem with orphans, they reduce the strength of decentralized mining against attack, by favoring larger miners and discarding proof-of-works that would otherwise strengthen the difficulty. An extreme demonstration of this was just had on testnet after a reset to difficulty 1 vs difficulty 100k hashrate: Even holding 1% of the network hashrate it was impossible to get your block find published, because the largest miner was finding blocks at nearly one per second and building upon their own chain even though they didn't have a majority hashrate nor were they running an "attack" client.

An attacker can enhance the chance of a malicious block acceptance by not including irrelevant transactions. This is in addition to a 51% attack actually becoming a 49.83% attack with a one second delay between legitimate miners. There is already a multisecond delay in pooled mining between the pool software learning of a new block from bitcoin, and pushing it out to miners, and their miner software flushing the work and getting the new block hashing on hardware.

I think is is wise choice.
Fork it!

What's a fork. And what's the difference between forks when it's stiff or flaccid?

Not everyone's a bitcoin MSc Engineer FFS.

I am glad to see that the viewpoint of the dev team has changed from "Well deal with that later" to "We need to do this now, so there is a later".

The industry is evaluating bitcoin for its capabilities and restrictions now, for things they will build "later".

Hats off to Gavin for taking the reigns.  Wish it wasn't such a one man show in this regard.

Any chance someone can begin to manage the development priorities, enhancements, and create a timeline for execution, so there is a "5 year plan" set in stone?

-B-

So, the limit is defined in main.h, line 42.
https://github.com/bitcoin/bitcoin/blob/5505a1b13f75af9f0f6421b42d97c06e079db345/src/main.h#L42

And the test is done at main.cpp at line 727.
https://github.com/bitcoin/bitcoin/blob/3222802ea11053f0dd69c99fc2f33edff554dc17/src/main.cpp#L727

So this looks like a very simple change. 

Is there any way for someone to play sillybuggers right around the transition period?  With the main chain and other chains at different heights, can the client ever be in a state where it's willing to accept larger blocks in one chain, or unwilling to accept larger blocks in one chain, due to the block height of some different chain?

Could anyone lay out exactly what are the risks with the proposed hard fork? Ie. what could go wrong, and what are the percentages it could go wrong (if possible to calculate it).

LOL!  I gotta wonder if that was not one of the ideas that came out of the closed door sessions with the CFR.  I guess we'll never know since Gavin never saw fit to either swear off private conversations or give the community a de-briefing of any which may or may not have happened.  At least that I saw.  A huge percentage of humans lack the capability to conceptualize an exponential function, and people who make it to CFR status understand this deficiency well and deploy it liberally as a weapon.

That said, I find the proposed formula workable insofar as it would not destroy the core concepts of the system.  At these relatively modest rates the system would still be operational under significant attack and it would still be feasible to verify transactions fully by my estimation.  I'm in.

The downside of this modest growth is that it would not come close to solving the 'problem' of giving the system the capacity to serve as an exchange currency.  So, what's the point?  Especially if sidechains or some other logical scaling mechanisms develop.  One way or another, let's run up into the economics of transaction fees to see how they actually work before something as drastic as a hard fork.

The proposed changes to the block size has a goal of keeping up with anticipated TX volume growth over time. You need to remember that the average block size right now is well under 1 MB so even though the max block size is 1 MB, we are really not starting at that size when comparing the max block size in the future to today's block size.

In the event that the block size growth is not able to keep up with TX growth then the protocol could easily be forked again to increase the block size growth

Ya, of course it could.  What could be easier than a simple little hard fork?  Personally I never understood why we didn't do hard forks several times per week.

I'm not sure if this had been mentioned elsewhere but if *malleability* could be resolved then one very simple way to reduce the amount of data per tx is to only put the transaction id's in them (not the actual signed transaction script).

From memory a typical raw tx is 200+ bytes so if we just stored the tx hash (32 bytes) then we have just made nearly a ten-fold improvement in bandwidth usage for blocks (of course if a node doesn't have all the txs in a new block already its memory pool then it would need to request those in order to validate the block).

Note that the tx scripts still need to be stored (until they can be pruned) so this is not a suggestion about "disk storage" but about reducing *bandwidth* (the txs are already being broadcast so they don't really need to be *repeated* in each block as well).

This.  *EXACTLY* this.  I said this three pages ago and the responding silence was deafening.  Come on guys, this is a REALLY good idea, and needs a response. 

What's a hard fork, and what's a soft fork? FFS I've asked this before and no one answered. Can't the bitcoin genius step up to the plate and use this forum to educate instead of joke and berate?

I await...

http://bitcoin.stackexchange.com/questions/9173/what-is-a-hard-fork

http://bitcoin.stackexchange.com/questions/30817/what-is-a-soft-fork

There are serious risks to the miners when Bitcoin is hard forked. There is a possibility that some miners will not accept the fork at first which would result in the miners mining on a what will be a worthless blockchain.

The network should really only be forked when it is absolutely necessary.

this change would require users to check with the nodes on every single transaction on the blockchain. How the blockchain is setup now, a user can download what they think is the blockchain, and easily check each block to make sure no transaction spends the same input, while if the blockchain only contains the TXID of a Tx then someone would not only need to download the blockchain but also connect to what they hope is an honest node to confirm the inputs and outputs of each TX

The transaction hashes (malleability issues aside) mean they don't need to worry about the *honesty* of their peers - either each tx matches or it doesn't. The blockchain hasn't been changed in basic design either and for *normal bitcoin core nodes* that relay txs they will already have (at least most of) the txs for new blocks in their memory pool.

If you are worried about a "brand new node" that needs to catch up then I would suggest that they could be given "full blocks". As stated my goal wasn't to save on disk space (so the blocks would still be *stored* exactly as now). The idea is that for "general block publication" (to nodes that have most if not all relevant txs in their memory pool) there is no need for the tx scripts to be included in the block (saving a lot of bandwidth).

Nodes that "don't relay transactions" (nor keep a memory pool) would be a problem but I think that generally they would be connecting to things like "stratum" servers which could always just send them "complete blocks".

So to restate what your proposal, you are saying that blocks  (when initially propagated) should only contain the TXID of the confirmed transactions in each block and nodes should store the signed message of each TXID in their mem pool.

A new node would need to check each signed TX in order for it to validate that the blockchain is in fact valid.

I am confused as to how the blocks would go from only having a TXID to having the entire signed TX.

Yes - basically the blocks just contain the txids - which can be matched with those in each nodes memory pool (assuming they are present - they may need to "request" txs if they don't already know about them).


That would be part of the "validation" - to illustrate:


So during validation the block is "expanded" by replacing the txids with the actual txs and then the expanded block can be persisted.

if gavin proposes to fork the chain. i propose that he forks it and jumps the max limit to 20mb or more for 2015, and then do the 50% increase a year,
as at the moment the tx per second limits for the next 10 years are proposed by gavin as
2014: 7/sec
2015: 10/sec(rounded down for easy maths, dont knitpick)
2016: 15/sec
2017: 22/sec
2018: 33/sec
2019: 49/sec
2020: 73/sec
2021: 109/sec
2022: 163/sec
2023: 244/sec
2024: 366/sec

366 tx per second is still not competitive enough to cope with visa/mastercard tx/s volume in 10 years.

yet if we start at 20mb in 2015
2015: 140/sec
2016: 230/sec
2017: 345/sec
2018: 517/sec
2019: 775/sec
2020: 1162/sec
2021: 1743/sec
2022: 2614/sec
2023: 3921/sec
2024: 5881/sec

which is more appealing as able to handle large volume.

just remember this is just opening up the potential tx volume and it wont actually bloat the blockchain unless there is actual transactions to fill the limits, meaning in 2015 we may have the potential of handling 140 tx per second even if actual tx average is still less than a dozen (thus giving a nice buffer space to cope with unpredictable growth)

Note that with the "compressed blocks" idea we'd be able to handle 50 txs/sec with the current 1MB limit.

Is that your idea? Have you written an explanation about how it's done, and have others chimed in to verify it's possible? Does Gavin know about that suggestion? Did he comment on it?

Actually I am pretty sure that it was *his idea* called "O(n) blocks" or something like that ??? (I just use the term "compressed blocks" as I think that is more "intuitive"). As stated one major thing that would need to be resolved is "transaction malleability" for this idea to be a "goer" (and see my posts in the previous page for the explanation).

Funnily enough I had *come up with the same idea* (I am using it in my own blockchain design) about six months ago - but I never thought to suggest it for use with Bitcoin at the time.

Its a pretty great idea for me. :) I hope Gavin can read it.

Well this is the GREAT thing about BTC If something fails or it's not working, it can be changed. The new changes will only apply to those who FORKS to the new changed protocol.

The others are left behind, holding a ALT coin.  ;D

I see this as a improvement on something that might fail in future. Those who are not happy, can mine the new ALT coin.  ;)
 

Great decision, enabling more transactions over the network is one of Bitcoins core necessities as the project grows. Especially removing the stupid 7tps limit imposed right now.

Don't forget that as more transactions would be allowed per block it's very likely that if these changes are implemented right now would mean that all broadcast transactions would be immediately included into the very next mined block, this would in turn also SIGNIFICANTLY lower mining fees since miners will want to include as many as possible transactions per block.

Also, it would be easy to hard fork this since you can technically give nodes time to update, for example the new Bitcoin-QT/bitcoind is rolled out and the block change doesn't go into effect for another 6000 blocks. This way there would be time for everyone to update their clients.

And scaling all this at half of Moore's law looks more fair as well to keep the costs of storage down. This would however be even better if combined with a more compressed version of the blockchain.

Perfect change, here's to hoping they will implement it soon.

The thing is we really dont know what will happen next.

I think you're reinventing Matt's fast block relay code.  See:
  https://bitcoinfoundation.org/2014/08/a-bitcoin-backbone/

I actually had thought it was your invention (sorry Matt) - but yes - I do remember hearing about it before.

The real question is do you think it is feasible to do this before the "hard-fork"?

It is already being done, so yes. Optimizations to how transactions or blocks are communicated between peers don't require any sort of fork.

That is great news - I am very supportive of where this is going!

Hi Gavin,

Is there a time schedule for future updates/upgrades or a list with the high priority items for future updates?

Explain it like I'm 5 version:


The size of the "closet" (block) that is "created" (mined) every 10 minutes will be increased so that more "clothes" (transactions) can fit in each "closet" (block).

Of course bigger "closets" (blocks) also need more space to "store" (MB's per block) all those created closets.

This does not necessarily mean that miners will get paid less, but it will be easier for them to include more "clothes" (transactions) into each "closet" (block). Miners will always charge what they want for a transaction, the market will take care of the rest.
=====================================================================

Each block will still reward 25 bitcoins to the miner that generates the block (that continues to lower per halvening as scheduled). The only thing can MIGHT change is how much transaction fee is paid per transaction.

Any time you send a TX, it must be included in a block that is found by the miners. The TX that you create takes up a certain amount of space in the block based on how many addresses you are sending the money to and how many different people sent you the money you are spending.

As it is now there is a 1 MB limit as to how much space each block can hold. This limits the number of transactions to roughly 7 per second as if more transactions are sent there would not be enough space in each block.

The change being proposed is to gradually increase the maximum block size so that more transactions can fit in each confirmed block

The number of tx per second (and the amount of storage required) is limited by two things; block size and block frequency.  We could double tx per second by doubling blocksize or by doubling block frequency.   Or we could do both and quadruple it.  Of course if we doubled block frequency we'd need to halve block rewards to stay on the same money supply curve.

A lot of the motivation for the 1MB limit was a fear that if it weren't limited we'd have people building gigantic blocks just to clog up the system.  If someone with major hashing power started building giant blocks every time he got a block, he  could DoS the system just by making the block chain too large for most people to store. 

A lot of the motivation for the ten-minute intervals was limiting the amount of storage devoted to block headers.

Increasing block frequency would be beyond a bad idea. It would increase the number of orphaned blocks and reduce the security of the network. It would also do nothing to address the size of the total blockchain.

IMO if you are looking for a shorter block time you should look at the many failed altcoins that have much shorter block times

Has this actually been set in stone or is Gavin just pondering ideas?

I am trying to get consensus. The process will look like:

Get rough consensus. I need to write some code to find out what size blocks the current code can handle, but other than that I think we're close to rough consensus on the approach.

Note: Getting consensus that we actually need to change something NOW will be harder; it will be much easier to get consensus after we hit the 1MB blocksize limit and transaction fees spike up. It would be lovely to avoid that panic/pain.

Implement the change / Write a BIP (these happen at about the same time).

Submit a pull request, after code is reviewed pull it into the reference implementation.

... wait until there is a release containing the change...

... wait until supermajority of miners have upgraded to the new release...

Voila, the possibility of bigger blocks.

Have you run any tests on the testnet (or a scamcoin/altcoin) to get some kind of idea as to just how much TX fees will increase when the 1 MB block size limit has reached? I would have the same question with how TX fees would change after the block size is increased?

I think this would be valuable evidence to provide to help your argument to increase the block size. I think it is more or less agreed upon that the block size limit will eventually be reached as it stands, however I think the disagreement is what effects both not raising the limit and raising the limit will have on the network and on TX fees

Is there really any disagreement? Everybody I have talked with believes that transaction fees will rise if Bitcoin is successful and the 1MB limit is kept.

How much we won't know-- that depends on how much demand for transactions moves somewhere else (fiat currency, altcoin, or some off-blockchain solution).

There is a small minority of people who believe that it would be BETTER if transactions moved to fiat currency, an altcoin, or some more-centralized off-blockchain solution. I strongly disagree.

Bitcoin has been marketed as a payment network with little to no transaction fees, from the start. I think it is a good idea to raise the block size.

With the block size increasing, and the block relay code being merged. Miners will not have to worry about the block size taking too long to propogate and being beaten. So the incentive is there to include as many transactions as possible in that block and collect miners fee even if it is small amount. I think this is good for consumers, because it will keep transaction fees at a minimum.

I think the disagreement lies within what will happen if we raise the block limit. I think some people think there will be more no TX fee TXs included in blocks because because there would be more room for these TXs in each block. The argument is that this is bad because the miners would receive less total TX fees which will become a larger portion of their "income" as the block subsidy declines over time. I would disagree because the miners would still be doing the same amount of work to confirm a TX in a block and there would be nothing that would force miners to include no TX fee TXs period, regardless of max block size.

I think there are a very small subset of applications when off-blockchain transactions would be better, primarily when an off-chain transaction would require a very small amount of additional risk to the buyer (for example someone who already trusts  an airline enough to prepay for an airline ticket could deposit funds into an account for pay for in-flight wifi, or someone who trusts a retail store to not sell faulty products to deposit funds in an account to pay for a number of transactions with the retail store, or some other similar situation).

If we move primarily to off-chain solutions that are not store specific (or band/company specific) (and are very similar to coinbase) then we have essentially invented a new version of paypal.

http://bitcoinist.net/the-optimal-block-size/

I think that miners will eventually be supported by TX fees, but right now our TX fee structure is probably wrong for it.

TX fees are what we pay the miners to maintain security on the chain.  They do this mainly by making a major investment in hashing power.  When Bitcoin got started the resources required to do mining were mainly bandwidth and storage space for the blockchain, because CPU power was assumed to be widely if unevenly distributed. Accordingly the tx fees were set according to the amount of bandwidth and storage space a tx required -- that is, the transaction size in bits, because the cost of mining was assumed at the time to be proportional to bandwidth and storage required.  

But ASICs changed the world.  The bandwidth and storage space required to do mining is now essentially irrelevant as regards the expense of mining.  People with the bandwidth and storage can't mine effectively in competition with ASIC farms.  The major expense of mining is now dedicated hashing hardware, not bandwidth or storage.  If we want to charge what a transaction costs the network to secure, TX size is no longer an accurate measure of anything.  

Ultimately, what secures the blockchain now is sheer dedicated hashing hardware.  The question is how much of it we want to buy -- indeed, how much we will economically cause to be manufactured -- in order to secure the chain.

I think that we need security proportional to the value of the transactions secured.  Therefore if we're going to charge tx fees for security, we need tx fees proportional to the amount of bitcoin sent.  The charge for tx size in bits (bandwidth and storage) should be high enough to keep "dust" out of the chain, but if we want security proportional to the amount secured, the main source of tx fees should probably be charged for the tx size measured in bitcoins, not in bits.

What is the current status on this, and estimated implementation date?

-B-

Within the last year I sensed a recognition among the more informed people trying to have Bitcoin support the world's exchange economy was fairly incompatible with having it serve as a reliable monetary medium free of external controls.  Such people may be a 'small minority' at this point, but I don't think it's fair to weigh everyone's opinion equally or if it is fair, it is doomed to failure.  I'd call your attention to the number of relatively new people who will authoritatively produce utterly wrong information on the Multibit sticky thread for instance.

I like your exponential trickery actually.  It will give me plenty of time to execute my exit strategy.

You can't get too crazy increasing fees for large transactions. People using a system for large transactions will simply use another system. The money transfer business is huge and competitive. If you make the fee proportional to the amount you're sending someone will figure out a way to be cheaper. TransferWise is a good example of a competitor that is undercutting the market right now by only charging 0.5% to send any amount and will exchange to different currencies at no additional cost. You give Bitcoin a large transfer fee and top it off with an exchange fee you will watch big transfers move elsewhere.

For my business I pay around $10 for a Bitcoin transaction and am happy to do it (else I'd set my bitcoind more normally.)  This value is less than half what I would pay for a wire and Bitcoin is vastly less hassle and more reliable because so far it is unencumbered by regulatory issues and bank cartels, and not dependent on those who are by necessity under the thumb of said regulators (e.g., Google, etc.)

If I could pay transfer agents I would be happy to do so, and would be very inclined to run one myself full time for my own use if nothing else, and probably off-shore.  If I could break even on it I'd run a dedicated transfer server to do it...and configure a router to actually make the deployment a thing of value to the ecosystem which I only did in the very early days due to security issues.  When I first read up on Bitcoin I was sure I saw reference to transfer fees, and thought found it again some time later.  Last I looked I could find no reference.  Sucked down the memory hole perhaps, or I'm remembering wrong.  The reason I thought I read it is because I considered transfers (bitcoin full) much more important than transaction fees (mining.)  And the reason for this is that I figured that mining could easily shift jurisdictionally while transfer agents would have to be more available to the end-user who may be trying to operate in an environment where controls might be more tight.

Got a poll going and early results are interesting. https://bitcointalk.org/index.php?topic=827209.0
So far, $2 is not a popular fee for a transaction, and over half the respondents think transactions should cost 1 cent or less.

I don't know that it's fair to say Bitcoin is unencumbered by regulatory issues. Bitcoin exchanges must be compliant or we will end up with another BitInstant issue. Exchanging for fiat will be necessary for the foreseeable future. Bitcoin is the worlds first personal transfer agent. That's the beauty of it. I can send money to my uncle across the ocean in Germany as easily as if he were across the street and the records are maintained by an enormous very secure system. Of course I can do that without Bitcoin but it's not as fast and it's not as cheap. Bitcoin needs to stay cheap at least for now. It must capture a large user base before any associated big increases in costs occur. That was the original plan after all. Reward subsidies slowly taper off and fees take over. That process should happen naturally per the original design, not overnight.

Exchanges are a totally different thing than Bitcoin, and all of the (many) problems I've had in exchange-land have been 100% on the fiat side while the Bitcoin aspect of things has been flawless.

It's not Bitcoin's place to correct hassles with fiat systems, but it is distinctly the place of those steering the Bitcoin solution and network in such a way that such problems will be avoided.  Laying prone on ones back and exposing the jugular in hopes that the regulators will feel pity or be shamed into leaving the solution alone or whatever is a stupid strategy.  At least for those who believe as I do that Bitcoin's strength lays with it's ability to avoid some of these hassles.  OTOH, if one believes that the lack of oversight and control by the authorities is dangerous and a negative, or a potential threat to other important and valued systems then forming Bitcoin into a solution which makes it likely that it will be able to be more controlled does make sense.  These arguments are 100% valid ones, but I don't happen to agree with them.

I do see it as inevitable that if/when the solution grows to a point where most of the infrastructure is provided by corporate entities then control by the authorities will be relatively easy.  Also, of course, that if Bitcoin can grow into a broadly used solution for buying trinkets on the global and persistent blockchain it will be very unlikely that smaller and independent entities will be represented as infrastructure providers.  'Capturing a large user base' is, to me, not a good thing unless the user base is carefully chosen to be people who are less likely to aggravate problems I foresee.

If I were devising an attack on Bitcoin, I would lull the solution into outgrowing it's capacity to operate in the ways it did in the early days then put the hammer down with vigor and with good coordination (since we still have a multi-polar world.)  I think I outlined this strategy nearly three years ago.  What has happened, and what I did not predict, is that it has been damned difficult to NOT form off-chain solutions, and the appeal has been weighted toward those who have money (and want more of it) rather than those with a sweet-tooth for Skittles.  So, pressure on the transaction rate is much less than I would have anticipated at the current valuations and popularity.  Delightful to me, but much to the chagrin of other's in the community I'm sure :)

It would be quite easy to get a 'cash back' for using Bitcoin.  The intel value coming off of the solution probably exceeds the value of being able to scan people's 'private' e-mail and spy on their surfing habits.  I don't doubt for a minute that a majority of people would 'jump eeen it.'  Especially now in the late 2014 makeup of the community.

I'll go check out the link now.

What I am always wondering, when I read about what the transaction fees should be:
Are you guys proposing a standard fee, that is mandatory?

For anyone wanting to know more:










Scalability targets

VISA handles on average around 2,000 transactions per second (tps), so call it a daily peak rate of 47,000 tps. [1]

PayPal, in contrast, handles around 4 million transactions per day for an average of 46 tps or a probably peak rate of 100 tps.

Let's take 4,000 tps as starting goal. Obviously if we want Bitcoin to scale to all economic transactions worldwide, including cash, it'd be a lot higher than that, perhaps more in the region of a few hundred thousand tps. And the need to be able to withstand DoS attacks (which VISA does not have to deal with) implies we would want to scale far beyond the standard peak rates. Still, picking a target let us do some basic calculations even if it's a little arbitrary.

Current bottlenecks

Today the Bitcoin network is restricted to a sustained rate of 7 tps due to the bitcoin protocol restricting block sizes to 1MB.

CPU

The protocol has two parts. Nodes send "inv" messages to other nodes telling them they have a new transaction. If the receiving node doesn't have that transaction it requests it with a getdata.

The big cost is the crypto and block chain lookups involved with verifying the transaction. Verifying a transaction means some hashing and some ECDSA signature verifications. RIPEMD-160 runs at 106 megabytes/sec (call it 100 for simplicity) and SHA256 is about the same. So hashing 1 megabyte should take around 10 milliseconds and hashing 1 kilobyte would take 0.01 milliseconds - fast enough that we can ignore it.

Bitcoin is currently able (with a couple of simple optimizations that are prototyped but not merged yet) to perform around 8000 signature verifications per second on an quad core Intel Core i7-2670QM 2.2Ghz processor. The average number of inputs per transaction is around 2, so we must halve the rate. This means 4000 tps is easily achievable CPU-wise with a single fairly mainstream CPU.

As we can see, this means as long as Bitcoin nodes are allowed to max out at least 4 cores of the machines they run on, we will not run out of CPU capacity for signature checking unless Bitcoin is handling 100 times as much traffic as PayPal. As of late 2012 the network is handling 0.5 transactions/second, so even assuming enormous growth in popularity we will not reach this level for a long time.

Of course Bitcoin does other things beyond signature checking, most obviously, managing the database. We use LevelDB which does the bulk of the heavy lifting on a separate thread, and is capable of very high read/write loads. Overall Bitcoin's CPU usage is dominated by ECDSA.

Network

Let's assume an average rate of 2000tps, so just VISA. Transactions vary in size from about 0.2 kilobytes to over 1 kilobyte, but it's averaging half a kilobyte today.

That means that you need to keep up with around 8 megabits/second of transaction data (2000tps * 512 bytes) / 1024 bytes in a kilobyte / 1024 kilobytes in a megabyte = 0.97 megabytes per second * 8 = 7.8 megabits/second.

This sort of bandwidth is already common for even residential connections today, and is certainly at the low end of what colocation providers would expect to provide you with.

When blocks are solved, the current protocol will send the transactions again, even if a peer has already seen it at broadcast time. Fixing this to make blocks just list of hashes would resolve the issue and make the bandwidth needed for block broadcast negligable. So whilst this optimization isn't fully implemented today, we do not consider block transmission bandwidth here.

Storage

At very high transaction rates each block can be over half a gigabyte in size.

It is not required for most fully validating nodes to store the entire chain. In Satoshi's paper he describes "pruning", a way to delete unnecessary data about transactions that are fully spent. This reduces the amount of data that is needed for a fully validating node to be only the size of the current unspent output size, plus some additional data that is needed to handle re-orgs. As of October 2012 (block 203258) there have been 7,979,231 transactions, however the size of the unspent output set is less than 100MiB, which is small enough to easily fit in RAM for even quite old computers.

Only a small number of archival nodes need to store the full chain going back to the genesis block. These nodes can be used to bootstrap new fully validating nodes from scratch but are otherwise unnecessary.

The primary limiting factor in Bitcoin's performance is disk seeks once the unspent transaction output set stops fitting in memory. It is quite possible that the set will always fit in memory on dedicated server class machines, if hardware advances faster than Bitcoin usage does.

Optimizations

The description above applies to the current software with only minor optimizations assumed (the type that can and have been done by one man in a few weeks).

However there is potential for even greater optimizations to be made in future, at the cost of some additional complexity.

CPU

Pieter Wuille has implemented a custom verifier tuned for secp256k1 that can go beyond 20,000 signature verifications per second. It would require careful review by professional cryptographers to gain as much confidence as OpenSSL, but this can easily halve CPU load.

Algorithms exist to accelerate batch verification over elliptic curve signatures. This means if there are several inputs that are signing with the same key, it's possible to check their signatures simultaneously for another 9x speedup. This is a somewhat more complex implementation, however, it can work with existing signatures (clients don't need upgrading).

Newly developed digital signature algorithms, like ed25519 have extremely efficient software implementations that can reach speeds of nearly 80,000 verifications per second, even on an old Westmere CPU. That is a 10x improvement over secp256k1, and most likely is even higher on more modern CPUs. Supporting this in Bitcoin would mean a chain fork. This ECC algorithm has also been shown to be easily accelerated using GPUs, yielding scalar point multiplication times of less than a microsecond (i.e. a million point multiplications per second).

At these speeds it is likely that disk and memory bandwidth would become the primary limiting factor, rather than signature checking.

Simplified payment verification

It's possible to build a Bitcoin implementation that does not verify everything, but instead relies on either connecting to a trusted node, or puts its faith in high difficulty as a proxy for proof of validity. bitcoinj is an implementation of this mode.

In Simplified Payment Verification (SPV) mode, named after the section of Satoshi's paper that describes it, clients connect to an arbitrary full node and download only the block headers. They verify the chain headers connect together correctly and that the difficulty is high enough. They then request transactions matching particular patterns from the remote node (ie, payments to your addresses), which provides copies of those transactions along with a Merkle branch linking them to the block in which they appeared. This exploits the Merkle tree structure to allow proof of inclusion without needing the full contents of the block.

As a further optimization, block headers that are buried sufficiently deep can be thrown away after some time (eg, you only really need to store say 5000 blocks).

The level of difficulty required to obtain confidence the remote node is not feeding you fictional transactions depends on your threat model. If you are connecting to a node that is known to be reliable, the difficulty doesn't matter. If you want to pick a random node, the cost for an attacker to mine a block sequence containing a bogus transaction should be higher than the value to be obtained by defrauding you. By changing how deeply buried the block must be, you can trade off confirmation time vs cost of an attack.

Programs implementing this approach can have fixed storage/network overhead in the null case of no usage, and resource usage proportional to received/sent transactions.

I understand and sympathize with your viewpoint. I even agree with it but you and I don't matter. The lead dev works exclusively for big business. TBF is controlled by business and they payed him $200k last year reported in the TBF tax return. Increasing the number of users and selling coin for new money (fiat) is their business model. The profit model is the reason for life to a business. They could care less about libertarian ideals or ending government financial system abuse. They need Bitcoin to grow to make money. This thread is about providing Bitcoin with the ability to grow. The Bitcoin that you and I want is not the one that exists or will exist in the future and we can't change it.

Please stop trolling. I think what I think and do what I do because I want the Bitcoin Project to be even more wildly successful.

If I was motivated by greed I would have a much higher salary. And lots of stock options.

The majority of Bitcoin users here want transaction fees less than a penny; I want them to be as low as practical. The only way to get there is to increase the block size.

I'm not trolling that's what I really believe. You are being paid by an organization that has proven its not responsive to the people and it makes really bad decisions.

I don't think your motivated by greed I think your controlled by business.

Increasing the block size allows an increase in the number of transactions. Do you disagree that this favors increased business adoption? Aren't you the one that continuously calls Bitcoin expermental and advises people to only invest what they can afford to lose? How will increasing adoption favor a system in Beta that shouldn't be trusted?

I don't trust Bitcoin Foundation, and I also want Bitcoin to scale up because that's the only way it can survive.

There are 7 billion people in the world, and with a 1 MB block size limit, it means everybody on the planet is allowed to use Bitcoin once every 33 years.

That's never going to happen - if Bitcoin transactions stay rationed, then it will die because everybody will switch to a better currency.

Of course I agree with increased adoption at the proper rate. I also don't believe Mr. Andresen is a bad person. I just believe big business has the ability to move projects in a direction they see as favorable to them before its ready and present ideas for implementation to intelligent people in a convincing manner.  

You know what the proper rate is? Looking forward to seeing your paper demonstrating your solution to the economic calculation problem.

Sure, I accept this as a possibility.

What's the best way to combat it?

Spoiler alert: it's not demanding a halt to progress.

There is one valid concern regarding allowing the transaction rate to increase - bandwidth in the network is donated, not paid for. More transactions on the network increase the resource consumption of volunteers who operate relay nodes without providing them with any corresponding revenue.

So if you want Bitcoin to grow sustainably fix that problem instead of demanding the transaction rationing problem remain unfixed.

Are we, or should I say, is the lead scientist ready to say Bitcoin is no longer expermental and retract the statement, "only risk what you can afford to lose"? I wouldn't pretend to know all of the shortcomings of the system that the lead scientist knows. Just the ones I know about have nearly made me exchange my investment in several times. I usually blindly follow the recommendations and word of the "experts" but the group that controls the experts have made me question their ability. I do, however, still trust the word of Mr. Andresen. If he tells me that I can trust the system explicitly and no longer have to be concerned that even more money from the great unformed masses can be lost in the event of a failure I will believe him. Again, this isn't about my ability to make changes. It's about trusting the group making them.

"Only invest what you can afford to lose" applies just as well to any complete technology as it does to something that's still in beta. 

Remember, Bitcoin is the initial implementation of a protocol.  Even if Bitcoin is a mature technology and no longer experimental, you should still invest only what you can afford to lose, because some other implementation of the protocol (yes, an altcoin) may eventually be the one that businesses settle on as being friendlier to their interests. 

I would like to hear Satoshi's opinion on this proposal.

I somehow doubt he is going to provide that - there seems to be a few divided opinions about *what is best* for the future but certainly I think nearly all of us can agree that 7tps is not what we want to be saying about Bitcoin in a few years time.

Will this cause any disruptions to existing Joe users coins or transactions?

This is only a concern for those running *full nodes* really (which is no *average Joe*) - so Joe is pretty much *fine*.

I know who you are and I respect your opinion. Do you believe only knowledgable well versed investors are being indoctrinated into Bitcoin? How can we ask even more innocents to buy into a system that they see as a cheap version of a company they trust like Western Union without making it as hardy? Do you believe Hal Finney or Satoshi would have agreed with the rapid spread of Bitcoin without developing solid solutions to issues first? Do you feel this is the solid solution that should be next on the agenda? This has been discussed for a very long time, why is it so important to do it now?


Are you saying this might not even provide the desired effect? A stepped periodic increase is proposed, is that the right way to go?

I also don't care much about 'libertarian ideals or ending government financial system abuse'.  I use USD for 99.9% of my economic activity and am reasonably happy with it as it works fine.  For the 0.1% of things it doesn't work well for I appreciate having options.  And again, am willing to pay well for.

The defining characteristic of government backed fiat monetary solutions is that they have the power of the court system behind them.  This is usually more of a blessing than a curse which is why they are most useful to me.  Bitcoin's original design made it useful without support from the court system support which makes it useful in cases where this support is more of a hindrance than a help, and it also made Bitcoin it a compelling backup solution to fiat.

One of the main problems with fiat have to do with financial services industry meddling at the legislative and judiciary level.  There has never been any love lost between me and TBF and the primary reason is that I always sensed that TBF would usher in the same problems to Bitcoin that the various financial services lobbies present for fiat.

The kinds of value proposition that Bitcoin offers to me in it's present (prototype) stage is huge, and there is a vast pool of individuals and their wealth out there who could leverage the solution in it's present form but do not for various reason.  Simply appealing to this market alone argues for a huge net benefit to society and vastly increased valuations over today's numbers.

there is only one satoshi, and it ain't gavin...  8) so why should I care  :P

Gavin basically took over satoshis spot, so I think a lot of people listen to him (as we should) we shouldn't follow him like blind sheep, but do what we have always done, look at what needs to be done, discuss the pros and cons and then go forward. Its not like Gavin makes all the decisions, hes the core developer lead (I think thats his title). He knows his shit and I would listen to him.

A foundation is an integral part of a house.  Just because on rarely sees it and it does not keep the rain off does not mean that it is not 'being used.'  Indeed, it is probably the most important aspect of a house system since everything else would collapse and fail without it.

Just because every individual's Skittles purchase is not transmitted around the world within seconds and becomes part of a permanent record on multiple storage systems would not necessarily mean that Bitcoin, when used as a foundation upon which other systems are built, would not be 'being used.'  Quite the opposite really.

Not only that, but the foundation of a building structure often derives various benefits and protections by the structure itself.  For instance, those living in the structure take pains to make sure that water flows and pests don't threaten the foundation because it would, in turn, threaten the whole house.

As far as I'm concerned a network of various kinds of off-chain solutions based on a solid foundation is not only about the only chance that Bitcoin has for long-term survival, but also by far the best way to achieve a robust and flexible ecosystem which can adapted to a variety of threats and distributes the benefits to the largest number of end-users.

This is an interesting post.  And it conveys one major side of the argument.  For those who TL;DR .....

"Bitcoin doesn't have to do faster transaction times.  Bitcoin is a foundation which can be built on top of.  And a foundation needs to be stable."

My response:  The general public doesn't know that, and is looking at Bitcoin itself to perform these functions.  Then again, there could be a "Visa" for Bitcoin.  After all ... Visa is not the US Dollar.   Visa is a company providing services on a layer above the US Dollar. And it is Visa that is processing 2,000 transactions per second. So there we have a perfect example.

But does that mean Bitcoin itself shouldn't be enhanced?  That's really the question.  If a service layer appeared which provided 2,000 Bitcoin transactions per second, would there be "too much risk" for them to stay in business, with the sometimes 1 hour wait for 6 confirmations?  In the end, that really is the question.  Can a service layer exist on top of bitcoin that meets this need, and still function effectively with the slow speed of Bitcoin itself?  If the answer is yes, then you're right.  No point in messing with the 'foundation'.  If the answer is that slow Bitcoin speed creates extensive risk for any service layer hoping to to 2,000 transactions "off blockchain" .... then Bitcoin needs to be enhanced.

Andreas A. always comments that this is the first programmable money.  Its able to evolve.  Unlike fiat.  So do we make it like fiat and refuse to evolve it?  Or do we take advantage of its programmable qualities?  Obviously change introduces risk of bugs, hacks, etc.  

As for the public currently "expecting Bitcoin itself to do all this stuff" ... we would need to make sure that the "Visa" analogy above is introduced into the public conversation about Bitcoin.  Assuming its a valid analogy.  The fact that "What Bitcoin can't do, can be done as a service layer on top of it"... is just a public education thing.  

The more adventurous side of me says:  Enhance Bitcoin. Make it fucking awesome(r). I think its silly to assume it'll never change over the next hundred years....

-B-

I've voiced modest (for me) negativity about certain fairly valuable of the developments, but mostly because I am somewhat allergic to complexity.  Ultimately I DO favor developments which can further Bitcon's usefulness in a mediation or backing capacity.  Specifically those which allow providers to pass on the counterparty-free aspects of Bitcoin to their clients and use it in their interactions with one another.  Fortunately there has been some good work in these areas (e.g, p2sh) in addition to the talking paperclip garbage that gets most users and some of our dear friends in the development community all aroused.

The win from successfully attacking Bitcoin is pretty big so there are many skilled people working on the problem and the more features Bitcoin has the less defensible it is.  Mostly being blindsided by some attack mode which was not thought of, and permutations of such attacks grow exponentially with increasing complexity.

To me Bitcoin's biggest strengths are exactly those which bother most people.  The 'batch mode' aspect with highly variable block times, and the tiny messaging size and volumes make it a fiendishly difficult system to mount an enduring attack on (from the infrastructure perspective which is the playing field of state regulators...particularly the U.S. ones.)  Also, it really is a very simple system at the end of the day and this makes it very likely that most realistic attacks would be thwarted quite quickly because the solution would (and could) adapt.  All of these things things could go out the window pretty readily if the solution balloons and/or tries to fill a niche which is at variance with it's native design properties (e.g., near real-time behavior necessary for buying coffee and the like.)

I agree. I think a lot of people have followed satoshi like a religion and this is a liability to Bitcoin. I don't think the same will be true with Gavin.

I think what he is doing is trying to get a conscious of what the community and Bitcoin stakeholders think would be best instead of trying to get the code changed without any input from anyone else

So assuming some sort of hard fork will happen here. What timeframe are we looking at?

Ideally the software version which enables scaling should be available a long time before older versions are incompatible, 6 months or even a year, to ensure as many nodes as possible have upgraded before the changes take effect.

So this is still pie in the sky stuff? probably a year off, or something like that?

Yes, but the pie is falling closer to our faces while time is passing and volumes climb steadily. This could have been done in 2012 with 3 years delay, or 2013 with 2 years delay...

A hard-fork, where nearly everyone has upgraded first, is a big fat non-event, like January 2000 after the Y2K changes.

WWNSD?

What would Nick Szabo do?

How exactly would this be done? Where are these transactions coming from? Could this "bloating" attack be detected and these blocks rejected?

It would be better to prevent this some other way and remove the limit entirely.

This is absolutely ridiculous, your logic is that making bitcoin more widely available for business in general is a bad thing? Supporting more transactions is a bad thing? A growing community is a bad thing? Having bitcoin successful is a bad thing?

As long as the protocol maintains it's decentralization no external businesses can influence the protocol in any bad way. Read up how all this works and then get back and reply.

This has already been addressed by Gavins original post. Maximum Block size would for example grow 50% per year to allow for more transactions in each block, per year, while still keeping storage costs relatively low. A totally unrestricted block size has never been spoken about.

I meant how would the attack be done...

I just worry about the negative impact when the hard fork is taking place especially put into consideration the size of network we are having right now. I mean what if somebody plans a out scheme that manipulates the network during the switch over. But then if we think again, if we don't do it now, then the question is when are we going to do it. As the network grows there can never be the right time.... and we really need to plan, prepare and anticipate for the future.

It's a simple matter of having the miner send one (or more) of his unspent txouts to a new txout -- which he also controls, of course.  He can even put in a generous tx fee -- because he's the miner and he'll collect it.  They won't cost him anything even if another miner gets the block.  The other  miner hasn't heard about them yet (because the guy bloating blocks didn't broadcast them), hence the attacker won't even owe any tx fees. 

So, yes, in principle a miner can bloat a block with as many bogus transactions as he wants, it won't cost him a darn thing to do so beyond the possibility that his huge block broadcasts more slowly and gets orphaned, and there's really not much anybody can do to stop him. 

K.I.S.S. = Keep It Stupidly Simple, leads to the Moon and beyond...

I think investing is different from daily use. If the only users were speculators I wouldn't have an issue with them losing everything. If you invest in junk bonds and lose it all it's your fault. The altcoins don't have much of an economy. Those are really investments (so to speak) and their users are out for a quick return. Some of the altcoins are trying new things and might have the ability to overtake Bitcoin while being more stable and safe. In that case, I hope they do leave Bitcoin. I seriously doubt big business, at this point, will jump ship and attach to an altcoin with no name recognition and no established economy.

I know it's impossible to see many problems before they happen. Some issues can be seen ahead of time and corrected. For the most part the dev team has corrected the issues quickly. Sometimes crooks can use real systemic issues as an excuse to steal as Karpeles did with transaction malleability. Is the system so well prepared now that we can scale up and invite even more use and possibly more loss until there's no one left on the earth that's willing to trust Bitcoin?

It's an easy decision for businesses to accept another payment method. It's especially easy when companies like Coinbase are offering the first million dollars of exchanges to fiat for free. Users are a different story. Users need to trust the system and benefit from it. I know low fees are a benefit and this will help. Should the system be throttled limiting the amount of new entry until it's ready for prime time, is it ready now or is there no way to know until it's ramped up? Ever increasing use means ever increasing losses when failure happens. I would hate to be the lead dev knowing I had this huge experimental market sitting on my shoulders. I'm really not trying to be a prick. I'm just giving you food for thought. Mr. Andresen likes to reach out to the community for consensus and that's a good thing. Maybe the word community to him means only the dev team. In that case, he should really just send out an email instead.

by reading this post I realized that most of you are against competing currencies... if you could kill the king$ you would, just because you have high stakes in btc... But the great wise and smart speculators will all know your little plan before you are even born. Why? they are so basic, make btc the only global currency, and you, first time hoarders the new master of the Earth... you really believe it would be that simple...  ::) Long Live the Alt. Btc must stay unforked. the speculators, again will find its right place... to extract the maximum value of it. by learning to code you made a trade off. You can't escape the consequences of this choice.

Edit: forking would be the greatest thing to happen to the alts since... well... bitcoin.

If this thread needed more conjecture I would provide it(and in a more amusing way).

I have seen your posts and you do troll. I could go back to a thread from something and post your quote where you admit that you troll for the fun of it. You treated me badly before in a thread from the past and it is whatever honestly.


Bitcoin will need to adapt and change. I fully agree with Gavin after reading more into his posts and more on the bitcoinfoundation site. It is easy for everyone here to criticize something when they aren't even in charge of more than a few hundred K per year.

I personally Forecast/Plan for 2 production facilities and the yearly total of production is $80,000,000 to $150,000,000(just giving a range real number is in there). Supply and Demand is KING for what I do. As a Forecaster I can see Bitcoin needs this change because all signs point to there being a higher demand for transactions sometime soon, therefore supply of transactions will increase by X% as demand grows. On the supply slide of things you can then infer that transactions will grow larger in size and eventually hit a point where it is bigger than 1 MB blocks, meaning fees will need to be higher. It is not intended for fees to be so high early on, that comes later. It is a simple concept and if it is wrong there isn't exactly any consequences as it can be changed to something else that would better suit it.

Bitcoin Protocol is largely correct in many areas, other areas get improved, and the rest of the slack will be taken up by something else or another coin. Bitcoin cannot be everything any anything at the same time. Focusing on what Bitcoin does best is what Gavin is talking about for this hard fork. The main principle that wider adoption will come from ensuring fees stay low is key here. Especially since the fees are a direct result of reward + transaction volume(size and amount). So if there are too many transactions going through that it goes over 1MB consistently only the higher value fees will be taken which makes fees go up in price.

tada the protocol already found the answer itself... no need for fork. Who said the most precious numbers were cheap to transact? use an alt for your tipping.

edit: you can put a k for thousand and a M for millions... but I don't think you need to learn the next letters... even in your fantasies...

When did this turn into a discussion about TBF, Gavins credibility and such?
This is about Network Scalability. Gavin is right, and you know that he is.

response from Gavins AMA today


estimates on timeframe suggest Q2 next year at the earliest.

I don't think a planned fork would make the network any more vulnerable to a potential attack then a time when the network is not about to get hard-forked. I would even argue that the network would be slightly more secure during this time as many people would be paying very close attention to the network and various aspects about the network

i like this hardfork idea

If a hard fork is inevitable, lets just embrace it. We should give BTC protocol a chance to improve itself. Just like we have Html 5 and CSS 3 after Html 4 and CSS2.

Probably THE most critical thing would be predictability, and the set-in-stone increase in transaction rate achieves that.  Without predictability it would be much less easy to justify investments in infrastructure among other forms of planning and it would likely set the solution back a fair bit.  So, hats off to Gavin on this thing at least.  (No shit.)

I still don't understand why, if the goal is to support the world's beings with a nearly free (in monetary terms) solution to their economic exchange needs, the expansion rate is so low.  It makes me suspicious that there is something else going on...but then I'm a naturally suspicious guy.  I'd take a long hard look at the deltas which make 1.0, especially with the likes of Mike hanging around.  Maybe it's just a matter of getting people used to hard forks the solution can be more easily modified at will (or on demand) going forward.

I would strongly agree with this. It is unquestionable that the block size will need to be increased in order for Bitcoin to facilitate the number of transactions it would likely see when it becomes successful. If the protocol is forked multiple times then uncertainty would be caused

if they fork once they will fork twice...  >:(

No, that was me, and I still say you were trolling first in that thread.  However, in this thread, I agree with you.

If you don't like that, then you need to get a time machine and go back in time to stop them from forking the first time.

It's funny how none of you want to accept the existence of alts, and how they could be integrated in the p2p payment system... but nooo, you want your precious bitcoin to take over everything, including alt... interesting.

You cannot change that if forking is what they do.  >:(

what do you mean no that was you? The thread I am referencing is something from months back and I don't think I ever quoted you on anything but I may be mistaken because I am not going to take the time to search through every post I ever made. But I am pretty sure I have never said anything to you.

Actually... M is a 1,000 and MM is a 1,000 x 1,000, or 1,000,000. When speaking of financials($) that is one of the most correct ways of doing it that is universally understood in the plant of Earth. It appears in all popular formats including banking statements, IPO releases from companies, stock indexes, most financial documents, ETC....

"M" should be be used with numbers that are related with intangible and conceptual subjects like money, time, and counting. The "k" is related to the "M"(always a lower-case k) which is the abbreviation for kilo-. 'k' abbreviation should be used with things that are tangible and physical, like distance and weight.

Confusion comes from a former symbol abbreviation of an "M" with an overstrike or overbar. The overbar means that the mille unit (1,000) is multiplied again by 1,000 because MM = M * M in math. A number followed by an M with an overstrike then means that the preceding number is multiplied by 1,000,000.

Since it is very difficult to create this symbol and most people do not know keyboard shortcuts or how to make it, it is hardly ever seen and is improperly abbreviated as a single "M" instead of the proper "MM".
This grammar rule is not very well known outside the financial world and will often be used incorrectly and the slang of "k" for thousand is often used even by venerated publications such as the New York Times and the Wall Street Journal. 

So I notice your message under your name says you are trolling, but you actually thought that you were right so you were not trolling in this scenario, just uninformed.

Finally good news, even Satoshi told the 1MB limit is temporary.

But easier would be double maxblocksize every block reward halving, to make Bitcoin simple...

50 BTC = 1 MB
25 BTC = 2 MB
12.5 BTC = 4 MB

and so on.

orly?

I can point to any number of formally adopted international standards adopted by accredited standards organizations which are unanimous on the SI system of prefixes. As a serious question, can you point to the same for your financial-based prefix system you describe above?

Gavin has made a *lot* of insinuations lately that he is somewhat alone in his views on what to do with the Protocol.

He constantly mentions that the "other core devs" don't agree with him on much.

Who are these brilliant scholars that are turning the Bitcoin Protocol into the US Congress?   Completely unable to make decisions, be agreeable, and move forward?

Gavin can propose anything he likes, and we can all love it, but if this mysterious *CENTRALIZED* group of core devs doesn't like it, they wont have a "CONCENSUS".

Concensus is supposed to be from the entire community.  Not a handful of programmers who have zero education or training in finance.

-B-

As a serious answer, I was giving a history lesson on what the correct notation is before it was bastardized by other organizations not too long ago. There isn't any room to argue on this as it is historically accurate.


http://www.accountingcoach.com/blog/what-does-m-and-mm-stand-for

http://english.stackexchange.com/questions/181917/mixing-use-of-k-for-thousands-and-mm-for-millions

http://www.bankersonline.com/forum/ubbthreads.php?ubb=showflat&Number=94526

It seems like there are a lot of people around with financial incentives to keep Bitcoin from advancing any further, even people who are nominally part of the "Bitcoin community".

Interesting.  I had no idea, and I've BEEN working with financial data. 

Pretty much everything I've seen has used SI prefixes here in the US.  On the (rare) occasions where I've seen 'M' used to mean thousands I've briefly wondered whether it was a typo or a deliberate misstatement, but since the truth was clear enough for other reasons in those particular documents, never pursued it.

Anyway, I'm sticking with SI prefixes in everything I write.  It's the nearly-universal standard now and the sooner everybody stops using everything else the less confusion we'll have.  But now that I know some people have learned an obsolete system that will cause them to misinterpret SI prefixes, I'll at least make a footnote that says so.

one sure thing, I need practice in trolling, you guys rocks, what 10 posts on k or m, when the issue is forking or not forking ::)

This is not far from what gavin had proposed.His proposal would involve a higher rate of block size increases due to more frequent compounding. Your suggestion would make it very easy to remember when the max block size will increase and would likely require much smaller changes to the code then what gavin is proposing

Thanks for the references. I can see there that there is some sentiment there for M=1000, MM=1000000. However, none of these seems to rise to the level of an accredited international standards organization - such as the American National Standards Institute, British Institute of Standards, [International Standards Organization], or similar - each of which have standardized the use of SI prefixes. Further, your bankersonline reference seems to indicate that the traditional financial prefixes may be an anachronism on its way to disuse.

However, tradition is a strong force. I'll leave the bankers to their traditional units. I just worry the potential of magnitude errors as these two systems clash. Indeed the bankersonline link you provided already alludes to such a problem.

To those not interested, sorry for the sidebar. I'll drop this line of inquiry.

I wouldn't call that a fork, but an improvement. And it's quite elegant. I support it too...

A hard fork is a change that older versions will reject.  Older versions will certainly reject a 1.1MB block no matter what you call a change to allow it.  It's nice that you are starting to understand what is actually being proposed,  but this would not be the first or last fork of bitcoin regardless of your definition and/or acceptance of the same.

who cares... what I like about this one, is that even I, can understand it... However, and to your disappointment I am firmly against the proposition of Gavin (even if I didn't read it) for the reason that it's too complex, and only a feat for the devs, not for the coin... if you see what I mean...

edit: if you want (for your dream of world domination) you could even square it, meaning at 6.25 BTC = 16 MB and so on...

If by 'advancing any further' you mean not becoming manageable enough to meet the spirit of the demands necessary to achieve what the U.S. government would like to have in a Bitcoin License, I would agree.  Certain of them are much more than 'nominally' involved though.

In terms of 'financial incentive', I've little doubt that prostrating Bitcoin to TPTB while the marketing propaganda has most people convinced it is otherwise and thus has a coolness factor would produce a sweet spot where possessors could make a killing if they got the timing right.  I'll certainly be shooting for that if I see the opportunity present itself.

Win/win for the hodler who still has some hope for the solution.  It either under-performs (in the mid term at least) and remains a worthwhile endeavor, or it goes to shit and makes the shrewd player some big buck.

I hope we can just make our decision and get it done soon instead of debating about it for another year. Based on reading these threads, the majority consensus is that block size needs to increase. Satoshi said it himself 1mb can be changed in the future.

Ya, ya.  Get that exponential growth in there lickidy-spilt quick ASAP before sidechains make it obvious that it is pointless and counterproductive.  Nothing like an exponential function to ensure that something will eventually explode, and it would be a disaster for a lot of people if there was a chance that Bitcoin could be relied on on a sustained basis.  When a collapse can be predicted, even if it is decades out, it does wonders for future-value computations (if one wishes them to be damaged, that is.)

Sarcasm aside, it actually is a little bit questionable whether 7 TPS would be enough to comfortable support a thriving sidechains ecosystem.  Such a thing would be almost infinitely adaptable, however, so probably it would be OK.  It always seemed to me (years ago when I proposed 'bc0' for the primary blockchain and long before 'sidechains' were proposed as a word) that transfers between child chains and the main chain would be bundled.

"If Bitcoin is to remain decentralized, it must have larger blocks."
Of course we need bigger blocks. Some people still think scrypt is a good idea in that bigger memory requirements improve decentralization. Bigger is better. Why can't this "scrypt mentality" work for block size too? If the blocks are bigger, then Bitcoin will be more decentralized. It's the same argument for Litecoin, except on a different scale. With Litecoin the notion was that the CPU would dominate mining because it would be unaffordable to develop ASICs to handle the memory requirements. With block size doubling it is believed it will be unaffordable for people to transmit and store the blockchain. This example uses contradictory notions about size to make the point that size doesn't matter. This is not a cryptology (or philosophy) problem, it is an engineering problem. "Scotty, get me Warp Nine!"

Who said already that 32ko would be enough  ::) ?

Are you suggesting that it makes more sense to fork bitcoin so that microtransactions can be processed and ultimately repatriated in a separate decentralized sidechain?  That seems like a much more complicated fork with little to no additional potential benefit.  Without such a fork, it seems to me that switching to a sidechain for everday transactions would only benefit arbitragers and scammers.

IOW, in order for your bitcoin to move based on activity on a sidechain, you would have to trade into whatever the sidechain has, which means at least temporarily giving control of your assets to a third party.  Speculators can make money trading the sidechain currency, but from a security standpoint, the activity required to switch to such a sidechain is a short term risk, see Mt.Gox et al.  If the sidechain you propose is something like Ripple, then it's not even decentralized, and users would have to give up control of their assets for as long as they wanted to take advantage of the "sidechain" extending the same scam risk.  Beyond that, why are we calling it a sidechain?  Even if it is decentralized and somehow references bitcoin blocks, it still sounds like an altcoin to me.  I believe the purpose of sidechains is to take advantage of the bitcoin blockchain for non-currency functions.

That having been said, I agree that growing exponentially indefinitely is a bad idea, but given the last of the halvings would be dealing in small fractions of bitcoins, it should be reasonable to do something like this:of course, I've not done any math to determine whether doubling is necessary for each step (vs increasing by 25% after 16MB or only increasing by a set MB amount after a certain MB target), my point is simply that the blocksize increases could stop with last halving, and that this isn't a bad point either:

looks good to me, but it is more of just a cool little ratio.  I think Gavin made his by looking at Bitcoins past needs, drawing a line to what the future is, and then trying to meet those needs.  Probably more realistic that way even if it is more complicated. 

That said, either way is better than what is happening now. 

For the people who think exponential growth is NOT a good model for this, I'd like to point out something.... 

Accusing Satoshi of pulling a Bill Gates when he put in the 7 TPS cap is funny and all that, but it simply doesn't map to the concept of exponential growth very well.  It does, however, illustrate what I was talking about when I said that most human minds are simply not wired to register it adequately.

Yo Dawg, I hear you like side chains so I put side chains inside your side chains. Now you have 7⁷TPS.

Huh? No, not really.

I'm saying that I'd be very willing to shake some of my BTC out of cold storage and peg them on various side-chains which server various purposes if I could ultimately repatriate them on the (hopefully decentralized) non-sidechain.  That is to say, Bitcoin.  That's kind of the point as I understand things.

In practice, ya, I'd lock some BTC value to super-micotipping sidechain (as an example) and micro-tip to my heart's content.  If the super-microtipping sidechain maintainers turned out to be dicks (and I was paying attention) I'd repatriate whatever I had left on that sidechain back to the Bitcoin blockchain.  Of course it is expected that the recipient of micro-tips would be repatriating their micro-tips to Bitcoin blockchain from time to time as well.

Basically sidechains just open up a new universe of use cases (market) for Bitcoin with almost zero downside.  At least not one which I've seen enunciated very effectively.  They do, however, solve almost all of the problems which cause so much risk to Bitcoin when it comes to development progress.  Sidechains seem to be as close to a win/win as I can remember in the ecosystem.

Yeah, it sounds great in theory, but what makes you think it can be done without a fork?  Currently, bitcoins exist on the blockchain and they are controlled by the private key.  They can't magically disappear from the blockchain and come back later as it currently stands.  Even when they are sent to addresses that aren't revealed yet, the owner of the relevant private key still controls them and the blockchain is still tracking them.  That having been said, my understanding of what you are describing is that either you still have the bitcoins and still control the private key, in which case they aren't moving on a sidechain and you are issuing IOUs on the sidechain, or you've given the bitcoins away, trading them for IOUs in the sidechain while trusting someone to reimburse you in the future for the ones you didn't spend.  Clearly one of us is understanding something wrong.

That having been said, even if a decentralized system that we could trust to manage our private keys existed so that we could send bitcoins to the "sidechain" (by giving up a private key or sending to an address assigned to us but controlled by the "sidechain" [this example wouldn't actually be a chain, it would be off-chain, which is already possible if you don't mind IOUs from a centralized party]), you'd still have to trust that "sidechain" to properly allocate the bitcoins in the blockchain at some point, and for it to be any more efficient when someone "repatriated" (really "withdrew") their microtips (from your example), it would have to behave as a mixer of sorts, maybe taking the sum of the microtips from the private key you "deposited" to and repatriating your leftover bitcoins to an address you control from someone else's "deposit".  This is in no way simpler than the proposed fork, and it doesn't necessarily resolve the underlying problem.

Cryddit puts my mangled thoughts from above into much better words two posts down (https://bitcointalk.org/index.php?topic=816298.msg9317787#msg9317787).

Don't be silly.  Satoshi knew darn well that one or more hard forks to address scalability would eventually be needed.  He said so back in 2008-2009. 

Side chains last I looked, if we want to do them in a trustless network, require several important bits:

First, coin can be created "ex nihilo" on the side chain by a transaction that locks up BTC on the main blockchain.  This much, at least, is easy.

Second, the side chain can handle transactions of side chain coins going back and forth between users of that side chain.  This is also easy.  

Third, the secret/s necessary to unlock that BTC gets transmitted through the side chain to the recipients of the side chain coins.   And simultaneously the secrets held by the former owner of the side chain coins become unusable for releasing the BTC on the main chain when the side chain coin is transmitted. I don't know a good way to do this other than constructing parallels of every side chain transaction on the main chain, which makes having a side chain rather pointless.

Fourth, when someone on the side chain redeems his side chain txouts onto the main block chain, he has to be able to repatriate -- probably taking only parts of the BTC  locked up by the locking transactions, which means 'spending' that locked BTC and creating a new main-blockchain txout to hold "change".  But this has to be done in such a way that the other side chain coin holders whose coins represent  claims on that locked BTC can still redeem their coins from that same lock, for remaining coin now in the "change" txout.  

I have not seen a good solution to the above problems.  

All 'side chain' schemes I have seen involve trusting someone to exchange BTC and side-chain coins, and having the secrets to release the BTC on the main chain.  I don't think a person we can trust to be that exchanger exists.

sorry for this noobish question but what is a TPS? thx

To the extent that sidechains need a fork for efficiency, I'd support it fully.  Meaning that I'd accept it, and it's very possible that I'd start running a full node again (and maybe at home behind my satellite connection if certain other 'good ideas' don't make it into the codebase.)


I've always visualized sidechains (before they were named) as efforts which are not free of work.  People involved in a sidechain effort would have basically the same set of responsibilities that the people involved with Bitcoin have in order to make me wish to use (or participate in) the effort.

The SC whitepaper anticipates some not insignificant latency involved in securely moving between the bitcoin blockchain and the sidechain.  I've always imagined such transfers as being aggregated operations which would add somewhat to the latency.  Say, for instance, once an hour adjustments to the backing store were performed.  I'm fine with that as long as I can have confidence that my value on the sidechain is protected in a reasonably sound and unexploitable manner, and this seems technically quite doable to me (though hardly trivial!)

In practice I would probably almost never do an actual proper Bitcoin transaction.  It would be an event like going to my safe deposit box which I maybe do once per year.  I would, however, likely be transferring from one sidechain to another sidechain on a very regular basis, and behind the scenes a variety of aggregated operations would be doing the heavy lifting.  Many of them probably need not even result in one actual Bitcoin transaction.  Obviously I would only be using sidechains which are operated in a manner which is on par with Bitcoin in terms of the confidence I have against exploit.

In the manner so described I would in fact be using Bitcoin fully insofar as I acquired some fraction of the Bicoin currency base and maintain unique control over that fraction, but I would be doing so with minimal burden on the actual blockchain.

Transactions Per Second.  Spends.

The block size is a function of the TPS and the size of each transaction which can very depending on complexity.  At the current 1MB the ballpark average number of transactions per second is traditionally considered around 7 transactions per second.

This is the thing which Gavin wants to change to be growing exponentially which means to me that the future-value of Bitcoin is fairly closely approximates my confidence in the endurance of 'Moore's law'.  That is to say, not very high.

For general info, Gavin's 50% per year comes from observing the long-term trend in high-end home user bandwidth speed.

http://s3.amazonaws.com/media.nngroup.com/media/editor/2014/08/08/internet-bandwidth-nielsens-law-1983-2914.png

http://www.nngroup.com/articles/law-of-bandwidth/

The trend will level off, but probably after the 2020s.

OK, but why is a complicated fork to make sidechains work better than a simple fork to allow bitcoin to process a meaningful number of transactions?

As I've said about all your posts, it sounds great, but we can increase the size of blocks now.  We may or may not be able to come up with a solution to the problem with these theoretical sidechains that is better described by Cryddit shortly after my post (and linked to my post apparently as you were typing this) at all.  So, for sidechains to be a viable option, you need a trustless method of transfer from and to bitcoin, and for what you describe, you also need a trustless method of transfer between multiple sidechains.  In addition to that, you need motivation for the workers that run each sidechain.  In the sidechain described by Cryddit, it proably can 't be mining rewards (since coins are created and destroyed on the fly to represent bitcoins), if it's fees, then why do you need to get out of the bitcoin blockchain to begin with?

;tldr Why against blocksize increase? + Nevermind that trustless sidechains don't exist, what are such a sidechain's benefits?

Speaking only for myself, the current rate is very confidence inspiring because I can see it being defensible even if all governments decided to go to war on Bitcoin simultaneously.

I would also point out that the kinds of things that might help sidechains be efficient in a hard or soft fork are very low risk to bitcoin proper.  The key element of sidechains is that they are highly independent of bitcoin which isolates it from risk.

To me (and probably to very few others) changing the transaction rate (a hard-fork) is on par with changing the total currency base (the 21-million) in terms of the risk to the system.  At the beginning of the year I liquidated a not insignificant amount of my BTC holdings and it was the constant threat of this eventuality which was a big factor.  The threat alone and the traction it is getting very much damaged my confidence in the solution.


As I described in my last missive, sidechains would allow genuine real 'use' of Bitcoin while preserving the defensible nature of it.  In fact it would promote the robust defense of Bitcoin since it would be the core upon which everything else rests.

It could be legitimately argued that in order for Bitcoin to thrive it needs to become compliant with the demands which the governments would like to place on it.  'Bitcoin licenses' and such.  This very well may be the case, but it completely kills my interest in the solution.  Not that I don't see the concerns that governments have and agree that there are potential problems with an uncontrolled currency solution, but I see the dangers of abuse of such control as being an even bigger threat.

I would be very disappointed if bitcoin were forked/modified solely for the purpose of complying with any such demands.  It is outlandish to suggest that bitcoin needs to be controlled anymore than cash when it is already less anonymous than cash.  Most regulation in the pipelines is about people/corporate entities and does not (many would argue can not) tell the protocol or asset what to do.  Most said regulation also refers to virtual currency as a catch all, meaning that side chains would not be immune from the same set of rules.  I have to assume your concern is about blockchain bloat at this point, but that seems to me like a more expensive and less effective point of attack than the current limited transaction rate.  Regardless, if all transactions are being blocked by an attack consuming the entirety of the available transaction rate, then it is difficult to believe that sidechains won't be negatively affected even if still functional.

Hard fork is always risk for whole bitcoin project. If something will go bad, some critical bug will occur, we are doomed.

One of the cool things about sidechains is that some of them could be perfectly compliant with all the regulations that the government wants, and entities who would like to use Bitcoin but are finding it difficult due to judicial and legislative difficulties (e.g., PayPal) could still use Bitcoin...just under the cover of a sidechain.  And I would happily use such sidechains for a lot of stuff because I've already got to practically give such entities a DNA sample to do business under their umbrella anyway.  But they would still have visibility into what *I* want them to have visibility into and not everything I might choose to do in financial-land.

It would be much more difficult (though not impossible) to make a case that a Bitcoin-backed sidechain itself was non-compliant because Bitcoin remains uncontrolled.  One way or another it would throw a giant monkey-wrench into any plans to bring Bitcoin under control (via, say, red-listing or simply ballooning the system to such an extent that only large-ish corporations are able to do real verification.)

Ya, well I wouldn't notice since it would impact the sidechain I happened to be using in the same way a sidechain would impact Bitcoin: not at all.

But say I did notice and didn't agree with the direction (e.g., somehow supporting pedocoin or some similar disagreeable thing and not able to shake it.)  I may switch half of my sidechain holdings to a different sidechain which had more promising management and half back to Bitcoin which I send to a cold storage wallet.

Anyway, and very key, "Bitcoin not affected."

  ...though in this case some lucky miner picked up a transaction fee or two from me for my rare native Bitcoin transactions.

How long is 'always' I asked myself?  Looks like around the time of my first posts in this forum and I joined within a month or two of when I first compiled Bitcoin:



Almost literally my first thought upon understanding Bitcoin was "that will never scale" and I tried to imagine ways that it could.  The fundamental economic and basic mechanical theories behind sidechains popped into my head immediately though I never had the technical abilities and dedication to think up some of the ideas and finer points that the blockstream guys have.

Even back in the early days (pre Satoshi-Dice) I was conscientious about polluting the blockchain.  I was also miffed that talking paperclip class development efforts were prioritized above blockchain pruning as described in the original paper.  These developments never did materialize making it extra galling that the solution is three years later to just to grow the block size without bound and rely on the tender mercies of the corporate network providers and the conjectures of Dr. Moore to backstop the solution on out into infinity.

thank you a lot, you are very kind and clear! I clearly don't think to have the necessary level to participate in this discussion. So thank you all, I will read you from the sideline, and wish you all well. My last stupid comment, as this topic seems more mature :

There are in my limited knowledge only 6 options to scalability :

1. with the fees, it will be adjusted automatically (don't pay enough to be in the 7 tps, no tx for you) / BEST OPTION
2. bigger blocks
3. faster blocks
4. alts
5. data compression (it will fit in those 640ko btw)
6. dynamic blocks (everything change depending of the usage)

6. being a little bit complex and that with alts no need to fork! maybe the global payment system is just a pipe dream... but a global payment system (which is the case right now) why not...

And a big thank you to the People of bitcointalk.org for letting speech be free here.

(Astalavista baby, I will be back)

I still want to know, technically, how a side chain could work, including the ability to trustlessly, without an intermediary or a human-operated point of failure or control, move coins back and forth from the side chain, through some unbounded number of side chain transactions, and back to the main chain.

1 is probably not an option as the TX fees will get increasingly more expensive up to the point that people are priced out of sending anything but very large amounts.
2 is what is being proposed
3 would be considered to be an altcoi
4 horrible idea - they all eventually fail
5 and 6 would be interesting potential alternatives to what is being proposed now.

Me too. Key management is cumbersome enough with only one blockchain let alone having to handle multiple blockchains simultaneously. I've worked out a way to manage 1:1 bitcoin swaps using 2 of 2 multisignature transactions, but it would be worse than just using Bitcoin.

The more I look at this proposal the more I get the idea that sidechains might be a distraction that they don't ever intend anyone to actually use.

Maybe there's something else that could be done with those new opcodes.

So essentially an SC client will issue a 2 of 2 multi-signature transaction in which you deposit bitcoins. Your client will broadcast the transaction to the SC miners who will send you the SC address to send the bitcoins. It will then automatically send you an SC asset (or coin). Your SC key is then an encrypted version of your half of the bitcoin key. In order to decrypt your key you must transfer the SC into a  conversion account this time purchased from a miner, and give it your Bitcoin address. The algo then automatically broadcasts the 2 of 2 transaction to your Bitcoin address. SC mining would convert coins back and forth by encrypting and decrypting the Bitcoin addresses with SC  tokens.

If you read Gavin Andresen's blog and posts, you will see that in the past he has made the logical suggestion that the users of BTC pay for network scalability by paying more in bitcoin that the current 'voluntary' contribution of 0.1 mBTC.  This is because with increased scalability, the transaction fee must rise to as high as 0.02 BTC, which is at today's prices about $8 USD (and of course if BTC goes higher, this fee will be higher as well), since miners will no longer subsidize low fees (a paper was done showing this, see: http://www.coindesk.com/new-study-low-bitcoin-transaction-fees-unsustainable/   )

As BTC transaction fees rise, G.A. has said, users can either pay more by selling their anonymity to a marketer like Google (a blog post said this, I don't recall where it is), or, simply pay the extra transaction fee money.  

IMO what will happen with BTC as transaction fees rise will be that it becomes more like PayPal or Western Union.

After thinking about it for a few minutes the one solution which came to mind was something along the lines of what follows, and doesn't even include any fancy stuff though the idea of figuring out how to exchange private keys themselves (possible 'BTC fractions' outlined below) has always appealed to me for a few reasons:

I choose to fund a sidechain with 1BTC.  In doing so, the sidechain gives me 1M unripened tokens.  Only I can ripen them and make them usable.

The sidechain keeps kind of a 'till' filled with whatever fractions of BTC they have handy, but they are locked up and it requires X number of ripened tokens to unlock.  I can trade my ripened tokens around with other users within the system, and if I want to cash out (into Bitcoin) I can dedicate my ripened tokens to the task.

Possibly the sidechain in order to perform optimizations and what-not would request that I give them some ripened tokens which they might use to thaw some BTC.  Possibly just to get their till organized and also maybe sometimes to balances between themselves and other sidechains.  This I would happily do and of course accept some unripened tokens right away as replacements.  Naturally this would be effortless and automatic on my part though I might tweak some knobs once it a while.

Actually, come to think of it, maybe I have full and unique control to unlock specific BTC fractions using my own ripened tokens and the balancing is just me giving up and taking control of BTC fractions as need be to maintain some approximate valuation which I have in the system.

It must be remembered that the source code which performs these operations is open and written to be secure, and part of my decision to use a particular sidechain would be associated with how many eyes had looked things over and their history of non-failure.  Even the system cannot, say, ripen my tokens (unless someone slips some evil code in.)  This is not unlike the methodology which protects Bitcoin proper users.

Yeah, the token thing occurred to me as well but seems quite complex as they also need to be uniquely and verifiably paired to bitcoins. Sorry for getting so far off topic.

I think raising the fees for scalability would be too much. For a fee of 0.02, imagine if 1 Bitcoin was worth $1000. That would result in a fee of $20 for any transaction, regardless of how much is being sent! That's not very ideal. I think what can be done is to support a larger number transactions per block. More transactions processed = more fees collected.

There needs to be a reasonable supply/demand curve in order to get fees to be a voluntary thing and allow the market to work (though the inflation-based block reward currently fucks up the market royally.)

One cool thing about sidechains (and probably other constructs as well) is that they create the potential to aggregate native Bitcoin transactions.  This means that very significant transaction fees could be paid to Bitcoin infrastructure providers yet individual users would hardly feel it because they share the cost.

Indeed, even if no more mining rigs were built between now and 2040-ish it would require very large transaction fees just to keep the existing rigs powered up unless BTC valuations expand by a bunch.  And if the miners cannot make a dime helping Bitcoin then we better hope and pray that they cannot do so by harming it either.  Of course 'hope and prayer' are often fairly ineffective engineering strategies.

Transaction fees only exists for 2 reasons currently;

1. To prevent massive blockchain spam
2. To keep the miners going after block reward is either extremely low or non existent

If no more miners would be build it would actually be more profitable for current miners because the difficulty would stop increasing exponentially, current miners would be celebrating on the streets since they will keep making the same amount of bitcoins per month.

On the counterpart, old mining equipment simply goes into retirement when they become obsolete (too slow, too much power draw, etc)

I don't see the average consumer dealing with sidechains and everything. If we remove the limit of 7tps soon, we might be in time to prevent massive transaction fees when the next price/transaction spike happens. In the end Bitcoin is advertised as a low fee system, if each transaction starts costing dollars personally I would loose interest.

Also creating sidechains would destroy Bitcoin when the block reward gets extremely low or when we stop having block rewards, since miners on the main chain would either stop mining since the transaction fee is so low (making the network extremely insecure), or make transactions on the main chain insupportably expensive to maintain their mining.

In order to prevent high transaction fees we need to increase blocksize and remove the 7tps limit. It appears that the majority of community is in "pro" of this so it should be done quickly to prevent the inevitable high transaction fee explosion. When transaction fees become important hopefully miners will make their fees by high volume of transactions (all at a low fee).


Example:

Bitcoin high frequency trading:   

47,000 tps (around the peak rate of VISA) = 28,200,000 transactions per ~10 minute block

Fee of 0.000000017 = 5 bitcoins per block transactions reward for miners. Easily sustaining the network at a high price. If Bitcoin is going to be a global cash system we'd probably have hundreds of thousands of transactions per second. But having more transactions per second than VISA is a good initial.

High transaction fees:

7 tps limit:

5 bitcoins (transaction reward) / 4200 (tranactions per block) = 0.001190 transaction fee. Way too high for the consumer paying his hamburger at a restaurant.

=====================

Combining pruning + near no limit of transactions = low transactions fee.

Why artificially limit a open concept market? The market will take care of the fee, we shouldn't impose limits on it except to prevent massive blockchain spam or otherwise malicious activities.

That should make it pretty clear why I (and quite a few others) don't believe that Bitcoin in anything remotely resembling it's original and described implementation (distributed persistent decentralized ledger) is applicable as a solution to the described problem.  Bitcoin won't scale just because people would think it's cool if it did.  A handful of large organizations probably could run Bitcoin at these rates but realistically that's about it, and at that point they may as well do away with the blockchain itself and make it a real-time system like VISA.  That's why clued in folks like the blockstrream guys are looking around for a solution which will let Bitcoin scale to these levels without abandoning the very desirable aspects of the solution that it has today.

As usual, your theory sounds great.  However, I've seen nothing that would convince me the block size shouldn't be increased.  That having been said...Blockchain pruning is very important.  Blockchain pruning and blocksize increases are not mutually exclusive.  I hope blockchain pruning is being worked on, and optimally, blockchain pruning would be included in the same fork as blocksize increases.  Data for sidechain transactions has to be stored and secured as well.  In my mind, using one super-large super-secure network is better than having to move between a lot of competitive networks when you are talking about decentralized systems like Bitcoin.  Yes I'm glad most local retailers accept Visa AND MasterCard, but I'd be better off if they didn't an I wasn't paying the fees.  To that end, if they start accepting bitcoin and offering a discount for its use (which admittedly may only be as likely as businesses offering discounts for cash, which are rare), then I would expect both discount offers and acceptance to decrease with each additional sidechain.  IOW, I would expect the same nonsensical multi-tiered payment processor plans where you pay more to accept SC1 in addition to BTC and even more to accept each sidechain beyond that.  With that kind of potential outcomes, I believe it is much better for bitcoin to adapt as necessary and even expected from the start than for it to be treated as an untouchable behemoth base that must be worked from/around.  However, back to the first quote, I also believe that most countries where bitcoin will be useable in the beginning are supposed to be controlled by their citizens and that, as such, bitcoin should not need to be modified (or connected to sidechains) for regulatory reasons to begin with (nevermind my previous comment that most regulations control corporate entities and bitcoin is already more visible than fiat, so certainly shouldn't need more control than fiat [which can't truly be controlled anytime it is in the hands of citizens]).  Nonetheless, to the suggestion that bitcoin or a sidechain could need changed (or created) for regulatory reasons, I say it is incredibly unfortunate that fear in uninformed citizens and money from large corporations seem to be the only things driving the law most of the time.

Pretty sure satoshi talked about light clients for the masses.  Also pretty sure VISA keeps a ledger.  Are you suggesting that "clued in guys" have insider knowledge that storage technology isn't going to continue to grow and get cheaper?  Do you also think "clued in guys" are writing solutions that pay people to mine things other than bitcoin are doing so completely philanthropically and not out to make a buck?  Is there any real evidence that sidechains aren't just going to be the new altcoin?

ETA: Considering the cost of ASIC mining equipment, storage technology would actually have to start shrinking and increasing in cost to the point that individuals couldn't afford computers before it would begin to matter to miners.

Actually combining blockchain pruning (i.e, the "main" blockchain only storing UNSPEND addresses), and some of the new emerging technologies like ed25519 that even on an old 2010 CPU we're already capable of 80,000 verifications per second. Seeing how we have a HUGE HUGE way to go before we actually reaching that amount of transactions per second, when we actually do reach it would likely be way post 2020, where we will have even faster hardware and likely better algorithms, which should technically be able to sustain the guidelines I mentioned.

Not to mention that most people would be running light clients anyway around that time, just as described in satoshi's original paper.

In the end there is no reason not to have everything running on the main blockchain since technological difficulties can be overcome.

Visa does not actually keep a ledger. If you wanted to use a Bitcoin analogy, you would say that Visa acts as a node (that does not keep a mempool of unspent inputs) and will only "accept" a transaction if the issuing bank confirms there is enough unspent inputs (credit line available).

I've thought of that, but it doesn't work unless the sidechain coins come in non-divisible (and more to the point, non-unitable) denominations.   Otherwise the 2nd sig becomes "problematic" when facing a sidechain coin that represents a microscopic interest in each of thousands of BTC-locking transactions on the main chain -- which happens, on average, after about ten spends if the sidechain coins can be split and recombined like Bitcoin.

And you have to have Trent holding the 2nd sig of the multisignature.  The minute someone serves Trent with a photo of his wife and kids with guns to their heads, nobody can redeem their coins off the sidechain without the extortionist's approval.

This only works if you are eventually cashing out the same number of tokens you cashed in for.   The minute someone actually pays someone on the side chain, and doesn't eventually get back an equal number of sidechain coins, the people they paid on the side chain have no way to get their money back to the main chain without the payer's continued cooperation.

Suppose Alice uses a Bitcoin to get 1000 mBTC tokens.  She ripens them and pays Bob 750 of them on the sidechain, then cashes out her 250 remaining mBTC tokens back onto the main blockchain, sells all her BTC  at an exchange, and takes her client offline permanently.  How does Bob ever cash his 750 tokens out without her cooperation?  Alice hasn't even stolen anything here, but she's still just being a heartless bitch. Maybe Bob is her ex-husband or something.

So essentially you still have the "Trent" problem, except that now "Trent" is whoever happened to make the original BTC-locking transaction.  Nobody can cash out their coins unless Trent is cooperating, and Trent won't cooperate when under duress or extortion.  Nor will Trent cooperate if Trent is Alice and just doesn't give a crap whether Bob lives or dies.

I've heard all this kind of things ad-nauseam for the 3+ years that I've been following things.  Simultaneously I've seen both the hardware and network improvements which have been made realistically available over that time period, and also the struggles Bitcoin has had just to make the original 7 TPS number kinda work.  Many of them were not pretty.  Some of these rosy predictions about how technology will swoop in to save the day (and let us go from 7 TPS to 200,000 TPS which is enthusiastic even for your type) would be more convincing if there were a few more signs of it actually occurring.

Sorry, I know that for the last few posts I've been talking about side chains rather than the proposal.  

This is relevant because I'm trying to demonstrate that unless someone makes a fairly profound cryptographic invention, side chains simply are not a trustless solution.  And in the long term nobody can be a point of trust without offering a point of failure and point of control to all the scammers, cons, extortionists, terrorists, dictators, governments, etc in the world.

We need this fork.  We don't have a viable alternative that can retain Bitcoin's permissionless nature.  

Clearly a simple but good move forwards to massive bitcoin adoption, hehe.

Nice of you to correct me, and maybe ledger isn't the right word at all considering that most of their transactions are credit based, but do you really expect me to believe that Visa contacts JP Morgan Chase to verify credit hurdreds of thousands of times per day?  I'm simply saying that Visa is keeping track of a lot of data in order to process all those transactions.  It may be pruned regularly since the banks have to provide statements and whatnot, but some transactions take a few days to clear, so they certainly have to track it that whole time.  Regardless, none that changes the fact that they process and track a lot of data.  Moreover, my point that storage is the cheapest part of a miner's arsenal still stands, and as long as miners are paying the kind of money they currently pay for ASICs, storage is not going to concern them.  On the other hand, income obviously will, and IMO, when the block reward halvings get relevant, more transactions are more likely to keep bitcoin secure and competitive than higher fees per transaction and users that go to sidechains to avoid paying the fees (and that's even assuming someone as genius as Satoshi comes up with a good trust-free way to make sidechains serve this purpose instead of all the purposes sidechains were really meant to serve when the concpet came about).

One of the main reasons these things haven't been implemented before is that Bitcoin as a whole was still in a massive alpha stage, having more transactions per second simply wasn't needed up until now. And now especially so that we can continue to grow.

Commercial profit driven companies attempting centralized solutions (like blockstream) to problems can be solved with decentralized and open solutions are honestly very terrifying, and I hope that technological advances on Bitcoin deploy fast enough to prevent any side-chaining or centralized solution having to take its place so we can continue this open concept revolution for everyone to continue spreading. 

What is also important is sidechains are useless if you want to receive your remainder of tokens back in bitcoins. All this will do is switch value away from an open decentralized solution to a closed centralized "solution".

But this won't solve the problem over time.  See the response by kkaskal in this thread: https://bitcointalk.org/index.php?topic=668704.0

And the graphic at URL in this thread:

<img class="userimg" src="https://ip.bitcointalk.org/?u=http%3A%2F%2Fi.imgur.com%2FMCWO0tH.png&amp;t=545&amp;c=8_MsRYuvimAWfQ" alt="" border="0"></img>

Note block reward is decreasing over time, a well known problem since the number of bitcoins is fixed and it gets progressively harder to mine bitcoins over time, all things being equal.

I made a fairly reasonable calculation on future fee costs that shows it actually is sustainable.

Well, the 'clued in guys' who associated themselves under 'blockstream' just happen to be among the most productive and thoughtful of the Bitcoin developers and maintainers.  I've personally paid pretty close attention off-and-on for some time now since I have a fair bit riding on Bitcoin (and have not yet diversified into any alts.)  I've seen Maxwell be uniformally out in front when it comes to trying to protect the goals of the Bitcoin project which are important to me (openness, decentralization, etc.)  When I was watching the deltas it was pretty clear to me that ~sipa was what we in the biz would call the 'principle architect' of the Bitcoin.  Adding bluematt, Back, Frie-whatever, etc into the mix makes this group clearly the tip of the codebase spear in my opinion.

It's a fair bet that some of these old timers have giant hoards of Bitcoin.  By your own logic it makes little sense that they have anything but a powerful financial incentive to foster the health of Bitcoin itself.  Since I personally believe that sidechains are by far the best hope of doing this (and benefit the world's masses in the process) I am not at all surprised and am very heartened that they have organized to achieve this effort.

As far as I'm concerned Hearn, who absolutely _has_ made some very valuable contributions to Bitcoin, has always been in direct opposition to many of the aspects of Bitcoin that appealed to me.  To his credit he has been relatively open about these things (debatable on some of them though.)  Discriminating against arbitrary users via mining consolidation, consolidation of blockchain maint to a small number of large entities, Red-listing, mainstream passport use for individual identities, etc.  I've developed a sense that Hearn has Andresen's ear in a fairly big way and significantly through the medium of the Bitcoin Foundation which also seems to align with Hearn's direction for Bitcoin.  When Gavin went to the Council on Foreign Relations (some of the most wealthy and influential people in the world) and refused to either commit to openness or even debrief on the conversations he may have had, this further damaged whatever credibility he had (to me.)

When Gavin champion an exponential growth rate for Bitcoin the first thing I thought was 'Ya, that figures.'


Aside from the fact that 'that don't make no kinda sense', nobody has ever really considered storage capacity (indicated by your use of the term 'shrinking') to be a factor in much of anything.  At worst one might need to physically deliver media in order to get a node operational, but that's doable.  Access to the local data for 'old school' full verification modes of operation is a somewhat different matter, but it's likely to be a solvable problem.  Both of these assume some simbalance of reasonable system growth at least.  If TPS limits were lifted completely all bets are off, but that's not what Gavin is suggesting here (for the next decade or so at least.)

The only reason those developers have "gotten behind" blocksteam is because they're getting paid to do so, they have actually included a part in their contract that states if they think the company is acting maliciously they can leave at any time, probably because they can realize what is going on already. They still work on the main Bitcoin code as well.

LOL!  OK.  And you know this with enough confidence to state it as a fact how again?

That's a bad thing?!?

If that's so then why in the fuck would they have even associated in the first place?  Work on your critical thinking skills a bit will ya?

Thank God!

I suggest you read through this: https://www.cryptocoinsnews.com/sidechains-bitcoin-2-0-revolution-highlights-reddit-ama/

I followed the sidechains AMA.  Nothing new in that story at all, and nothing whatsoever which would support much of what you've been saying.

I will say that I'll expect sidechains impact on alts to be one of 'separating the wheat from the chaff.'  I believe that a fair number of alts were created to address some legitimate and valid needs that the the designers felt important.  Probably a majority of alts were created as pump-n-dump scams.

Alts which were created for the right reasons probably largely lamented the fact that they could not let Bitcoin do the heavy lifting as the actual value component.  These should be absolutely delighted to switch to a sidechain implementation.

OTOH, I foresee howls of rage and despair from those alts which are pump-n-dump scams designed with the hopes of making some early adopters rich.  I suspect that a fair amount of the negativity toward sidechains is from this corner right now because I can see no other legitimate complaint against sidechains.  This from a risk perspective, economic perspective, philosophical perspective, or any other rational perspective.  At least not one that is based on any skin-deep understanding of things.  (Actually, I take that back; those desperate to destroy Bitcoin as an empowering technology for individuals will also be quite alarmed by sidechains.)

Better way ahead:

3rd party Service which individuals keep a btc balance on, app form for instant PoS transactions, like applepay.

Individual TX never sees the blockchain.

I snipped the first part of your comment because, I don't pay attention that closely and won't argue something I have no clue on.  Regarding this last comment, I've seen plenty of what Hearn wants to do and probably disagreed about as much as you have.  As such, your suggestion that he has much pull concerns me.  While I was also already somewhat concerned about TBF in general and the lack of openness with the council, for lack of a better way to put it, I don't think TBF is Google (with a motto of don't be evil and pure evil ambitions/intentions).  TBF may be stupid, but I prefer have opinions on the ideas instead of the people/groups who came up with said ideas instead of assuming the ideas match my opinions of their source.

Here, you just said exactly what I was saying about the size of the blockchain not being important to miners, so I'll pass that off as a communication glitch.  Similar comments could be made on the size of blocks and the cost of bandwidth.  If you agree storage and bandwidth aren't problems for miners, then you have not made it clear to me at all what you think the problems with a block size increase are.

For the record, I never touched any alts other than Namecoin and Litecoin.  Namecoin was never about value, and I only dabbled in Litecoin like a hedge more than anything else, although I had little doubt that ASICs would make their way to SCRYPT as quickly as they made their way to Bitcoin (this was before ASICs, and I had no idea they would make it to either near as quickly as they did).  That having been said, as I have previously stated, when the idea of sidechains came about, it was so that non-Bitcoin functions could take advantage of the biggest most secure blockchain without bloating it with non-Bitcoin information.  To that end, I am not against sidechains, and would even say it would have made sense for Namecoin to be a sidechain if it were going to catch on and actually compete with our centralized domain name registry.  However, I have yet to see obvious any arguments that adding complication and storing Bitcoin information outside of the Bitcoin blockchain will actually solve any legitimate problems.

I believe the main reason why we're in disagreement is because I think that the focus should be aimed at solving problems on the biggest and most secure blockchain in the world (Bitcoin), rather than implementing or trying to implement sidechains so we can incorporate a lot of smaller, let's call them ways to exchange different "tokens". The fact that this is driven by a for profit organization which will actually be touching the Bitcoin codebase and that has centralization on it's agenda concerns me greatly.

Hence I'd rather see us all working in unity to solve the problems we're facing on the main chain, rather than anywhere else.

Sidechains allow a lot of really cool functions to be added to bitcoin, without having to actually change bitcoin.  Now the real bitcoin chain doesn't have to take a risk and implement a risky code.  After a long time if a code is proven it can be added, but for now the sidechains can be extensive testnets that are locked into bitcoin but not actually bitcoin. 

Sidechains aren't necessarily an altcoin killer, though they are a pump and dump killer.  If a novel alt coin is born, it can be locked into bitcoin and add value to the bitcoin network.  If it isn't, then it can be ignored. 

In many ways sidechains will separate the phonies from the true innovators.  It is needed. 

These guys making sidechains are extremely vested in bitcoin.  I am sure they all have huge stashes and are doing this to protect their investment. 

By allowing side chains into bitcoin, it makes it soooooo much difficult for an alt to gain a network effect to challenge Bitcoin. 

"Huge stashes" is a bad assumption. Tweet from Jeff Garzik earlier this year:
  "As such, I dare to do what few if any others do:   My #bitcoin balance is 348.006 BTC."

I'm guessing other frequent contributors have this mindset:


And I'm sure lots of early adopters thought:

I agree, I'm not persuaded by any of the supposed technical suggestions pro-offered on this thread.

 :-\

Why 'biggest'?  In my area people struggle mightily to have the biggest tires on their pickup truck.  The theory/running joke is that the motivation for this desire is correlated with psychological issues brought on by sub-par genital mass.  The problem with giant tires on a pickup truck are many due implementation problems, and the inherent tradeoffs start to make the vehicle be actually useful for almost nothing...except perhaps impressing one's like-minded friends who are typically straight and of the same gender making the effort a costly exercise in frustration.

As for security, a blockchain is a blockchain.  It's security is associated with a certain number of factors.  The difficulty of subverting it is synonymous with 'security' in my mind.  That is associated with the hashing power that went into it, the ability of it to build freely and securely, and the amount of distribution.

Sidechains would promote at least the same amount of Bitcoin blockchain hashing since it would be necessary even if/when it is unprofitable to mine Bitcoin alone.  If the Bitcoin blockchain could remain small and tight this would promote distribution which would help mitigate various forms of attack and provide a lot of flexibility in fighting against attacks if/when they do occur.

Please please please understand that those of us who are enthusiastic about sidechains are very much interested in their ability to defend the Bitcoin blockchain and Bitcoin as both a source of monetary value as well as an empowering technology for individuals.  Sidechains are completely about Bitcoin in my mind and I think it likely that the same can be said for most of those who share my enthusiasm for the solution.

I do think it's fair to make some progress in pruning in a manner as described in Satoshi's whitepaper (or a better method of achieving the same effect) before simply tweaking the block size (which is a simple setting made at compile time.)  If this development (pruning) has been de-prioritized in order to focus on newer and better GUI's then it's time to pay the piper.

I'm sure another bunch thought "The potential, if unlikely, future-value of the BTC I hold is enormous.  It would be insane to throw that away for a few peanuts that I don't really need even if it is 10x what I put in."

My own strategy was to recoup my initial investment at 10x so I had 90% left to ride the wave (which I always consider unlikely to actually develop.)  It must be said, though, that I got in after the $30 wave so I was at least aware that such waves were a demonstrated possibility.  Actually I really did think it of value to soak up extra liquidity at the end of 2011 (and it was a hell of a lot easier than actually participating in development.)  Man-oh-man was I well rewarded for my altruism on that one!

Another bunch of people seem to have thought that the best investment was to give the BTC away in an attempt to foster interest in the solution.  Those who did so have my enduring respect for that action.  You and Jeff come to mind.  I myself used Bitcoin almost exclusively to make donations to further causes I saw as valuable in the early parts of my Bitcoin involvement, and the more involved persons who were similarly inclined were a motivation for me to do so.

Actually, that's about the price he is currently paying due to credit card fees, it's just hidden so he doesn't know he's paying it.

For the record, I never touched Namecoin or Litecoin because I was to lazy.  Both of these I thought of as 'good' things and created for basically the right reasons.  Probably...I was to lazy to research them fully.

Namecoin in particular was of high value and I would dearly love to see it implemented on a sidechain.  Going off on a bit of a tangent, yesterday my power was out and when it came back on, every http/https web page was being intercepted on both of my computers and sending me to a page which said that my 'mydish' account was suspended.  I don't and never did have an account with Dish Networks, and my system (Exede) does not even use the same satellites.  This was happening on both my unix box set to use Google's resolvers and my windows box which gets the resolvers via DHCP.  This means that either my router or modem was hijackable, or that Exede's abilities to intercept and modify traffic was compromised.  It actually was not a DNS issue because nslookup worked and going http://{ip} also resulted in a redirect to mydish.com.  The issue cleared up while I was on the phone with tech support and they agreed that it was very bizarre and they claim they had never heard of it.  Anyway, it's scary stuff to those with a basic understanding of traffic shaping and it should be a warning to those who feel that there is no way we'll ever see problems of excessive control down here on the consumer side of the Internet...even in 'free democratic' countries.

Lastly (and back closer to topic), I would point out that to Bitcoin a sidechain should look much like any old user.  It is no more 'storing Bitcoin information outside of the Bitcoin blockchain' than it would be keeping one's private keys private.  To the extent that it is, that is a good thing in my mind.  There is utterly no need to document your purchase of a hamburger in a persistent (forever) way which is replicated on multiple copies of the blockchain and distributed around the world.  Cool as it may be, it costs money and limits flexibility.  It is also something of a privacy issue to be honest.

Thanks for this post.  I am glad that you seem to have a very level-headed perspective on Bitcoin.  Thank you for all that you do for this experiment!

The sentinals have sent Mr Anderson to sabotage our BTC.

Unfortunately, much like paying cash doesn't save consumers the credit card transaction fee covering markups at most establishments, paying in Bitcoin probably won't either, so this will be in addition to the price he is paying due to credit card fees.I think a gift card is a good solution to this.  I also think that using a theoretical (not yet possible based on all I've read in this thread) sidechain would ultimately use just as much data overhead to send the Bitcoin to the same places unless you actually bought hamburgers in two separate instances at the same establishment before said establishment converted back to Bitcoin.  The only way around that issue is to give someone or something else control of your Bitcoin private key.  We've already discussed the possibility of a trustless system that could resolve that, but even then, it would effectively be a mixer, and potentially regulated accordingly.
ETA: Also, the trustless system presumably has less hashpower, so is less secure.  Moreover, cash would be another good way to work around the hamburger issue, and ATMs are even popping up to deal with this, but I'm assuming you want a sidechain that is effectively denominated in BTC either because you don't want to carry cash, which may allow for the gift card option, or you are imaging a future where fiat isn't a thing, in which case a gift card could be denominated in BTC.Sir, it has been too long since you have watched the Matrix.  Mr Anderson and the sentinels do NOT get along.  That will be three demerits, and your punishment is to get off the Internet and go watch the trilogy (one movie for each demerit).  That should give you time to think about what you've done.

True, but with the prospect of increasing value it would probably raise a lot. That is why we so desperately need this change to block size to allow more transactions per block, which will in turn lower transaction fees (as demonstrated in my high frequency trading example) :).

That works out to ~$0.41 per transaction, credit card transactions tend to start at ~$.27 due to minimum "TX" fees for credit card payments. As the amount being transacted increases with a credit card, the fee will increase in proportion to the dollar value of the transaction, this is not the case for bitcoin

In general, I agree with you.  Business investment is usually good for growth, which increases the likelihood of success.  But, you do challenge me to ask how it could develop counter to original principles if businesses dominate bitcoin.  One possibility is that anonymity can be removed through transaction association.  This would require X percent of transactions to go through entities that identify their customers.  Add to this regulatory collection and aggregation of data, and global sharing, something that is pervasive in the financial industry despite our civil rights putting up many decaying barriers in the communications industry, and the probability is difficult to dismiss. 

We're already seeing this phenomenon in one decentralized protocol - internet surfing, where site plugins constantly identify and market to us behind the scenes.  In the 90s, there were proposals to require identification on the Internet.  The regulations turned out to be unneeded, as online marketing naturally grew to fill that gap. 


 

1) The idea of sidechains is that many millions of relatively low-importance transactions could, and usually would, be aggregated into one bitcoin transaction.  I might send one Bitcoin in one transaction to the sidechain peg of some sidechain dedicated to tipping.  I would then perform micro-transactions within the sidechain to my heart's content.  On the other side, a person being tipped would probably rarely bother to cash out into Bitcoin (or a different sidechain.)

This is not very different to what we have today with exchanges where huge amounts of trading happen 'off-chain'.  A difference is that with a decent implementation I don't have to trust the sidechain and I can verify to a reasonable degree that this is so (just like with Bitcoin proper.)  This is not at all the case with non-backed solutions and because of this they regularly steal and probably inflate the currency as well.  The user basically sees a display transmitted out of a black box...an hears all kinds of marketing about how honest to operator is of course.

Ultimately all this does to Bitcoin is to make it seem like there are mostly large players doing important and high value transactions (and thus capable of paying generous transaction fees) where in reality a universe of people are reaping the rewards promised of a solution such as Bitcoin.  This is no loss at all to Bitcoin and I think it is a giant benefit because trying to service the world's exchange economies cannot help but balloon the system to something which doesn't really resemble the original almost at all.  Not only that, but a 'batch mode' system like Bitcoin is inherently disadvantaged for real-time operations as are most burger sales.  Sure there are bandaids but they are kind of ugly in my opinion, and ultimately result in provoking the same non-trustless system constructs that we see in the current crop of non-backed off-chain providers.

2)  Yes, 1 billion transactions is 1 billion transactions.  The point is that there would be many many sidechains which I don't give two shits about.  If I am acting as an infrastructure provider (by running a node or whatever) most of them don't effect me.  I support the chains that I need and care about, and those which have not grown to a point that is uncomfortable for me.  I'll be more than happy to support the Bitcoin core as well if I can.  That's why I'm so keen to avoid having it bloat to the point where doing so is no longer realistic.
Edit:  And because of the peg I don't have to worry about throwing money down a rat-hole when I choose what sidechains I like.  If it fails I can get my money back (again, if properly implemented and I do my due diligence correctly.)  That is one of the biggest reason I've not messed around with alts which, in principle, I've never had anything against even if they do draw interest/value away from Bitcoin.  Sidechains give the benefits I like in well implemented alts without those two disadvantages.

3)  Not sure what you are getting at with 'gift card' but in most mainstream implementations they are highly centralized...as are most mainstream things generally.  Some sidechains might (and probably would) work on a sort of a token model.  Those could be considered micro-gift cards of sorts, though simply one's footprint in the sidechain would also.

Most of my BTC spendings do receive discounts.

1) While I still don't see how this can work as great as you think it can (even if there were a trustless way to do it) unless all of the sidechains are cooperating and you can transfer directly between them, I'm also operating under the assumption that miners/processors in sidechains have income from fees as well.  Ultimately, for bitcoin to get the same fees it would get otherwise, users would have to pay more to use sidechains so that the entities running the sidechains can make their money, too.  Quite frankly, sidechains for transfer of value just don't seem likely to have benefits that outweigh their costs, but that is IMO.

2)  I think sidechains for added benefits would be fine, but pruning and blocksize increases need implemented in bitcoin regardless.

3)  I'm not sure what you're getting at in wanting sidechains instead of bitcoin or cash, so I'm shooting in the dark.  Regardless, 0 confirm transactions are not a concern for small transactions, and waiting for confirmation is not a concern for large transactions, so I'm not sure what benefit you are looking for in sidechains (assuming pruning is implemented in bitcoin to address your [2]).

All of that having been said, I don't feel like we're arguing, but I don't feel like we're making headway in understanding each other, either, and I have no problem with this conversation dropping.

Well, good, and true in the online world, but I'm talking about stopping by a gas station.  Some of them do give discounts for buying with cash, but the majority do not, and for established retailers that do not give a discount for cash, it seems unrealistic to expect a discount for bitcoin, especially if they are paying a processor, even if that processor costs far less than the credit card processor they use.

As much as a hard fork might suck for the commerces and end users I think it is necessary. Bitcoin development needs to speed up.

What happened with the latest LTC hardfork? didnt it contribute crashing the price?

We talked some time ago about implementing a network of micro-payment channels, which is a way to leverage third parties to make trustless instant off-chain transactions between bitcoin users.
This is, imho, a good approach to carry on, together with the parallel increase of the block size limit.
The market will decide if it's better to have off-chain instant transactions or normal transactions...

Best regards,
ilpirata79

Okay, I've finally seen a proposal for side chains that I can at least consider serious. 

The side chain creates coins ex nihilo based on a transaction in the Bitcoin blockchain which locks up BTC in a txout that will not be released without a "proof of legitimacy" from a pegged side chain.  The Bitcoin scripting language is modified to accept a "proof of legitimacy" from a pegged side chain, responding to it by "unlocking" one or more of the "locked" txouts in the bitcoin blockchain, creating two new txouts: one controlled by the entity/key specified in the "proof of legitimacy" and a "change" txout which then becomes part of the "locked" set. 

The crucial missing element is the addition to Bitcoin's scripting language.  Without it, pegged side chains simply will not work.  This is the crucial bit that means secrets (keys) associated with individual main-chain txouts do not need to be transmitted through the side chain somehow.  And this is why a pegged side chain will not work at all with the current Bitcoin infrastructure.

The side chain destroys its BTC when a "transfer" transaction is recorded in its blockchain - the "transfer" transaction producing a proof of legitimacy (with a key) that can be used in an "unlock" transaction in the Bitcoin blockchain.   

The possibility of reorgs, both in the side chain and in the main bitcoin chain, undoing just one side of the transfer-out and transfer-in transactions, creates a lot of security issues and results in transfers (in either direction) taking a long time - essentially twice the time required for a coinbase payment to become spendable, in the best case.  In the worst case, this has to be seen as a whole new attack surface and seriously examined - several weeks to several months of full time analysis by a pro would be required. 

The side chains are assumed to be merge-mined with the main chain, which seems only sensible. 

But it seems that the side chains would have to operate without a mining subsidy (ie, miners live on transaction fees alone) in order for the current bitcoin-supply structure to be maintained. 

So the question becomes, is it worth it for miners to merge-mine one or more side chains just for the tx fees generated by the side chain?  On the one hand, it requires no more hashing infrastructure than they've got now, and the configuration could be truly automatic if it were built into the default client which they base their code on.   On the other, the bandwidth and storage required would be proportional to the number of transactions performed and the number of blocks from the side chain's "genesis block". 

One possibility for compensating miners would be to let them have any coins whose keys get lost by people in the side chain.  The obvious way to do this is to have the side chains be finite in duration -- a few months to a year or two -- and have all coins not transferred out of the chain by its final day distributed among the miners in proportion to the number of side chain blocks they got for the full duration of the side chain.  As additional benefits, when a side chain comes to an end, the storage required (and bandwidth required for setting up a full node) is "pruned" from the history of all Bitcoin transactions, and Bitcoin itself would become less deflationary as coins are less likely to be permanently lost. 

Anyway, this seems possible, but it would need to function for a long-ish time on testnets and in altcoins before it became reasonable to do with Bitcoin itself. 

Do any of the proponents of side chains have a working testnet implementation?

Can another testnet be created?

for example, create a subnetwork with different rules to the main network, splitting the network in two and exchanging the coins between the high TPS network and the original Low TPS network.

We exchange the the coins between the network using a signature hash from the wallet, marking that someone decided to turn the coin into a high TPS coin marking it for exchange to the new network.

This way only people interested in doing a lot of transactions can apply and there should be a way to transfer the coin back to a low TPS network. The people with lots of hard drive space can try out the new network and function as nodes.


This will create a new market and exchange, the hashes of the high TPS network can be integrated into the low TPS network as a single transaction, a high priority transaction that gets taken care of first before all other transactions to prevent the network from failing.

The new network will be a little less secure by probability but will be equally secure because it will use the same mining network but simply at a faster pace with a lower hash target.

I've learned over the years that 'nothing is free' and to be highly suspect of things which are.  Initially at least I would only use a sidechain which entailed some sort of a fee.  As always, I'd want to be able to see exactly what is becoming of those fees and would expect the sidechain to be completely transparent in all ways and in this way in particular.  I would expect that if there was an excess which was not refunded to users it would be going toward support of the Bitcoin core.

I expect that one thing which will develop would be that organizations run their own sidechains.  In this case they can make an economic justification for subsidizing costs.  I probably would use these types of sidechains as well as needed, but here again I would even more strongly favor this class of sidechains based on their demonstrable support of the Bitcoin core (in it's original decentralized and non-controlled form.)  This would, in fact, be a big factor in my choosing to do business with them at all.


Ya, well, don't hold your breath on that one.  Voice of experience based on years of waiting and seeing a giant nothingburger.  Maxwell did make an oblique reference to 'working on something better' probably at least a year ago.  Possibly that was sidechains and if so I'd strongly agree that it is a more promising avenue.  In the mean time the cost of bringing up a full node continues to build on the back of a giant pile of absurd and inconsequential garbage.

One fairly safe method which occurred to me would be a massively POW'd optimized re-base.  As in half the hashing power working on the best solution for at least a quarter, and maybe with the results inserted into the codebase.  This, however, was never part of the design of Bitcoin.  Maybe it will be on a sidechain.

I have not seen anymore news about this. Anyone have any links to further discussion on it? Sorry if I missed another topic on it but I don't think I saw any floating around the first few pages.


Thanks :) !!!

Yes, however I don't think that a lot of people utilize the testnet nor do a lot of people mine on it (and those that do, don't have the same economic incentives that people who mine on the Bitcoin blockchain have).

I don't think that forking only the testnet would yield any additional information that would apply to Bitcoin

It seems Bitcoin community can't reach consensus on this issue, a lot of people against the proposal.

There seem to be a few people who want some OTHER algorithm for increasing the block size, but I'm hearing very broad consensus that we do need a hard fork to increase the size.

That is progress.

I'll be running some experiments using actual blockchain data to see where the current code breaks; if it can already handle 20MB blocks then I'll work through the details to propose a hard fork (write BIPs, write code, write tests, ...).

"How often do you get the chance to work on a potentially world-changing project?"

Every day presents another opportunity...thank you for your work Gavin.  I'm guessing Reid, Eric, Jerry and the rest of these boys have already reached out to you about evolution of the blockchain...
http://blogs.wsj.com/moneybeat/2014/11/17/linked-in-sun-microsystems-founders-lead-big-bet-on-bitcoin-innovation/ (http://blogs.wsj.com/moneybeat/2014/11/17/linked-in-sun-microsystems-founders-lead-big-bet-on-bitcoin-innovation/)

Organizations who are serious in what they do do what are called 'war games' to facilitate effective development.  The excersizes are as realistic as resources allow.  Done correctly, the 'opfor' (opposing forces) team has every method at their disposal that a real opponent might have.

In Bitcoinland this would (or should) take the form of a testnet where opfor has gear installed which can do deep packet analysis, filtering, and packet manipulation.  To be fair, traffic analysis of transit should dictate what types of traffic operations are allowed.  So, say, if real-world traffic is routed through a carrier who could conceivably be subject to legal mandates to perform certain operations, the opfor team would be allowed to employ the same.

As best I can tell there is no ability or desire to include this level of rigor in the development of Bitcoin.  As a holder I must factor this into the confidence I have in the solution.

You don't seem to have the "jump in and help" mentality needed to participate in a radically open project like Bitcoin.

As I have said repeatedly in the past: you don't have to ask anybody for permission or advice. You are part of the process-- make it happen.

Personally, I don't know nuthin about "opfor teams" ...  (but am the creator of the Bitcoin testnet, so am offended by you saying there is no ability or desire to bring more testing rigor to Bitcoin).

Thank you Gavin for responding to this topic!


Your logic on this is very sensible. I feel like anyone who is "going against" a hard fork is right to question it if questioning it intelligently, and it is nice to see your response to those questions. It can be very frustrating to see some of the local clowns chiming in and we agree they can be offensive.



Everyone,

I am not sure of most people's backgrounds here on this forum, but software can almost always be improved upon and is necessary to sometimes change. Any fellow coders here could think about a time they made a program or coded a module, then later learned a different way of going about it that makes it run faster or has less code to complete the same function, or added functionality is coded to deal with other factors or upgrades. They can also think about if something is needed in the business world or a new demand arises how something will fill that demand, once the Iphone was out did they keep making the exact same Iphone or was it constantly changed as time went on? Do companies who always do the same thing always stay in business? Look at the auto industry and how hard they were going to crash unless the government stepped in for some of them. Why did the government step in and give them bail out money? Because they didn't change with the times, they were still making gas guzzling trucks and SUVs while foreign companies were bringing over more fuel efficient smaller cars. Eventually after the bail out they started to change and get their act together.


TL:DR
Do we all want to wait until bitcoin needs a "bail out" before something gets changed in the code? Or do we analyze potential future problems and correct them before something bad happens?


Thanks :)

Good discussion about network scalability concerns :

https://www.youtube.com/watch?v=FEliXGr5Bl8

Peter Todd does have some valid concerns, although I believe he exaggerates a bit by suggesting 10x more transactions might require 10x more centralization, but I also like how he correctly points out that raising the block limit is the easy solution and we need to ultimately create other solutions(Like the lightning network) for Bitcoin to remain sufficiently decentralized.

This being said, I think a 20MB bump while other solutions are tested may be a fine adjustment as long as we don't simply adapt the habit of constantly increasing the block size limit.