📅 Original date posted:2017-12-06
📝 Original message:As i understand it, the transactions to be included in a block are
entirely up to the miner of that block.
What prevents a miner from implementing the proposal on their own?
If this is adopted as some kind of "policy", what forces a miner to
follow it?
Jim Renkel
On 12/2/2017 10:07 PM, Damian Williamson via bitcoin-dev wrote:
>
> # 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
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171205/c143a467/attachment-0001.html>;
Jim Renkel [ARCHIVE] /
npub1r5…etrj0
2023-06-07 18:08:14
in reply to nevent1q…upyd
Author Public Key
npub1r54yemf4uuuu3yqnn5ukj8fnkm4q4e3umj0tw2d0239r5g7r7ess4etrj0Seen on
wss://relay.noswhere.comPublished at
2023-06-07 18:08:14Event JSON
{
"id": "11b6980290dd0b4f535bb008dcb9fed46f6c6287bcea0731578ddb208af55e43",
"pubkey": "1d2a4ced35e739c890139d39691d33b6ea0ae63cdc9eb729af544a3a23c3f661",
"created_at": 1686161294,
"kind": 1,
"tags": [
[
"e",
"951044c4b5711f9ef1d20b7eddb96f15929b3f252d708006080ed5fadb7dcce3",
"",
"root"
],
[
"e",
"d7addcc2905b03279f075ba972177d025552ea645582e96629e957bff8797354",
"",
"reply"
],
[
"p",
"807351d851a3c419faea089fe59e0d72175abc5b316d48bfa974b48d83c07fed"
]
],
"content": "📅 Original date posted:2017-12-06\n📝 Original message:As i understand it, the transactions to be included in a block are \nentirely up to the miner of that block.\n\n\nWhat prevents a miner from implementing the proposal on their own?\n\n\nIf this is adopted as some kind of \"policy\", what forces a miner to \nfollow it?\n\nJim Renkel\n\nOn 12/2/2017 10:07 PM, Damian Williamson via bitcoin-dev wrote:\n\u003e\n\u003e # BIP Proposal: UTWFOTIB - Use Transaction Weight For Ordering \n\u003e Transactions In Blocks\n\u003e\n\u003e\n\u003e I admit, with my limited experience in the operation of the protocol, \n\u003e the section entitled 'Solution operation' may not be entirely correct \n\u003e but you will get the idea. If I have it wrong, please correct it back \n\u003e to the list.\n\u003e\n\u003e ## The problem:\n\u003e\n\u003e\n\u003e Everybody wants value. Miners want to maximize revenue from fees. \n\u003e Consumers want transaction reliability and, (we presume) low fees.\n\u003e\n\u003e\n\u003e Current transaction bandwidth limit is a limiting factor for both.\n\u003e\n\u003e ## Solution summary:\n\u003e\n\u003e\n\u003e Provide each transaction with a transaction weight, being a function \n\u003e of the fee paid (on a curve), and the time waiting in the transaction \n\u003e pool (also on a curve) out to n days (n=30 ?); the transaction weight \n\u003e serving as the likelihood of a transaction being included in the \n\u003e current block, and then use a target block size.\n\u003e\n\u003e\n\u003e Protocol enforcement to prevent high or low blocksize cheating to be \n\u003e handled by having the protocol determine the target size for the \n\u003e current block using; current transaction pool size x ( 1 / (144 x n \n\u003e days ) ) = transactions to be included in the current block.\n\u003e\n\u003e The curves used for the weight of transactions would have to be \n\u003e appropriate.\n\u003e\n\u003e ## Pros:\n\u003e\n\u003e\n\u003e * Maximizes transaction reliability.\n\u003e * Maximizes possibility for consumer and business uptake.\n\u003e * Maximizes total fees paid per block without reducing reliability; \n\u003e because of reliability, confidence and uptake are greater; therefore, \n\u003e more transactions and more transactions total at priority fees.\n\u003e * Market determines fee paid for transaction priority.\n\u003e\n\u003e * Fee recommendations work all the way out to 30 days or greater.\n\u003e\n\u003e * Provides additional block entropy and greater security since there \n\u003e is less probability of predicting the next block.\n\u003e\n\u003e ## Cons:\n\u003e\n\u003e\n\u003e * ?\n\u003e * Must be first be programmed.\n\u003e * Anything else?\n\u003e\n\u003e ## Solution operation:\n\u003e\n\u003e\n\u003e As I have said, my simplistic view of the operation. If I have this \n\u003e wrong, please correct it back to the list.\n\u003e\n\u003e\n\u003e 1. The protocol determines the target block size.\n\u003e\n\u003e 2. Assign each transaction in the pool a transaction weight based on \n\u003e fee and time waiting in the transaction pool.\n\u003e\n\u003e 3. Begin selecting transactions to include in the current block using \n\u003e transaction weight as the likelihood of inclusion until target block \n\u003e size is met.\n\u003e\n\u003e 4. Solve block.\n\u003e\n\u003e Regards,\n\u003e\n\u003e Damian Williamson\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171205/c143a467/attachment-0001.html\u003e",
"sig": "613d3e238090ea9d012e09bb42ec59fafc420d48dec41b99c6fc8d1a4490dc23fc387abe7d87455bfe237c67c0e7fc1bbb869eb3f974ec1a0b903312cff8ce88"
}