53

What are Channel Factories? In short, Channel Factories are payment channels that can be used to create more payment channels. That sounds weird, but it's really pretty simple: In a regular payment channel, you always have a transaction signed by all participating parties that's ready to commit the current channel balances to the block chain. For example,...


20

Satoshi Nakamoto addressed this issue in the original crypto forum thread. Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to ...


20

Please note, this answer was written in Februar 2015. The debate has significantly evolved since then, but I haven't gotten around to updating this answer, yet. I'm sorry, this kinda turned out less brief than it started. TL;DR: Very briefly, it is an issue of opposing ideologies: Proponents wish to provide a common good to everyone and believe the ...


17

I am basically doing the same thing for bitcoinmonitor.net. I have a database of addresses to monitor and get notifications from bitcoind for any incoming transaction. I maintain a patchset for bitcoind which allows setting an url which will be called with any incoming unconfirmed transaction, including transaction details in a json object. Also for any new ...


16

It's not a silver bullet solution, but it's a really good start. As Gavin Andresen has said, Segregated Witness is a poor name. The 'segregated' part of the name is there to denote that there is separation being done. The 'witness' portion of the name comes from the fact that digital signatures are often time called witnesses. Segregated witness splits ...


15

I don't know of any formal studies into this, but here are a few points to consider: It is generally assumed that in the future not every user will run a full network node. For a "supernode" of which a few thousands will exist in the world, the hardware requirements will be bearable - Even if we take the 52TB/year figure at face value and ignore ...


14

The blockchain already has reached nearly 1 GB to download and store, The proposal in Satoshi's paper does not reduce the download requirements, only the storage requirements (see this post to the bitcoin-dev mailing list). Unless you are able to rely on some trusted third party, you still need to download at least all of the block headers. If you ...


12

We are a long way away from VISA scale transaction volume (>4K transactions per second) however there are some methods for Bitcoin to deal with the data on that scale Remote blockchain. In the current implementation of the mainline client, every client downloads and store a complete copy of the blockchain. This is the best way to boostsrap the bitcoin ...


12

There are two problems with scaling P2Pool: The sharechain difficulty goes up as the pool gets bigger to maintain the rate of finding shares at around every 10 seconds. If everyone was using P2Pool then the difficulty of finding a share would only be 60 times less than the difficulty of solo mining, and so varience would go right up. As more miners join, ...


12

Two issues with Bitcoin's design Scalability of everyone checks everything Bitcoin is a gossip network: P2P nodes connect mostly randomly to each other and pass-on new information to each other as they receive it. That way, information floods through the network quickly: each step further increases the nodes that were informed exponentially (until most are)...


11

Best estimates on effective blocksize with SegWit are 1.6-2.0 MB. Current transactions/second possible are around 3 tx/s. Given that the effective increase is 1.6 - 2.0x, the transactions/second are also the same multiple giving us somewhere around 5-6 tx/s. The second question is harder to answer. There's a reason I wrote "effective blocksize" since ...


11

What does the UASF proposal entail? The UASF proposal is an extension of BIP9 that allows soft-forks to specify a mandatory activation time. If miners have not started signaling support by this time, they must start to signal. Any blocks not signaling support for the soft-fork after this time are rejected. BIP148 is an instance of the UASF proposal that ...


9

The current block size limit is 1MB, but this is likely to be changed in the future. Transactions are about 500B, so the current limit is 2000 transactions per block, or about 3 per second.


9

There are three parts to this: The miners have to verify each transaction that will go into the block and all transactions that are in the block they will be basing their own work on Each client needs to look for transaction destined to their own addresses, which can get hard if you have a large address pool Since all transactions are broadcast the network ...


9

No. They can increase scale, but that is not what they are good at or intended for. Before giving a longer answer, let me first talk briefly about the difference between scale and scalability. Increasing scale means increasing the throughput or number of participants to the system. It's very easy to achieve (decreasing the time between blocks, or ...


8

It will not scale (to mass-market adoption) if you want to put all transactions directly into the blockchain. There needs to be a hierarchy of services built on top of the core protocol. In addition to improving scalability, they can also offer all kinds of features that some people need, such as reversible transaction, instant (no-confirmation) transfers, ...


