📅 Original date posted:2017-12-06
📝 Original message:Good afternoon ZmnSCPxj,
I have posted some discussion on the need for this proposal and, some refinements to the proposal explanation (not changes to the intended operation) to the bitcoin-discuss list. I didn't exactly mean to double post but thought it could use the discussion and, not to post it again, I will link to it when (if) it turns up, or will post it back here as an update on request. Currently, that post is awaiting moderator approval. I have also rewritten the solution operation section a bit in that post, not the idea that is being conveyed. I have added an additional step, reject blocks that do not meet the target block size for the current block.
I suggest it still should be added to the solution operation, to broadcast the next target block size with the current block when it is solved. Using that method may answer a part of your concern.
As I understand it, each node would be aware independently of x transactions waiting for confirmation, the transaction pool. Each node would no doubt have its own idea about how many waiting transactions there are and which particular transactions exist. I do not see why each node could not just work with the information at hand, it is my understanding that is what happens now, even with solved blocks vs the longest chain. I have not followed why you foresee from my proposal the need for fullnodes to back confirm the previous blocks in that manner.
If next blocksize is broadcast with the completed block it would be a simple matter to back confirm that. With transaction weight (transaction priority) I am suggesting that value gives the likelihood of a transaction being included, presuming an element of randomness as to whether any particular transaction is then included or not. Back confirmations on a transaction basis would be impossible anyway, all that could be confirmed is that a particular block has transactions that conform to a probability curve, if the variables are known, fee amount and time waiting in the pool, then the transaction priority can be recreated to establish that the probability of a particular block conforms. I certainly do not foresee including the full transaction pool in each block.
I am also presuming blocksize as a number of transactions rather than KB.
My suggestion, if adopted, is to directly make the operation of transaction priority a part of the operational standard - even without verification that it is being followed. The result of full transactional reliability is actually in the interests of miners as much as anyone.
The benefit of the proposal, not directly stated, is variable sized blocks (uncapped block size).
Yes, I have learned not to recycle terminology. My apologies, I had not been made aware that terminology already had use. Perhaps it would be simpler to call the proposal that I am putting forward here Transaction Priority.
Regards,
Damian Williamson
________________________________
From: ZmnSCPxj <ZmnSCPxj at protonmail.com>
Sent: Wednesday, 6 December 2017 4:46:45 PM
To: Damian Williamson
Cc: bitcoin-dev at lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks
Good morning Damian,
The primary problem in your proposal, as I understand it, is that the "transaction pool" is never committed to and is not part of consensus currently. It is unlikely that the transaction pool will ever be part of consensus, as putting the transaction pool into consensus is effectively lifting the block size to include the entire transaction pool into each block. The issue is that the transaction pool is transient and future fullnodes cannot find the contents of the transaction pool at the time blocks were made and cannot verify the correctness of historical blocks. Also, fullnodes using -blocksonly mode have no transaction pool and cannot verify incoming blocks for these new rules.
Applying a patch that follows this policy into Bitcoin Core without enforcing it in all fullnodes will simply lead to miners removing the patch in software they run, making it an exercise in futility to write, review, and test this code in the first place.
In addition, you reuse the term "weight" for something different than its current use. Current use, is that the "weight" of a transaction, is the computed weight from the SegWit weight equation, measured in virtual units called "sipa", using the equation (4sipa / non-witness byte + 1sipa/witness byte).
Regards,
ZmnSCPxj
Sent with ProtonMail<https://protonmail.com>; Secure Email.
-------- Original Message --------
Subject: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks
Local Time: December 6, 2017 3:38 AM
UTC Time: December 5, 2017 7:38 PM
From: bitcoin-dev at lists.linuxfoundation.org
To: bitcoin-dev at lists.linuxfoundation.org <bitcoin-dev at lists.linuxfoundation.org>
# BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks
I admit, with my limited experience in the operation of the protocol, the section entitled 'Solution operation' may not be entirely correct but you will get the idea. If I have it wrong, please correct it back to the list.
## The problem:
Everybody wants value. Miners want to maximize revenue from fees. Consumers want transaction reliability and, (we presume) low fees.
Current transaction bandwidth limit is a limiting factor for both.
## Solution summary:
Provide each transaction with a transaction weight, being a function of the fee paid (on a curve), and the time waiting in the transaction pool (also on a curve) out to n days (n=30 ?); the transaction weight serving as the likelihood of a transaction being included in the current block, and then use a target block size.
Protocol enforcement to prevent high or low blocksize cheating to be handled by having the protocol determine the target size for the current block using; current transaction pool size x ( 1 / (144 x n days ) ) = transactions to be included in the current block.
The curves used for the weight of transactions would have to be appropriate.
## Pros:
* Maximizes transaction reliability.
* Maximizes possibility for consumer and business uptake.
* Maximizes total fees paid per block without reducing reliability; because of reliability, confidence and uptake are greater; therefore, more transactions and more transactions total at priority fees.
* Market determines fee paid for transaction priority.
* Fee recommendations work all the way out to 30 days or greater.
* Provides additional block entropy and greater security since there is less probability of predicting the next block.
## Cons:
* ?
* Must be first be programmed.
* Anything else?
## Solution operation:
As I have said, my simplistic view of the operation. If I have this wrong, please correct it back to the list.
1. The protocol determines the target block size.
2. Assign each transaction in the pool a transaction weight based on fee and time waiting in the transaction pool.
3. Begin selecting transactions to include in the current block using transaction weight as the likelihood of inclusion until target block size is met.
4. Solve block.
Regards,
Damian Williamson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171206/462fabf4/attachment.html>;
Damian Williamson [ARCHIVE] /
npub1sp…8lz2h
2023-06-07 18:08:15
in reply to nevent1q…6qf9
Author Public Key
npub1spe4rkz350zpn7h2pz07t8sdwgt440zmx9k530afwj6gmq7q0lksh8lz2hPublished at
2023-06-07 18:08:15Event JSON
{
"id": "5888081b1f7f5062b6d7671a88c5d1a6a1d4f00e00c1b6384ee8cca6a766b6b4",
"pubkey": "807351d851a3c419faea089fe59e0d72175abc5b316d48bfa974b48d83c07fed",
"created_at": 1686161295,
"kind": 1,
"tags": [
[
"e",
"951044c4b5711f9ef1d20b7eddb96f15929b3f252d708006080ed5fadb7dcce3",
"",
"root"
],
[
"e",
"577f733b36b5e143cac2444eef597df85b256c44cf17476468bd23fc184ac537",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2017-12-06\n📝 Original message:Good afternoon ZmnSCPxj,\n\n\nI have posted some discussion on the need for this proposal and, some refinements to the proposal explanation (not changes to the intended operation) to the bitcoin-discuss list. I didn't exactly mean to double post but thought it could use the discussion and, not to post it again, I will link to it when (if) it turns up, or will post it back here as an update on request. Currently, that post is awaiting moderator approval. I have also rewritten the solution operation section a bit in that post, not the idea that is being conveyed. I have added an additional step, reject blocks that do not meet the target block size for the current block.\n\nI suggest it still should be added to the solution operation, to broadcast the next target block size with the current block when it is solved. Using that method may answer a part of your concern.\n\nAs I understand it, each node would be aware independently of x transactions waiting for confirmation, the transaction pool. Each node would no doubt have its own idea about how many waiting transactions there are and which particular transactions exist. I do not see why each node could not just work with the information at hand, it is my understanding that is what happens now, even with solved blocks vs the longest chain. I have not followed why you foresee from my proposal the need for fullnodes to back confirm the previous blocks in that manner.\n\nIf next blocksize is broadcast with the completed block it would be a simple matter to back confirm that. With transaction weight (transaction priority) I am suggesting that value gives the likelihood of a transaction being included, presuming an element of randomness as to whether any particular transaction is then included or not. Back confirmations on a transaction basis would be impossible anyway, all that could be confirmed is that a particular block has transactions that conform to a probability curve, if the variables are known, fee amount and time waiting in the pool, then the transaction priority can be recreated to establish that the probability of a particular block conforms. I certainly do not foresee including the full transaction pool in each block.\n\nI am also presuming blocksize as a number of transactions rather than KB.\n\nMy suggestion, if adopted, is to directly make the operation of transaction priority a part of the operational standard - even without verification that it is being followed. The result of full transactional reliability is actually in the interests of miners as much as anyone.\n\nThe benefit of the proposal, not directly stated, is variable sized blocks (uncapped block size).\n\nYes, I have learned not to recycle terminology. My apologies, I had not been made aware that terminology already had use. Perhaps it would be simpler to call the proposal that I am putting forward here Transaction Priority.\n\nRegards,\nDamian Williamson\n\n\n________________________________\nFrom: ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e\nSent: Wednesday, 6 December 2017 4:46:45 PM\nTo: Damian Williamson\nCc: bitcoin-dev at lists.linuxfoundation.org\nSubject: Re: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks\n\nGood morning Damian,\n\nThe primary problem in your proposal, as I understand it, is that the \"transaction pool\" is never committed to and is not part of consensus currently. It is unlikely that the transaction pool will ever be part of consensus, as putting the transaction pool into consensus is effectively lifting the block size to include the entire transaction pool into each block. The issue is that the transaction pool is transient and future fullnodes cannot find the contents of the transaction pool at the time blocks were made and cannot verify the correctness of historical blocks. Also, fullnodes using -blocksonly mode have no transaction pool and cannot verify incoming blocks for these new rules.\n\nApplying a patch that follows this policy into Bitcoin Core without enforcing it in all fullnodes will simply lead to miners removing the patch in software they run, making it an exercise in futility to write, review, and test this code in the first place.\n\nIn addition, you reuse the term \"weight\" for something different than its current use. Current use, is that the \"weight\" of a transaction, is the computed weight from the SegWit weight equation, measured in virtual units called \"sipa\", using the equation (4sipa / non-witness byte + 1sipa/witness byte).\n\nRegards,\nZmnSCPxj\n\n\n\n\nSent with ProtonMail\u003chttps://protonmail.com\u003e Secure Email.\n\n-------- Original Message --------\nSubject: [bitcoin-dev] BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks\nLocal Time: December 6, 2017 3:38 AM\nUTC Time: December 5, 2017 7:38 PM\nFrom: bitcoin-dev at lists.linuxfoundation.org\nTo: bitcoin-dev at lists.linuxfoundation.org \u003cbitcoin-dev at lists.linuxfoundation.org\u003e\n\n\n\n# BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering Transactions In Blocks\n\nI admit, with my limited experience in the operation of the protocol, the section entitled 'Solution operation' may not be entirely correct but you will get the idea. If I have it wrong, please correct it back to the list.\n\n\n\n## The problem:\n\n\nEverybody wants value. Miners want to maximize revenue from fees. Consumers want transaction reliability and, (we presume) low fees.\n\nCurrent transaction bandwidth limit is a limiting factor for both.\n\n\n\n## Solution summary:\n\n\nProvide each transaction with a transaction weight, being a function of the fee paid (on a curve), and the time waiting in the transaction pool (also on a curve) out to n days (n=30 ?); the transaction weight serving as the likelihood of a transaction being included in the current block, and then use a target block size.\n\nProtocol enforcement to prevent high or low blocksize cheating to be handled by having the protocol determine the target size for the current block using; current transaction pool size x ( 1 / (144 x n days ) ) = transactions to be included in the current block.\n\nThe curves used for the weight of transactions would have to be appropriate.\n\n\n\n## Pros:\n\n* Maximizes transaction reliability.\n* Maximizes possibility for consumer and business uptake.\n* Maximizes total fees paid per block without reducing reliability; because of reliability, confidence and uptake are greater; therefore, more transactions and more transactions total at priority fees.\n* Market determines fee paid for transaction priority.\n\n\n* Fee recommendations work all the way out to 30 days or greater.\n\n* Provides additional block entropy and greater security since there is less probability of predicting the next block.\n\n\n\n## Cons:\n\n* ?\n* Must be first be programmed.\n* Anything else?\n\n\n\n## Solution operation:\n\n\nAs I have said, my simplistic view of the operation. If I have this wrong, please correct it back to the list.\n\n1. The protocol determines the target block size.\n\n\n2. Assign each transaction in the pool a transaction weight based on fee and time waiting in the transaction pool.\n\n3. Begin selecting transactions to include in the current block using transaction weight as the likelihood of inclusion until target block size is met.\n\n4. Solve block.\n\n\n\nRegards,\n\nDamian Williamson\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171206/462fabf4/attachment.html\u003e",
"sig": "8cc1a63b4439da99260b5af072f246a8a150db62c8ce65c66759cce1313d7fea6a59c52a1257326ce876b2361124c87a4f09c8617406c9a4ffe91e92af0689b1"
}