📅 Original date posted:2015-07-19
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Some brief thoughts, adding here a suggestion for a dynamic approach
to the issue. (e.g. each additional tx relayed has some thing
associated with it, that is, a "doubling" for each additional tx
relayed that spends a given UTXO, doesn't sound like it would be the
most dynamic approach to the issue; considering that full nodes use
the (UTXOs) to establish if transactions are valid – all inputs to a
transaction must be in the UTXO database for it to be valid, but
rather, would end up ratcheting upward the fee/kB for each additional
tx relayed, as proposed).
A more dynamic fee approach would be a better one, imho, but how is
this to occur?
Quoting from Gavin Andresen's http://gavinandresen.ninja/utxo-uhoh,
"The entire UTXO set doesn’t have to be in RAM; it can be stored on an
SSD or spinning hard disk. The access pattern to the UTXO is not
random; outputs that were spent recently are more likely to be
re-spent than outputs that have not been spent in a long time. Bitcoin
Core already has a multi-level UTXO cache, thanks to the hard work of
Pieter Wuille."
The relay nodes would, in this scenario that is proposed here in this
message, be confirming and discarding; the wallet nodes, if I
understand properly, in this scenario, as proposed, should be
retaining (keeping a record of the transactions they've relayed and
using a mempool).
There are some questions here:
- - How is the mempool to be limited?
- - What is the mechanism by which the UTXO set is stored (or proposed
to be stored)?
- - How would dynamic fee determinations be calculated?
- - Please describe more the general purpose messaging network?
Thank you
On 07/18/2015 12:46 PM, Patrick Strateman via bitcoin-dev wrote:
> Relay nodes do not need a mempool, but do need some mechanism to
> avoid DoS issues.
>
> Wallet nodes can use the mempool for fee estimation (in addition
> to looking at past blocks).
>
> On 07/18/2015 11:52 AM, Peter Todd via bitcoin-dev wrote:
>> As in, do relay nodes need to keep a record of the transactions
>> they've relayed? Strictly speaking, the answer is no: one a tx is
>> relayed modulo DoS concerns the entire thing can be discarded by
>> the node. (unconfirmed txs spending other unconfirmed txs can be
>> handled by creating packages of transactions, evaluated as a
>> whole)
>>
>> To mitigate DoS concerns, we of course have to have some per-UTXO
>> limit on bandwidth relayed, but that task can be accomplished by
>> simply maintaining some kind of per-UTXO record of bandwidth
>> used. For instance if the weighted fee and fee/KB were recorded,
>> and forced to - say - double for each additional tx relayed that
>> spent a given UTXO you would have a clear and simple upper limit
>> of lifetime bandwidth. Equally it's easy to limit bandwidth
>> moment to moment by asking peers for highest fee/KB transactions
>> they advertise first, stopping when our bandwidth limit is
>> reached.
>>
>> You probably could even remove IsStandard() pretty much entirely
>> with the right increasingly expensive "replacement" policy,
>> relying on it alone to provide anti-DoS. Obviously this would
>> simplify some of the debates around mining policy! This could
>> even be re-used for scalable a general-purpose messaging network
>> paid by coin ownership if the UTXO set is split up, and some kind
>> of expiration over time policy is implemented.
>>
>> Miners of course would still want to have a mempool, but that
>> codebase may prove simpler if it doesn't have to work double-duty
>> for relaying as well.
>>
>>
>>
>> _______________________________________________ bitcoin-dev
>> mailing list bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________ bitcoin-dev mailing
> list bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
- --
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBAgAGBQJVq2cFAAoJEGxwq/inSG8CIo4IAJAZ97NvW6Qdjd6HLN8q2074
sEUGdDeonARiQZXLfGyTJVg43Yb6LKPqkjWPQEgl9LLNni8t99iUqu3BJxedRDjd
8x+/F8n5VJrUrn1pXUcbC1aWss1y8JPTO2KpF/WL254IFc8iE8MJf4YF8PDSgy5j
9uW8NvWvdT4dz+rXu9vqfcplz8x7NGQ+CWN2N2JlChhKLMFprXPIx8a7NQwaKdrY
lTpgAJWGMyPGNCmYQprBjIjOfp8tdTLQFlsLUAsXDmEisJX9goRVGMsHOWLTREoA
l3kTgM0WMv6MIG7NOQQcWLD7cZdwWYR9e49hc27VcHt2R/FTepvnwPqo2GtE0tM=
=eRbR
-----END PGP SIGNATURE-----
odinn [ARCHIVE] /
npub1xv…5j2ga
2023-06-07 15:42:36
in reply to nevent1q…9wdq
Author Public Key
npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2gaPublished at
2023-06-07 15:42:36Event JSON
{
"id": "1a3bb2f27a788654c867d426ec71447920c9ac87986b9ef3c30111e358a8f52c",
"pubkey": "33228a8ed797b24e872fc0257c1515fc9bca74c0b230dcbb7d3d2bd38fd97ed7",
"created_at": 1686152556,
"kind": 1,
"tags": [
[
"e",
"6c219e76e9c4ea7b8a06a7dddb0816f943d913ed3f6a4dabf273eff85309d97c",
"",
"root"
],
[
"e",
"22fc3ad8311f3aa34486c057cd814b7e83e54cac61ba92ed7ab173f0e61691e4",
"",
"reply"
],
[
"p",
"fc7892eea47289e31dc49660ebe7f00108707eb2ee3b59909accdf0afaa4eb61"
]
],
"content": "📅 Original date posted:2015-07-19\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nSome brief thoughts, adding here a suggestion for a dynamic approach\nto the issue. (e.g. each additional tx relayed has some thing\nassociated with it, that is, a \"doubling\" for each additional tx\nrelayed that spends a given UTXO, doesn't sound like it would be the\nmost dynamic approach to the issue; considering that full nodes use\nthe (UTXOs) to establish if transactions are valid – all inputs to a\ntransaction must be in the UTXO database for it to be valid, but\nrather, would end up ratcheting upward the fee/kB for each additional\ntx relayed, as proposed).\n\nA more dynamic fee approach would be a better one, imho, but how is\nthis to occur?\n\nQuoting from Gavin Andresen's http://gavinandresen.ninja/utxo-uhoh,\n\"The entire UTXO set doesn’t have to be in RAM; it can be stored on an\nSSD or spinning hard disk. The access pattern to the UTXO is not\nrandom; outputs that were spent recently are more likely to be\nre-spent than outputs that have not been spent in a long time. Bitcoin\nCore already has a multi-level UTXO cache, thanks to the hard work of\nPieter Wuille.\"\n\nThe relay nodes would, in this scenario that is proposed here in this\nmessage, be confirming and discarding; the wallet nodes, if I\nunderstand properly, in this scenario, as proposed, should be\nretaining (keeping a record of the transactions they've relayed and\nusing a mempool).\n\nThere are some questions here:\n\n- - How is the mempool to be limited?\n- - What is the mechanism by which the UTXO set is stored (or proposed\nto be stored)?\n- - How would dynamic fee determinations be calculated?\n- - Please describe more the general purpose messaging network?\n\nThank you\n\n\n\nOn 07/18/2015 12:46 PM, Patrick Strateman via bitcoin-dev wrote:\n\u003e Relay nodes do not need a mempool, but do need some mechanism to\n\u003e avoid DoS issues.\n\u003e \n\u003e Wallet nodes can use the mempool for fee estimation (in addition\n\u003e to looking at past blocks).\n\u003e \n\u003e On 07/18/2015 11:52 AM, Peter Todd via bitcoin-dev wrote:\n\u003e\u003e As in, do relay nodes need to keep a record of the transactions\n\u003e\u003e they've relayed? Strictly speaking, the answer is no: one a tx is\n\u003e\u003e relayed modulo DoS concerns the entire thing can be discarded by\n\u003e\u003e the node. (unconfirmed txs spending other unconfirmed txs can be\n\u003e\u003e handled by creating packages of transactions, evaluated as a\n\u003e\u003e whole)\n\u003e\u003e \n\u003e\u003e To mitigate DoS concerns, we of course have to have some per-UTXO\n\u003e\u003e limit on bandwidth relayed, but that task can be accomplished by\n\u003e\u003e simply maintaining some kind of per-UTXO record of bandwidth\n\u003e\u003e used. For instance if the weighted fee and fee/KB were recorded,\n\u003e\u003e and forced to - say - double for each additional tx relayed that\n\u003e\u003e spent a given UTXO you would have a clear and simple upper limit\n\u003e\u003e of lifetime bandwidth. Equally it's easy to limit bandwidth\n\u003e\u003e moment to moment by asking peers for highest fee/KB transactions\n\u003e\u003e they advertise first, stopping when our bandwidth limit is\n\u003e\u003e reached.\n\u003e\u003e \n\u003e\u003e You probably could even remove IsStandard() pretty much entirely\n\u003e\u003e with the right increasingly expensive \"replacement\" policy,\n\u003e\u003e relying on it alone to provide anti-DoS. Obviously this would\n\u003e\u003e simplify some of the debates around mining policy! This could\n\u003e\u003e even be re-used for scalable a general-purpose messaging network\n\u003e\u003e paid by coin ownership if the UTXO set is split up, and some kind\n\u003e\u003e of expiration over time policy is implemented.\n\u003e\u003e \n\u003e\u003e Miners of course would still want to have a mempool, but that\n\u003e\u003e codebase may prove simpler if it doesn't have to work double-duty\n\u003e\u003e for relaying as well.\n\u003e\u003e \n\u003e\u003e \n\u003e\u003e \n\u003e\u003e _______________________________________________ bitcoin-dev\n\u003e\u003e mailing list bitcoin-dev at lists.linuxfoundation.org \n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________ bitcoin-dev mailing\n\u003e list bitcoin-dev at lists.linuxfoundation.org \n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \n\n- -- \nhttp://abis.io ~\n\"a protocol concept to enable decentralization\nand expansion of a giving economy, and a new social good\"\nhttps://keybase.io/odinn\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJVq2cFAAoJEGxwq/inSG8CIo4IAJAZ97NvW6Qdjd6HLN8q2074\nsEUGdDeonARiQZXLfGyTJVg43Yb6LKPqkjWPQEgl9LLNni8t99iUqu3BJxedRDjd\n8x+/F8n5VJrUrn1pXUcbC1aWss1y8JPTO2KpF/WL254IFc8iE8MJf4YF8PDSgy5j\n9uW8NvWvdT4dz+rXu9vqfcplz8x7NGQ+CWN2N2JlChhKLMFprXPIx8a7NQwaKdrY\nlTpgAJWGMyPGNCmYQprBjIjOfp8tdTLQFlsLUAsXDmEisJX9goRVGMsHOWLTREoA\nl3kTgM0WMv6MIG7NOQQcWLD7cZdwWYR9e49hc27VcHt2R/FTepvnwPqo2GtE0tM=\n=eRbR\n-----END PGP SIGNATURE-----",
"sig": "19835b31e9c2ced5eae1fd64d8e5af7f265ab1bf95deed55bb0a979633c6a1e345cb1814047f2a316dd8d9fcca625d381eaa7dde95cd4a60cf3a401015270a53"
}