8

1) It's not clear why you think every client having to download the entire block chain is a scalability problem. Pruning currently doesn't take place but it should eventually be possible in theory. Storage space is growing at a much faster rate than Bitcoin is. 2) To validate a new transaction, the only transactions you have to look at are the inputs to ...


8

You could potentially be asking the wrong question. This has been brought up in discussion in #bitcoin-dev on Freenode a few dozen times, and eventually it comes down to the fact that having to wait 30 minutes or more for a transaction to clear as valid (vs several seconds on a credit card at a working terminal) will hinder Bitcoin adoption in the wild. A ...


8

As mentioned in the page you linked, it is a bit awkward to use Bitcoin-qt's accounts system. Don't bother with accounts as they are intended to be a way to manage your money within the program. When you're having thousands of accounts you are already doing it wrong. So how do you structure a service to do this? Handle accounts completely on your database. ...


7

There are actually a number of possible threat models to evaluate. But since you asked about overwhelming "the network", I'll look only at attempts to overwhelm the network as a whole and not talk about attempts to overwhelm a few nodes. (You can overwhelm a node with invalid transactions, but that won't hurt the network as a whole.) First, nodes will only ...


7

Bitcoin transactions usually carry change, and to increase privacy and security, it is certainly no worse to generate a new address every time for receiving change than to reuse old addresses. Details maybe belong into their own question; however, it is well within the realm of reason to expect a future where most Bitcoin transactions include two new ...


7

If I understand correctly, there is a second Merkle tree of witnesses mirroring the transaction data. The witness tree's root is committed to in the coinbase, but otherwise this second tree lives outside of the block. That is my understanding as well. Don't the witnesses still have to be relayed to other nodes to validate? Only nodes that actually ...


7

A lot of people who accumulated thousands of coins in the early days spent them on silly things or cashed out during the 2012 bubble. Lazlo for example, spent 10,000 bitcoins on two pizzas. Nobody knew that bitcoin would rise to the prices we briefly saw in 2013 or that we have today. The same thing will happen again, people have a price and will very ...


7

The throughput in Bitcoin is not defined in transactions per second, rather indirectly, via block size limit. What matters in the size of transactions in bytes. The more complex the transaction is (complex meaning more inputs and outputs, long scripts), the more space it takes. A typical full (nearly 1 MB) block in Bitcoin includes around 2000 transactions, ...


6

The limitations on Ripple scalability are substantially the same as the limits of Bitcoin scalability. There are various minor differences, but they don't significantly change the picture. Ripple already has some scalability features that Bitcoin doesn't have yet, but Bitcoin can easily add them when it needs them. For example: Ripple nodes don't need to ...


6

Your transactions would be given the lowest priority as they are not paying fees, also if anyone is actually marginally successful in spamming the system it is entirely possible that the larger pools will simply not take their transactions, in fact some pools do filter out some transactions. This thread shows some of the restrictions that some mining pools ...


6

This is explained in Satoshi's original paper: Basically, the block hash does not contain the hashes of the individual transactions, rather it contains the root of the Merkle tree of the hashes. Once all the bitcoin outputs of a transaction have been fully spent, then there is no need for the original transaction, and hence its branch is chopped off from ...


6

Generally speaking, BIP37 bloom filtering SPV has atrocious scaling though it is hard to say exactly how poor it is in the real works. Every peer must sync the entire block chain from the last they had contact with the network, in the worst case this is approximately 50GB. The node must load every single block from disk, filter it to the clients ...


6

The obvious one would be side chains, the idea being that the transactions on the side chain would be off the main chain. Most other scaling solutions are either on-chain or centralized. For example, segwit and block size increases are on-chain and using a service like coinbase to move coins off-chain are clearly centralized.


6

You are correct that transaction fees per block are much smaller than block reward, but they are still significant and rising: https://www.smartbit.com.au/charts/transaction-fees-per-block Recently the average has passed 0.5 BTC per block. With a 50x rise (easily obtainable if bitcoin use becomes mainstream in certain sectors) the reward would be 25BTC per ...


Only top voted, non community-wiki answers of a minimum length are eligible