You’re thinking too small. It’s not about the practicality of storage, it’s about a simple fact: transaction history need not be perpetually kept to guarantee security. Prior to MW, we thought that this was the case. There is no fundamental reason why we need anything more than the UTXOs to guarantee security of the network, MW proves that. That’s what makes it the future.
Another consideration: throughput is constrained by block size in both Bitcoin and Monero. In MW, throughput is constrained by network bandwidth. The entire blockchain is one big block with only UTXOs in it. You can have an unlimited block size and it still only scales with the UTXO set if the nodes can all talk to each other fast enough. You can have unlimited throughput at layer 0 finalized directly on chain.
MW gives us pure money without storing anything about historical state. But it doesn’t give us programmability. Right now we have to store some historical state in order to get programmability, but I see no reason why this is a fundamental requirement, maybe a cryptographer or information theorist around here can correct me there. All we need is that breakthrough and we have the foundation to build the perfect money.
Personally, I think the truth lies in the middle. I think having full history for purchasing coffee is not only wasteful of space clogs the blockchain (imagine 6 billion people adding 3 coffees a day to the block chain over 50 years). My back account keep track of all transactions for a few years and I’ve rarely needed more, but I absolutely do need a transaction history for budgeting and taxes. So a hybrid approach where important or big ticket items have full transaction history (until you ask to prune to a MW), and smaller ticket items can be in smaller MW subaccounts of different categories is the best of all worlds.
You don’t need the entire network to store your transaction history, you can do that yourself. The bitcoin network doesn’t store them as a service to you, it stores them because it has to for the security guarantees it makes.
Actually both since it is an important way to avoid and resolve payment disputes. Private ledgers mean nothing in a payment dispute. It’s so important that without it, for large payments everyone will have to involve a “trusted third party” to keep everyone honest. It’s the reason why good cashiers never put payments in the cash register until the customer leaves…without this “trick” it’s easy to be scammed. It’s the whole reason double entry accounting exists. MW also doesn’t completely fix the issue of exploding blockchains. With 6 billion people on MW (arbitrarily chosen number) and each person having multiple wallets and wallets being lost and new people coming into MW regularly due to new births the number of wallets will explode. There needs to be a regularly get rid of abandoned and locked out wallets. Hard forks like Seraphis are a good way to find out who still has a wallet and eventually clear out the old wallets, but you can’t keep doing that for a stable money supply. I’ve stated before, I fully support transaction fees being partially based on how big your blockchain footprint is as long as you can “close the books” and compact your footprint. I’m also open to fair schemes dropping abandoned wallets (e.g. calculate a “fee” based on blockchain footprint and time of last access. If the “fee” is less than the amount in the wallet, then do nothing. If it is greater than the amount, then the wallet can be pruned.).
In MW, if you keep a copy of every transaction you’ve ever signed that has been broadcast, their signature is in it as well so it is trivial to prove payment was made. You don’t get to store it for free forever on other people’s hard drives if they turn around and spend the output, but you’re free to keep a ledger of your own payments and they are provable.
Cahsiers have to put the money in the register to get change.
You make a good point about the ever growing blockchain of unspent outputs in lost wallets. And with an ever growing supply like grin or Monero, this will ultimately grow to infinity. The curve is very different than linear growth with the size of all combined transactions every block, so nowhere near as bad but it’s still there. Pruning ancient ones… I don’t know that I like that. We do pay a cost to continuous record on the blockchain, and that is in the form of inflation of the supply forever. It acts as a tax to use the blockchain to store our wealth, it doesn’t go to every done but it does go to miners. We even pay on proportion to the value we get, since every unit is debased the same amount.
I was trying to come up with a scheme by which you could prune transactions if they’re too old, but allow for someone to broadcast the unspent tx again to get it included again, but we run into the problem you mentioned, once it’s gone from the ledger there’s no previous transaction to reference that it is valid. You can show the signed transaction but there’s no way yo know if it was valid when you signed it.
Currently MW is Andrew Poelstra’s modification to it, which includes block kernels, so there is always proof that an old transaction happened. This defeats the memoryless purpose of MW the way it was initially designed, it was done to give MW programmability, and it does solve this problem of the entire record being gone, but it leaves us with an ever growing blockchain, albeit a much slower growing one because you only need the last unspent output and the transaction kernels from it’s history rather than the whole set of them from every block. Like I said above, I think we can get programmability without these kernels, but we wouldn’t be able to prune ancient unspent outputs while giving the owner a way to prove they existed if in fact the wallet isn’t dead, and that is unsound if you want to be able to store value indefinitely, pruning ancient wallets in an irreversible way is just not an option.
It saves no bandwidth. And yes, it does make for infinite transaction throughput, or more accurately, throughput is not constrained by block size. Understand, this isn’t some theory I came up with in my head, this is a core feature of the original MW paper that everyone involved already knows and is well understood, I will try to explain it to you so that you understand.
What is the limiting factor for bitcoin transaction throughput? It’s block size, right? And why is block size constrained? Because you have to keep all of them forever. Having to only keep unspent transactions would mean that you could scale throughput without having to worry about block size at all, the thing that grows the blockchain is only the number of outputs created in all the transactions being put into that block. Sweeping multiple outputs into a single output actually shrinks the size of the blockchain. This means you could have any size blocks you want, you can put any number of transactions in a block you like, they don’t take up space forever, only while the outputs are unspent. Eventually you reach an equilibrium where the size stays within some range as outputs are created and combined constantly every block. This might be large, but the point is it doesn’t grow perpetually and so the size of the blocks don’t matter at all, and therefore the number of transactions per block doesn’t matter.
This changes the limiting factor for transaction throughput. The limiting factor then becomes how fast you can propagate transactions across the network, how many transactions can reach all miners within the block time to ensure that they are mined in the next block. We can even go further and allow for them to reach some miners within the next block and all miners within a set number of blocks, say 2, and be OK with some transactions waiting for 2 blocks to be mined, we do this already when blocks fill up in bitcoin. So throughput will be limited, but it will be significantly larger, by orders of magnitude.
@mister_monster @snitchy_asc I had the same skepticism about monotonically increasing blockchain sizes.
I wish I had looked at storage and bandwidth curves a lot earlier.
Long term storage size is no longer a concern I worry about.
You’re thinking too small. It’s not about the practicality of storage, it’s about a simple fact: transaction history need not be perpetually kept to guarantee security. Prior to MW, we thought that this was the case. There is no fundamental reason why we need anything more than the UTXOs to guarantee security of the network, MW proves that. That’s what makes it the future.
Another consideration: throughput is constrained by block size in both Bitcoin and Monero. In MW, throughput is constrained by network bandwidth. The entire blockchain is one big block with only UTXOs in it. You can have an unlimited block size and it still only scales with the UTXO set if the nodes can all talk to each other fast enough. You can have unlimited throughput at layer 0 finalized directly on chain.
MW gives us pure money without storing anything about historical state. But it doesn’t give us programmability. Right now we have to store some historical state in order to get programmability, but I see no reason why this is a fundamental requirement, maybe a cryptographer or information theorist around here can correct me there. All we need is that breakthrough and we have the foundation to build the perfect money.
Personally, I think the truth lies in the middle. I think having full history for purchasing coffee is not only wasteful of space clogs the blockchain (imagine 6 billion people adding 3 coffees a day to the block chain over 50 years). My back account keep track of all transactions for a few years and I’ve rarely needed more, but I absolutely do need a transaction history for budgeting and taxes. So a hybrid approach where important or big ticket items have full transaction history (until you ask to prune to a MW), and smaller ticket items can be in smaller MW subaccounts of different categories is the best of all worlds.
You don’t need the entire network to store your transaction history, you can do that yourself. The bitcoin network doesn’t store them as a service to you, it stores them because it has to for the security guarantees it makes.
Actually both since it is an important way to avoid and resolve payment disputes. Private ledgers mean nothing in a payment dispute. It’s so important that without it, for large payments everyone will have to involve a “trusted third party” to keep everyone honest. It’s the reason why good cashiers never put payments in the cash register until the customer leaves…without this “trick” it’s easy to be scammed. It’s the whole reason double entry accounting exists. MW also doesn’t completely fix the issue of exploding blockchains. With 6 billion people on MW (arbitrarily chosen number) and each person having multiple wallets and wallets being lost and new people coming into MW regularly due to new births the number of wallets will explode. There needs to be a regularly get rid of abandoned and locked out wallets. Hard forks like Seraphis are a good way to find out who still has a wallet and eventually clear out the old wallets, but you can’t keep doing that for a stable money supply. I’ve stated before, I fully support transaction fees being partially based on how big your blockchain footprint is as long as you can “close the books” and compact your footprint. I’m also open to fair schemes dropping abandoned wallets (e.g. calculate a “fee” based on blockchain footprint and time of last access. If the “fee” is less than the amount in the wallet, then do nothing. If it is greater than the amount, then the wallet can be pruned.).
In MW, if you keep a copy of every transaction you’ve ever signed that has been broadcast, their signature is in it as well so it is trivial to prove payment was made. You don’t get to store it for free forever on other people’s hard drives if they turn around and spend the output, but you’re free to keep a ledger of your own payments and they are provable.
Cahsiers have to put the money in the register to get change.
You make a good point about the ever growing blockchain of unspent outputs in lost wallets. And with an ever growing supply like grin or Monero, this will ultimately grow to infinity. The curve is very different than linear growth with the size of all combined transactions every block, so nowhere near as bad but it’s still there. Pruning ancient ones… I don’t know that I like that. We do pay a cost to continuous record on the blockchain, and that is in the form of inflation of the supply forever. It acts as a tax to use the blockchain to store our wealth, it doesn’t go to every done but it does go to miners. We even pay on proportion to the value we get, since every unit is debased the same amount.
I was trying to come up with a scheme by which you could prune transactions if they’re too old, but allow for someone to broadcast the unspent tx again to get it included again, but we run into the problem you mentioned, once it’s gone from the ledger there’s no previous transaction to reference that it is valid. You can show the signed transaction but there’s no way yo know if it was valid when you signed it.
Currently MW is Andrew Poelstra’s modification to it, which includes block kernels, so there is always proof that an old transaction happened. This defeats the memoryless purpose of MW the way it was initially designed, it was done to give MW programmability, and it does solve this problem of the entire record being gone, but it leaves us with an ever growing blockchain, albeit a much slower growing one because you only need the last unspent output and the transaction kernels from it’s history rather than the whole set of them from every block. Like I said above, I think we can get programmability without these kernels, but we wouldn’t be able to prune ancient unspent outputs while giving the owner a way to prove they existed if in fact the wallet isn’t dead, and that is unsound if you want to be able to store value indefinitely, pruning ancient wallets in an irreversible way is just not an option.
@mister_monster No, MW does not make for infinite throughput.
It saves some disk space and some bandwidth. It’s a good tool for certain use cases.
It is not at all clear to me that those use cases are central to the problem of a Peer to Peer Internet Cash System
It saves no bandwidth. And yes, it does make for infinite transaction throughput, or more accurately, throughput is not constrained by block size. Understand, this isn’t some theory I came up with in my head, this is a core feature of the original MW paper that everyone involved already knows and is well understood, I will try to explain it to you so that you understand.
What is the limiting factor for bitcoin transaction throughput? It’s block size, right? And why is block size constrained? Because you have to keep all of them forever. Having to only keep unspent transactions would mean that you could scale throughput without having to worry about block size at all, the thing that grows the blockchain is only the number of outputs created in all the transactions being put into that block. Sweeping multiple outputs into a single output actually shrinks the size of the blockchain. This means you could have any size blocks you want, you can put any number of transactions in a block you like, they don’t take up space forever, only while the outputs are unspent. Eventually you reach an equilibrium where the size stays within some range as outputs are created and combined constantly every block. This might be large, but the point is it doesn’t grow perpetually and so the size of the blocks don’t matter at all, and therefore the number of transactions per block doesn’t matter.
This changes the limiting factor for transaction throughput. The limiting factor then becomes how fast you can propagate transactions across the network, how many transactions can reach all miners within the block time to ensure that they are mined in the next block. We can even go further and allow for them to reach some miners within the next block and all miners within a set number of blocks, say 2, and be OK with some transactions waiting for 2 blocks to be mined, we do this already when blocks fill up in bitcoin. So throughput will be limited, but it will be significantly larger, by orders of magnitude.