Anything that reduces any of the outputs of a transaction already broadcast through the network is by definition a double spend. This would essentially invalidate instant acknowledgement by the P2P network, and force everyone to wait for a block confirmation, crippling many services in the process.
To increase the fee, you have to either reduce an output or add an input. Reducing an output is not an option, so you'd have to add an input, which at that point is essentially a new transaction replacing the earlier. That is a big change from today's bitcoin IMHO.
The version that that only allows adding additional outputs (and therefore inputs) has already been discussed for years and maybe implemented. So it is certainly possible (the original question). Another possible approach is child-pays-for-parent. In this case you respend your change with a higher fee. The fee credit counts toward the entire tx chain, causing the parent be mined faster. That there is the solution, and it does not require any changes to the protocol. It only requires that mining pools add in more inteligence to look at a chain of transactions to determine the total fee structure the chain offers. This is easy to do. Miners probably have not implemented this because it is not commonly practiced. So it just needs to be something they add to their implementation. As I said before though, I consider all of these inevitable as mining continues to become more competitive (especially after 1+ more block halving). If you are relying on zero confirm transactions, you better have a plan for what you're going to do when they break.
Zero confirm transactions are fine provided that the transaction is valid, all the inputs are already confirmed and it has propagated through the P2P network. Once that has happened it requires collusion with the miner who fines the next block to reverse. That is hard... |
|
|
|
With fees, I see no problem with the market sorting it out. Except - when someone wants to minimize the fees of his own transactions, some transactions will suddenly take forever to confirm. So a possibility to raise the fee on a nonconfirmed transaction would be great. Has anyone suggested that, or is it unpossible technically?
Yes it is called replace by fee I'm not sure. With replace by fee, you can change other things in the transactions (like outputs), no? This makes double-spending much easier. I'm not sure wether "increase fee" can even be done, since it also requires changes to the outputs (and maybe inputs). I see replace-by-fee as a very bad idea currently. First off, I think it's inevitable, as there is nothing that would make a miner want to not accept a higher fee. That said, you can make a restricted version that doesn't allow reducing any outputs. You would have to add an additional input to pay the higher fee. Anything that reduces any of the outputs of a transaction already broadcast through the network is by definition a double spend. This would essentially invalidate instant acknowledgement by the P2P network, and force everyone to wait for a block confirmation, crippling many services in the process. To increase the fee, you have to either reduce an output or add an input. Reducing an output is not an option, so you'd have to add an input, which at that point is essentially a new transaction replacing the earlier. That is a big change from today's bitcoin IMHO. |
|
|
|
Those sexy diagrams are a helpful addition. I've always enjoyed the ongoing romance of Alice and Bob. They have a true romance, but Eve is always trying to spoil it. justusranvier, thanks for sharing and explaining this work in this thread |
|
|
|
|
Re: The centralization discussion
I think it is important to remember that the most important aspect of bitcoin that needs to remain decentralized is mining (not pools), and that block size has no impact on miners since they already operate through pools.
For bitcoin to succeed, it needs to be used and managed directly by individuals. Not through 3rd party services. If bitcoin is primarily used through 3rd parties it will go the way of gold and eventually be co-opted and destroyed.
For bitcoin to be used directly P2P nodes need to be able to scale to much higher transaction throughput than VISA does today and maintain a massive history. I do not believe this is possible in a fully distributed manner. It will require centralization & specialization to the point where even companies such as coinbase may not maintain their own nodes but subscribe to node services run as cloud services.
But this is OK as long as mining stays distributed and there are some small number of public service nodes that monitor the full history and people trust to flag issues (think an MIT node, an EFF node, an Isle of Mann node, etc).
The distributed security mechanism of bitcoin (i.e. mining) was really the novel invention satoshi came up with. This distributed security is what bitcoin is. As long as it remains distributed we are OK. The other aspects (i.e. nodes) probably need to become more centralized if we want bitcoin to be used directly at a massive global scale.
|
|
|
|
I'm for Gavin's 20MB increase. But if I was doing it, I'd propose actually building a real supply/demand curve so economic analysis actually works. The reason it doesn't work today is because additional demand (price) cannot ever create new supply (space in the block).
So I'd do it by allowing txn fee paying blocks to be located beyond the limit (its now a "soft" limit). In other words, if your txn pays 0uBTC fee it can be located in the block at 0-20MB, if 1uBtc located at 0-21MB, if 2uBTC located at 0-22MB, 3uBTC located at 0-23MB, etc (or some other pricing curve). So supply (space in a block) can actually increase as demand increases.
You might be able to look at historical block size vs price information to actually price this... it does not need to be perfect since an error will just move the graph a bit. The biggest concern would be if exponential BTC price increases (vs fiat) makes the minimum fee way too high. In that case, we are no worse than today's proposal.
I like this proposal a lot. High-priority non-fee transactions that consume older coins are suppose to be just that, free and gain priority access to a block. Today's situation is even if your transaction has enough priority to qualify for free processing, they often take hours to confirm since most minors do not pick high priority transactions without a fee. This completely defeats the purpose of having the priority system at all. Reserving a front space in each block for high-priority non-fee transactions does two things: 1) It would ensure that high-priority transactions are processed in a timely fashion 2) It would encourage more competition from low-priority transactions and possibly increase the fees they need to offer to be processed quickly This would shift transaction fees more towards for profit services that are built on top of bitcoin and away from individual wallet users. I would consider this to be a good thing. Anyone on this thread have contact with any of the core developers? Have they considered it? If not how could zerg propose it (provide people here also think it makes sense...) |
|
|
|
Winklevii are probably foaming at the mouth after seeing these shares go for over double market value. Probably on the phone with the SEC right now lol.
Well the twins should get off the pot and make this happen. They've been talking about it for what 2 years? If GBTC has been able to find an approval path, what is the holdup for COIN? Worse, it seems that other potential funds have taken a wait and see approach with COIN and decided to let them pave the way and follow. But if COIN does not execute that just stalls the market. The price action on GBTC is demonstrating the real investment potential that OTC markets could unlock. This needs to happen and faster. BTW, which brokers have people had success at least putting orders in? I have schwab and they are providing quotes, but are not offering trades yet. Actually GBTC has taken a path that doesn't require approval. They're claiming an exemption from securities regulation under Reg D which means they're only allowed to take funds directly from accredited investors and the reason the shares are subject to a restricted period. The holdup for COIN is entirely on SEC's part. The commission has the authority to simply not grant approval for as long as it wants to. Thanks for the explanation, if this is the case then the SEC policy doesn't seem to make a lot of sense. After accredited investors purchase shares and hold for 1-year, they are now selling those shares to non-accredited investors on the OTC market. Which means that non-accredited investors are buying the fund in the end. The only difference for GBTC is that only accredited investors can initiate the creation of shares, but anyone can trade them. If I'm understanding this correctly is seems absurd. |
|
|
|
Winklevii are probably foaming at the mouth after seeing these shares go for over double market value. Probably on the phone with the SEC right now lol.
Well the twins should get off the pot and make this happen. They've been talking about it for what 2 years? If GBTC has been able to find an approval path, what is the holdup for COIN? Worse, it seems that other potential funds have taken a wait and see approach with COIN and decided to let them pave the way and follow. But if COIN does not execute that just stalls the market. The price action on GBTC is demonstrating the real investment potential that OTC markets could unlock. This needs to happen and faster. BTW, which brokers have people had success at least putting orders in? I have schwab and they are providing quotes, but are not offering trades yet. |
|
|
|
Multiply that by 100M and pretty soon you're making real money.
Here's an example of a money protocol that allowed for "only" 3%/year worth of double spending:  never realized it's that bad unless saw the graphs like this one Even this chart is misleading, since it is linear it does not show how the dollar continued drop over the past 30 years. Instead it looks relatively flat. The log chart shows how this process is continuing. Even though the dollar has already lost 98% purchasing power, dropping to 99% is really another 50% lose, not the 1% drop shown on this chart. |
|
|
|
Great explanation.
So I see we really have 4 types of node's:
1. Archival
2. Pruned
3. UTXO hash started
4. SPV
As for smartphones, I just got my Samsung S6 with 64GB. Could've have gotten the 128 GB. Plenty of space for even an archival node. So storage isn't an issue anymore. Also, as far as download and verification of the blockchain, to save bandwidth, you could download on your home pc and transfer to the phone later. This could be done for a pruned chain as well. As for relaying tx's and blocks, most of my day is at work connected to the office router. With the blockchain loaded, you could act as a temporary full node. Full nodes work fine with just 1GB of RAM (with some swap) and definitely with 2GB. With all the phones out there owned by Bitcoiners that might be willing to do this we could logarithmically increase the number of full nodes and thus security of the network significantly, I'd think.
I like the 4 types categorization. Today we have 1, 2 & 4. Adding UTXO hashes would give another method to participate. A Galaxy type smartphone has the storage space to run a full node (64GB or 128GB). It also has enough memory today, but probably not in a couple years. The UTXO set today is 650MB and an S6 has 3GB memory (as in RAM). So it would work today, but expect to stay plugged in to the wall most of the time... Smartphone & tablet memory (RAM) is not scaling much going forward. Desktop PCs today generally ship with 4GB or 8GB, mobile clients need less and most roadmaps I've seen have 3GB for the high end for a bit and then maybe 4GB, point is RAM content is definitely not doubling every two years. More RAM means more DRAM bits that need refreshing, which means worse battery life. So in a couple years I wouldn't be surprised to see the UTXO set no longer fitting into a high end smartphone. |
|
|
|
SPV clients don't normally carry the UTXO set around in their memory, correct?
Right the "UTXO client" we've been talking about is a different animal with a stronger security model... SPV clients only request information on transactions involving addresses that they care about (well actually they ask for a range of address to preserve some level of anonymity). Using the merkle tree an SPV is able to link a single transaction up the tree to the block's header. Since they do maintain the header chain of the longest blockchain, this mechanism allows them to verify for themselves the validity of a transaction. However since they do not keep data on other addresses or transactions, they are not able to verify blocks or other new transactions on the P2P network. Think of them as leaves to the network. SPV clients take information, but do not contribute to the P2P network's security in any way, they are leaches. 1) "Archival nodes" [Full nodes operating with full history] &
3) "Pruned nodes" or "UTXO hash started nodes" [Full nodes operating without full history]All full nodes maintain the full UTXO set. This is what enables them to verify blocks and new transactions on the network. The UTXO hash clients mentioned before are still full clients. The only difference is how the node obtains the current UTXO set from the longest blockchain. One method is to download and process the complete history (i.e. 1 - Archival nodes; 3 - Pruned nodes) , another method is to download only the UTXO set (current as of block xxx) and verify that UTXO set within the current block with a hash embedded in the block (i.e. 3 - UTXO hash started nodes). Once done, such a node would be in the same state as another who processed the complete history and would contribute to the P2P network as a full node. I would argue that a UTXO hash would be as secure as a coinbase transaction, which is very secure. The risk to UTXO hashes is that a miner might insert an invalid hash for a new incorrect UTXO set. Miners can do the same thing with coinbase transactions, i.e. reward themselves 1000 BTC instead of 25 BTC. But they don't because such a block is invalid and would be rejected. Same with a UTXO hash, a miner could insert an incorrect hash, but such a block is invalid and would be rejected. And if you were still worried you could always scan the complete history, there will always be some nodes who do so and who would scream if there was a falsification. You're doing a great job articulating this but what's a bit confusing, at least for me, is from which type of node's perspective you're arguing from; namely 1. Archival nodes, 2. SPV clients, or 3. Pruned nodes. I think it matters because I don't think that current SPV clients have the capability to download the UTXO set to verify the UTXO hash embedded in their block headers. Do you think it would just be a small additional implementation detail that these wallet providers will insert once this protocol change gets enacted? Do smartphones have that memory capability? Ah OK, I think I now see what you were getting at. In the post above I was contrasting all three types, sorry if that was confusing. I edited the quoted text above to hopefully make the post more clear. If I understand your question correctly, you're asking if thin clients such as smartphones could utilize some form of a UTXO set to verify transactions and blocks on the P2P network. That is an interesting possibility. The reason smartphone type devices can't be full nodes today is due to both the storage and the bandwidth requirements. In terms of storage both 3) Pruned nodes and 3) UTXO hash started nodes could run on a smartphone since neither have to store the full blockchain. Bandwidth would still be an issue though. Pruned nodes would still need to download the full blockchain, over a mobile connection that would be expensive. UTXO hash started nodes however would only have to download the UTXO set, probably reasonable today, but it keeps growing. And that is just to get started, once started the node would need to transmit transactions & blocks. At over 1MB every 10 minutes, that will eat through any wireless plan's data allowances pretty fast. Here is a chart on the current UTXO set size. We are already at 650MB and growing. High end smartphones today only have 2-3GB of memory, and some of that is needed for other apps. http://statoshi.info/#/dashboard/file/default.json?panelId=5&fullscreen&from=now-24h&to=nowSo my guess is pretty soon the size of the UTXO set will be large enough that smartphone like devices couldn't run a full node, even if you ignore the bandwidth and storage limitations. Node memory requirements will become too large. |
|
|
|
SPV clients don't normally carry the UTXO set around in their memory, correct?
Right the "UTXO client" we've been talking about is a different animal with a stronger security model... SPV clients only request information on transactions involving addresses that they care about (well actually they ask for a range of address to preserve some level of anonymity). Using the merkle tree an SPV is able to link a single transaction up the tree to the block's header. Since they do maintain the header chain of the longest blockchain, this mechanism allows them to verify for themselves the validity of a transaction. However since they do not keep data on other addresses or transactions, they are not able to verify blocks or other new transactions on the P2P network. Think of them as leaves to the network. SPV clients take information, but do not contribute to the P2P network's security in any way, they are leaches. All full nodes maintain the full UTXO set. This is what enables them to verify blocks and new transactions on the network. The UTXO hash clients mentioned before are still full clients. The only difference is how the node obtains the current UTXO set from the longest blockchain. One method is to download and process the complete history, another method is to download only the UTXO set (current as of block xxx) and verify that UTXO set within the current block (i.e. with a hash embedded in the block). Once done, such a node would be in the same state as another who processed the complete history and would contribute to the P2P network as a full node. I would argue that a UTXO hash would be as secure as a coinbase transaction, which is very secure. The risk to UTXO hashes is that a miner might insert an invalid hash for a new incorrect UTXO set. Miners can do the same thing with coinbase transactions, i.e. reward themselves 1000 BTC instead of 25 BTC. But they don't because such a block is invalid and would be rejected. Same with a UTXO hash, a miner could insert an incorrect hash, but such a block is invalid and would be rejected. And if you were still worried you could always scan the complete history, there will always be some nodes who do so and who would scream if there was a falsification. |
|
|
|
when will people finally figure out that changing a guy on top of the power-structure doesn't bring about any meaningful change? We've tried and tried and still can't seem to vote in the "right people", yet so many people still cling to this idea of "if only we could vote in the right, honest and competent politicians all would be well". I'd really love to see the most benevolent and competent of all people put into positions of power, just to prove once and for all that it doesn't change anything. And they call my anarchist fantasies naive...hey those are at least something we haven't tried a gazillion times yet!
Well to be fair, a few people figured that out in the late 1700s. Even in a monarchy where the top supposedly can command anything, it is really the bureaucratic machine that determines everything. Even an economy in the late renaissance period was too large for any one king to actually understand and control. Today I don't think a president even has enough hours in a year to be briefed on all the various aspect of our economy, let alone have enough understanding to do anything meaningful. The top really only has time to implement and push through a few pet projects and almost always this expands government. And in the US the top having very little actual control is suppose to be OK and by design. In a constitutional republic where power is balanced between the states and the federal gov, the federal level is quite limited by what it can do. So it doesn't matter that the top (i.e. the President) has little actual control, because decision making is distributed throughout the system, and largely pushed out to local governments. This worked really well for ~100 years. But then the federal level took a tremendous amount of power over time, however the top still has very little actual control. This is what has created today's mess where the federal government is simply out of control. The bureaucratic machine has no check against it, the states can't stop it and the President can't stop it. Which is why we are quickly moving into a surveillance police state. It will all continue until the state runs out of money, which will only happen AFTER we have all been picked dry. |
|
|
|
@barrysilbert says trading of $GBTC should start today or tomorrow #BitcoinConf @BitcoinTrust https://twitter.com/InsideBitcoins/status/593489106296012800I can't wait to see if GBTC tracks the exchanges or if there develops a significant premium/discount spread. GBTC is the first mechanism to enable accounts that purchase assets through stock exchanges to buy BTC (indirectly). There is lots of money out there that can not easily access BTC today, and GBTC opens that up. |
|
|
|
also, i thought that the trolls said that banksters couldn't give a hoot about Bitcoin? it's too small, too geeky, no one wants decentralization, banksters are pure, yada, yada...
That's exactly my point. Banks will never use the bitcoin blockchain for several reasons.This reminds me...I recently came across this interesting article from back in February "Fedcoin: On the Desirability of a Government Cryptocurrency" by David Andolfatto (from the Federal Reserve Bank of St Louis). The article is about how to create "FedCoin," a cryptocurrency similar to Bitcoin, except for the monetary policy part. Instead of a floating exchange rate, the Fed maintains a credible peg between FedCoin and the USD. But that's not what I found interesting... ...what I found interesting is that he seems to believe that miners would be needed to process transactions in order to keep FedCoin free from KYC requirements: ...the e-version of the USD will probably be subject to KYC restrictions, which is unlike paper cash. To the paper cash feeling, we'd need to let the book-keeping done by disinterested third parties, like Bitcoin miners.
What a difference wording makes. Instead of "anonymous miners" that the the likes of Jeffrey Robinson (author of BitCon) claim would never be trusted for important financial transactions, these entities are now "disinterested third parties" and connotatively objective. They have no reason to be interested in any particular transaction, so why not objectively follow the protocol? ...to keep Fedcoin free of KYC restrictions, we probably don't want the Fed involved in processing these payments.
Lastly, and unrelated to the topic of who processes the payments, I liked this comment: Finally, the proposal for Fedcoin should in no way be construed as a backdoor attempt to legislate competing cryptocurrencies out of existence. The purpose of Fedcoin is to compete with other cryptocurrencies--to provide a property that no other cryptocurrency can offer (guaranteed exchange rate stability with the USD).
Imagine two competing digital currencies: Bitcoin vs Andolfatto's version of FedCoin, identical except for the monetary policy part (Bitcoin is bitcoin and 1 Fedcoin = 1 USD). Which would the free market choose? That is a fascinating find, Thanks. It is an acknowledgement of sorts that in order to keep a system honest and running correctly, it needs to be structured as a DAC which functions outside of external influence or government control. What he is saying is in order to ensure the functionality of cash transactions (i.e. anonymous, irreversible and open to all) there needs to be no central trusted entity. And that if there is any central entity to a system, that damaging regulations (such as KYC rules) will be inserted. |
|
|
|
UTXO hashes would be verified by both the P2P network and full (archival) nodes that maintain full history. I'd consider them as strong as a regular chain.
The p2p network can't verify them if it doesn't have the full chain, which is exactly what we were talking about: lightweight nodes that run an ARM thumb or something. You have a bootstrapping problem. Yes archival nodes would (or at least could) verify the whole thing, but there is nothing forcing them to, or at present not even any incentive to run an archival node at all. What happens if no one realizes that the last archival node shut down, or is malicious? To be clear, I'm not arguing "against" UXTO commitments, just pointing out that there is a reduction in trustlessness if everyone isn't verifying everything, and added risks when the incentives to verify are aligned with letting "someone else" do it. These can probably be fixed, or at least controlled, I agree with what you said about the third party trust creeping in regardless. The thing to remember is you don't need to hold the full chain to participate as a full node. That is why pruning works. Once you have a valid node state as of xxx block, you only need the header chain and the UTXO set to FULLY validate the next block. Assuming your node's state is correct, you do not need the full history to validate the next block. Again this is why pruning works. A UTXO set offers a faster method to reach a valid state as of xxx block. Today the only method to reach a valid state is to download & validate the complete history. But once your node has done so, your node can delete that history and just save the UTXO set, and still validate all future transactions and blocks. This is exactly what nodes that prune do. But this method is very inefficient, it is not a problem today, but it will be if bitcoin succeeds. As another example, with pruning it is possible that all nodes on the P2P network prune their history, and NO nodes on the network have a complete history individually. But each one would still be able to independently validate transactions and blocks. This is because they still have the valid UTXO set, the pruned history is not necessary. |
|
|
|
|
Last arguments for UTXO hashes, then I'll stop on it.
The reason I think bitcoin is going to have to add UTXO hashes at some point at simple, without them new nodes at some point will be forced to use centralized services that require trust to get going. In that scenario UTXO hashes strengthen bitcoin by providing a trustless mechanism for new nodes to get started.
In 30 years when Bitcoin has fully taken over, eliminated all fiat and gold, and ALL of mankind's transactions are on the blockchain (including machine-to-machine micropayments), the blockchain will be 100 Exabytes in size and grow by 10 Exabytes per year. Even if a new node is able to download this volume of data, processing the full history takes several CPU years. (I'm making up the numbers to make a point)
In such an environment starting a new node is both too costly and takes too long.
To fix this, centralized services appear that offer services to help new nodes start. These services will provide a node state for download that is valid as of xxxx block. This node state will have the full header history, the current UTXO set, and some number of random blocks to serve to others. With this download anyone can start a new node in minutes, instead of years.
Some of these centralized services are run by entities we like (such as blockchain.info) but others are run by entities we don't or shouldn't (such as the Bitcoin Foundation). But in either case, the practicality of starting a new node forces most people to trust some 3rd party entity .
UTXO hashes would eliminate this trust and enable new nodes to quickly start in a manner where they only have to trust the integrity of the blockchain (which is all you should need to trust). As argued in the above posts, I haven't seen a valid attack on them, even with a 51% miner attack.
|
|
|
|
Until yesterday I thought UTXO commitments were a good idea. After the discussion here I oppose it for 2 reasons: - It gives additional capabilities to a 51% attacker
I don't think this is true. UTXO hashes would be verified the same as transactions. Not if people are trusting them. Only if people are constructing them or verifying them. So you have a tragedy of the commons where if you have this nice little hash you can use to cheaply verify transactions without processing all the data, while expecting "someone else" to do the heavy lifting, the network as a whole gets weaker. I have to qualify that by saying I haven't looked that closely at the UXTO commitment proposals so my analysis may be slightly off, but I don't think so. UTXO hashes would be verified by both the P2P network and full (archival) nodes that maintain full history. I'd consider them as strong as a regular chain. Another way to look at it is, why can't a 51% miner reward themselves with larger than allowed coinbase transactions and increase the supply of coins beyond 21M? They do after all have the power to create the longest chain. The reason is such blocks are invalid and would be rejected as an invalid chain. Same with UTXO hashes, any attempt to insert an invalid UTXO hash is an invalid block and rejected by the P2P network. It is the exact same protection mechanism. |
|
|
|
nothing new, it seems at this point the reality could simply go beyond the fiction. at least for quite a while. just look at varoufakis exiting negociations by the small door. I disagree, what is novel here is a mainstream financial editor/writer willing to threaten the centralbank mind-control mantra and say specifically, "This is really, really, f$#%ed up". Fiat money is based purely on perception and Keynesians write papers on "behavioral economics" that fuel the manipulations, jaw-boning, market operations, etc that target price controls. If the illusion begins to dissolve it is over, that is how fragile the current situation is. What is depressing is it has taken the prospect of negative nominal rates to start this. Negative real rates are what really matter, that is financial repression. We have had negative real rates for years, but most people seem OK with that. It is only when the nominal rate goes negative and people see that their balances will go down, that all of a sudden it's an issue. An educated populace would have balked at negative real rates. That fact that we collectively didn't says a lot. |
|
|
|
Wouldn't the UTXO hash have to be in the header since otherwise it could get pruned?
I don't see why it would have to be. The header is really only for things a node has to have for each block, which is the linkage to the previous block and linkage to it's data package. You could put it in the block's tree structure. Then if a node needs it, the node could request and verify it. But if the node does not need it (i.e. an SPV client) the node could skip it (along with that block's other info such as the coinbase and transactions). |
|
|
|
Until yesterday I thought UTXO commitments were a good idea. After the discussion here I oppose it for 2 reasons: - It gives additional capabilities to a 51% attacker
I don't think this is true. UTXO hashes would be verified the same as transactions. For example, today if a 51% attacker tried to insert invalid transactions into a block to create coins, or double spend past transactions, the P2P network would reject such blocks. This is why a 51% attacker can really only attack by selecting specific transactions or refusing to confirm specific transactions. UTXO hashes would be the same. If a 51% attacker tried to create an invalid UTXO hash, that block would be rejected by the network. It is no different than a 51% attacker inserting an invalid transaction into a block. Both are rejected and a 51% attacker can't do this. - Since the UTXO set is actually an implementation detail, making it part of the bitcoin protocol seems inelegant and uneccessarily cluttering
I also don't think this is true. As of each block, the bitcoin protocol has a specific and known UTXO set. This isn't an implementation detail but an inherent property of the bitcoin protocol. Future transactions are limited to those in the UTXO set, it is part of the protocol. |
|
|
|
|
Show Posts
