It is my understanding that there is a consensus among devs that it is okay for some transactions never being confirmed, and the eventual pushing of those users and economic activity out of Bitcoin is acceptable. Although that seems to be the general feeling, I can't pinpoint where that understanding was born.
On how Satoshi Nakamoto would handle the problem, that doesn't seem very important, after all, he would probably pick the best solution anyone could propose. What is probably more important is: would Satoshi Nakamoto consider the inability of Bitcoin to supply its demand a problem, given its stated value proposition? I.e. why Bitcoin was created in the first place? Is it fulfilling its goals? 2017-11-29 5:38 GMT-02:00 Damian Williamson via bitcoin-discuss < [email protected]>: > I would be grateful if somebody can please forward a present TLDR; summary > of the present position on block size and transaction bandwidth. I > understand that there is quite some history of this discussion back to 2015 > (or further?), I would like to be summarily informed. > > > ---- > > Good afternoon, good morning, good evening, > > > I hope that I have found the correct place to put forward a proposal for > discussion. > > > My name is Damian Williamson, and I have a long history in CIT. I have > worked in the software industry but, will not claim to be a dev. I can git > pull. > > > In the following discussion, I set out what I suggest as a forward issue > for Bitcoin and a proposed response. Clearly, as always, my article could > have been better written. > > > **Make block sizes uncapped and have a transaction processing picking > weight.** > > The issue of what I will call transaction bandwidth, it seems, will > eventually be a real concern for the Bitcoin network. As popularity grows > there are more Bitcoin transactions, there is only room for a certain > number of transactions in a given time; only so many transactions can fit > into a block, and there are only so many blocks per week. Eventually, there > will be more transactions than the network can process. If transactions to > process are always selected based on fee (and it does not seem that they > currently always are) then, eventually, there will also be an increasing > number of fee-paying transactions that will never be processed, in addition > to those sent with no fees. I do not mind that it may take some time for > transactions to confirm and, I certainly do not mind the idea of paying > fees, being a core part of the operation of Bitcoin, however, it must be > possible for transactions to actually process and ideally in the priority > order of fees paid. > > From the position of a merchant, a customer sends you 1 BTC. If the > customer chooses no fees (or sets them too low), then it is entirely > possible that the merchant may never receive the customer's payment. This > as I understand it is the current situation with only a moderate amount of > transactions on the network. Once the total sustained number of > transactions exceeds the transaction bandwidth, there will need to be a > solution. This is necessary for the fundamental operation of Bitcoin. > > I ask, what would be Satoshi Nakamoto's original vision for dealing with > this issue? Clearly, there are several possibilities, not all of them are > equal. > > Increasing the fixed size of blocks is one possible temporary solution. As > more transactions are made, block sizes would need to increase further if > this approach is chosen. > > Another possibility is reducing the block time. Once again this is > temporary, as there are more transactions the block time would have to be > further adjusted. This may also cause further issues. > > Another solution would be to make block size uncapped. Transactions can be > selected to be process based on a function of a curve of the fee paid and > an inverse curve of the time that the transaction has waited in the > transaction pool, a transaction weight curve. Making them more likely to be > picked to be processed next the longer that they have waited or, the higher > the fee would seem workable. One month should be the highest priority to be > picked and, the market will determine the fee resulting in the highest > priority. The time that a transaction is created is not important; just the > time that a transaction entered into the transaction pool. All transactions > would eventually process and even waiting one month if low fees are paid is > still much faster to receive confirmed funds for a merchant than the Credit > Card chargeback regime. This solution is scalable to many transactions and > rewards those who pay fees. > > But I ask, is this the solution that Satoshi Nakamoto would have chosen? > It is important to consider and especially not to interrupt Bitcoin's > future operation. Remember that in a few short years from now, fees will be > the only payment that miners receive. Any solution needs to be scalable as > it is workable; it is not possible with certainty to say how large the > Bitcoin network will grow or, how many transactions per block will be the > workload. Transaction bandwidth is valuable. > > > Make block sizes uncapped and give each transaction a weight on a curve > that determines how likely it is to be included in the next block. > > > Thank you for your consideration. > > > Regards, > Damian Williamson > > > _______________________________________________ > bitcoin-discuss mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss > > -- Lucas Clemente Vella [email protected]
_______________________________________________ bitcoin-discuss mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
