Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2012-06-15 📝 Original message:On Fri, 2012-06-15 at ...
📅 Original date posted:2012-06-15
📝 Original message:On Fri, 2012-06-15 at 13:29 +0200, Mike Hearn wrote:
> I had to hit the sack last night as it was 2am CET, but I'd like to
> sum up the discussion we had on IRC about scalability and SatoshiDice
> in particular.
>
> I think we all agreed on the following:
>
> - Having senders/buyers pay no fees is psychologically desirable even
> though we all understand that eventually, somebody, somewhere will be
> paying fees to use Bitcoin
>
> - In the ideal world Bitcoin would scale perfectly and there would be
> no need for there to be some "winners" and some "losers" when it comes
> to confirmation time.
>
> There was discussion of some one-off changes to address the current
> situation, namely de-ranking transactions that re-use addresses. Gavin
> and myself were not keen on this idea, primarily because it just
> avoids the real problem and Bitcoin already has a good way to
> prioritize transactions via the fees mechanism itself. The real issue
> is that SatoshiDice does indeed pay fees and generates a lot of
> transactions, pushing more traditional traffic out due to artificial
> throttles.
The idea can be more generalized in that there are many cases where the
generator of a transaction doesn't care about confirmation times, and
would really be willing to make their transaction lower priority than
other 0-fee transactions. This enables the first point with lower
confirmation times for a while longer.
As it turns out, we already have an indication that someone is willing
to wait longer for confirmations - rapid reuse of an address.
1) Green Addresses: The whole point of a green address is that you are
trusted based on your address, not necessarily based on confirmations of
your transactions. In this case, you are generally willing to wait a
bit longer for confirmations than the average user depositing coins into
their Mt. Gox account.
2) Donation Addresses: If you are using a publicized donation address,
you probably aren't depending on getting your coins *now* to turn around
and ship a product and, again, you are a bit more willing to tolerate
longer confirmation times.
3) Lazy (or overworked) coders: If, for whatever reason, someone
designing a bitcoin site decides that it is simply easier to make users
pay to a single address for everything, such actions should generally be
discouraged. Such a setup is worse for end-user privacy. Also, such
laziness (or likely just overworked and not having time to fix the
issue) is likely also laziness across the board including ignoring
multisend for payouts. If you discourage such address use forcing site
designers to implement more sane policies, hopefully they will do enough
research to also do multisend. Note that though this is where one
addresses sites like SatoshiDice, its also the one where we are likely
to have the least impact...
One of the ways to implement such deprioritization of rapidly-reused
addresses is to limit the count of address re-uses by default in memory
pool. By limiting relaying of such transactions, you a) give nodes
across the network some small say in the transactions which they have to
deal with relaying outside of blocks, instead of relying on miners to
make decisions which are good for the total network load, but which are
worse for them. b) You allow sites which wish to re-use addresses to do
so initially to keep the time-to-launch the same as it is today, but
force them to re-think their design decisions as they grow to
(hopefully) decrease their impact on the average Bitcoin full-node
operator. Sites which begin to see their transactions rate-limited have
several options:
1) Make a deal with a miner to feed them their list of now-non-relayed
transactions outside of the regular p2p network and have them manually
added to blocks. Id argue that such setups are going to become more
common in the future and such out-of-band transaction relaying should be
encouraged. This also shifts the delay for other transactions from a
constant delay getting into blocks until there is room for additional
0-fee transactions to a spike on each block from the given miner. I
highly prefer this, as you would see usually only one or two block delay
getting your transaction confirmed at the worst case, instead of a very
fuzzy unknown delay that could stretch on for some time.
2) Use rotating addresses. This is likely the simplest to implement,
and I would absolutely think this is what most sites would end up doing.
Though it doesn't result in a decreased load on the transaction-relaying
nodes, it does at least allow for a minor improvement in user privacy.
In the end, it boils down to an optional transaction deprioritization.
>
> The following set of proposals were discussed:
>
> (1) Change the mining code to group transactions together with their
> mempool dependencies and then calculate all fees as a group. A tx with
> a fee of 1 BTC that depends on 5 txns with zero fees would result in
> all 6 transactions being considered to have a fee of 1BTC and
> therefore become prioritized for inclusion. This allows a transition
> to "receiver pays" model for fees. There are many advantages. One is
> that it actually makes sense ... it's always the receiver who wants
> confirmations because it's the receiver that fears double spends.
> Senders never do. What's more, whilst Bitcoin is designed to operate
> on a zero-trust model in the real world trust often exists and it can
> be used to optimize by passing groups of transactions around with
> their dependencies, until that group passes a trust boundary and gets
> broadcast with a send-to-self tx to add fees. Another advantage is it
> simplifies usage for end users who primarily buy rather than sell,
> because it avoids the need to guess at fees, one of the most
> problematic parts of Bitcoins design now.
>
> The disadvantages are that it can result in extra transactions that
> exist only for adding fees, and it requires a more modern payment
> protocol than the direct-IP protocol Satoshi designed.
>
> It would help address the current situation by avoiding angry users
> who want to buy things, but don't know what fee to set and so their
> transactions get stuck.
>
> (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to
> avoid paying excessive fees and queue-jumping. Guess that's on my
> plate.
>
> (3) Scalability improvements seem like a no brainer to everyone, it's
> just a case of how complicated they are.
I think all of the above are largely no brianers to everyone.
>
> (4) Making the block size limit float is better than picking a new
> arbitrary threshold.
Definitely something that is very appealing as we need to scale up.
>
> On the forums Matt stated that block chain pruning was a no-go because
> "it makes bitcoin more centralized". I think we've thrashed this one
> out sufficiently well by now that there should be a united opinion on
> it. There are technical ways to implement it such that there is no
> change of trust requirements. All the other issues (finding archival
> nodes, etc) can be again addressed with sufficient programming.
My point was that the easiest way to do it would be to ship a pruned
snapshot with Bitcoin, and such a system, while verifiable, would
increase Bitocin's centralization. Though it is quite possible to prune
the chain while downloading at checkpoints or when blocks are N deep, it
complicates the initial download if no one has the chain to begin with.
Another point I made was that by doing chain pruning by default, we may
see a decrease in non-fClient nodes (for compatibility, I would assume
pruned nodes have to set fClient) which is what old clients look for to
connect to, possibly complicating using Bitcoin for clients that either
wish to run a full IBD or older clients which need a non-fClient node
before they are happy (which could be an issue when you look at the very
poor "upgrade-apathy" in the Bitcoin community with people running
long-outdated versions because they don't feel like upgrading).
All that said, I do believe pruning will eventually have to come to
encourage p2pool and other getmemorypool-based pool mining, but
(obviously) its something that needs careful consideration in its
overall effects across the network before its applied.
>
> For the case of huge blocks slowing down end user syncing and wasting
> their resources, SPV clients like MultiBit and Android Wallet already
> exist and will get better with time. If Jeff implements the bloom
> filtering p2p commands I'll make bitcoinj use them and that'll knock
> out excessive bandwidth usage and parse overheads from end users who
> are on these clients. At some point Bitcoin-Qt can have a dual mode,
> but who knows when that'll get implemented.
>
> Does that all sound reasonable?
Published at
2023-06-07 10:14:01Event JSON
{
"id": "d1954bebe6687a76723bca7ae9dfbda4ecfad850c1e336f4fcf7ce73b4e4ecf8",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686132841,
"kind": 1,
"tags": [
[
"e",
"4c4b54c01d15791b993b2c3cf942fdf81f1302a536c78263499330580e87cb4e",
"",
"root"
],
[
"e",
"f8b28eca2115dd9c15fd3f6cf096a6a9e3a869bfe5433c404258b902b88499e7",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2012-06-15\n📝 Original message:On Fri, 2012-06-15 at 13:29 +0200, Mike Hearn wrote:\n\u003e I had to hit the sack last night as it was 2am CET, but I'd like to\n\u003e sum up the discussion we had on IRC about scalability and SatoshiDice\n\u003e in particular.\n\u003e \n\u003e I think we all agreed on the following:\n\u003e \n\u003e - Having senders/buyers pay no fees is psychologically desirable even\n\u003e though we all understand that eventually, somebody, somewhere will be\n\u003e paying fees to use Bitcoin\n\u003e \n\u003e - In the ideal world Bitcoin would scale perfectly and there would be\n\u003e no need for there to be some \"winners\" and some \"losers\" when it comes\n\u003e to confirmation time.\n\u003e \n\u003e There was discussion of some one-off changes to address the current\n\u003e situation, namely de-ranking transactions that re-use addresses. Gavin\n\u003e and myself were not keen on this idea, primarily because it just\n\u003e avoids the real problem and Bitcoin already has a good way to\n\u003e prioritize transactions via the fees mechanism itself. The real issue\n\u003e is that SatoshiDice does indeed pay fees and generates a lot of\n\u003e transactions, pushing more traditional traffic out due to artificial\n\u003e throttles.\nThe idea can be more generalized in that there are many cases where the\ngenerator of a transaction doesn't care about confirmation times, and\nwould really be willing to make their transaction lower priority than\nother 0-fee transactions. This enables the first point with lower\nconfirmation times for a while longer.\nAs it turns out, we already have an indication that someone is willing\nto wait longer for confirmations - rapid reuse of an address. \n1) Green Addresses: The whole point of a green address is that you are\ntrusted based on your address, not necessarily based on confirmations of\nyour transactions. In this case, you are generally willing to wait a\nbit longer for confirmations than the average user depositing coins into\ntheir Mt. Gox account. \n2) Donation Addresses: If you are using a publicized donation address,\nyou probably aren't depending on getting your coins *now* to turn around\nand ship a product and, again, you are a bit more willing to tolerate\nlonger confirmation times.\n3) Lazy (or overworked) coders: If, for whatever reason, someone\ndesigning a bitcoin site decides that it is simply easier to make users\npay to a single address for everything, such actions should generally be\ndiscouraged. Such a setup is worse for end-user privacy. Also, such\nlaziness (or likely just overworked and not having time to fix the\nissue) is likely also laziness across the board including ignoring\nmultisend for payouts. If you discourage such address use forcing site\ndesigners to implement more sane policies, hopefully they will do enough\nresearch to also do multisend. Note that though this is where one\naddresses sites like SatoshiDice, its also the one where we are likely\nto have the least impact...\n\nOne of the ways to implement such deprioritization of rapidly-reused\naddresses is to limit the count of address re-uses by default in memory\npool. By limiting relaying of such transactions, you a) give nodes\nacross the network some small say in the transactions which they have to\ndeal with relaying outside of blocks, instead of relying on miners to\nmake decisions which are good for the total network load, but which are\nworse for them. b) You allow sites which wish to re-use addresses to do\nso initially to keep the time-to-launch the same as it is today, but\nforce them to re-think their design decisions as they grow to\n(hopefully) decrease their impact on the average Bitcoin full-node\noperator. Sites which begin to see their transactions rate-limited have\nseveral options:\n1) Make a deal with a miner to feed them their list of now-non-relayed\ntransactions outside of the regular p2p network and have them manually\nadded to blocks. Id argue that such setups are going to become more\ncommon in the future and such out-of-band transaction relaying should be\nencouraged. This also shifts the delay for other transactions from a\nconstant delay getting into blocks until there is room for additional\n0-fee transactions to a spike on each block from the given miner. I\nhighly prefer this, as you would see usually only one or two block delay\ngetting your transaction confirmed at the worst case, instead of a very\nfuzzy unknown delay that could stretch on for some time.\n2) Use rotating addresses. This is likely the simplest to implement,\nand I would absolutely think this is what most sites would end up doing.\nThough it doesn't result in a decreased load on the transaction-relaying\nnodes, it does at least allow for a minor improvement in user privacy. \n\nIn the end, it boils down to an optional transaction deprioritization.\n\u003e \n\u003e The following set of proposals were discussed:\n\u003e \n\u003e (1) Change the mining code to group transactions together with their\n\u003e mempool dependencies and then calculate all fees as a group. A tx with\n\u003e a fee of 1 BTC that depends on 5 txns with zero fees would result in\n\u003e all 6 transactions being considered to have a fee of 1BTC and\n\u003e therefore become prioritized for inclusion. This allows a transition\n\u003e to \"receiver pays\" model for fees. There are many advantages. One is\n\u003e that it actually makes sense ... it's always the receiver who wants\n\u003e confirmations because it's the receiver that fears double spends.\n\u003e Senders never do. What's more, whilst Bitcoin is designed to operate\n\u003e on a zero-trust model in the real world trust often exists and it can\n\u003e be used to optimize by passing groups of transactions around with\n\u003e their dependencies, until that group passes a trust boundary and gets\n\u003e broadcast with a send-to-self tx to add fees. Another advantage is it\n\u003e simplifies usage for end users who primarily buy rather than sell,\n\u003e because it avoids the need to guess at fees, one of the most\n\u003e problematic parts of Bitcoins design now.\n\u003e \n\u003e The disadvantages are that it can result in extra transactions that\n\u003e exist only for adding fees, and it requires a more modern payment\n\u003e protocol than the direct-IP protocol Satoshi designed.\n\u003e \n\u003e It would help address the current situation by avoiding angry users\n\u003e who want to buy things, but don't know what fee to set and so their\n\u003e transactions get stuck.\n\u003e \n\u003e (2) SatoshiDice should use the same fee algorithms as Bitcoin-Qt to\n\u003e avoid paying excessive fees and queue-jumping. Guess that's on my\n\u003e plate.\n\u003e \n\u003e (3) Scalability improvements seem like a no brainer to everyone, it's\n\u003e just a case of how complicated they are.\nI think all of the above are largely no brianers to everyone.\n\u003e \n\u003e (4) Making the block size limit float is better than picking a new\n\u003e arbitrary threshold.\nDefinitely something that is very appealing as we need to scale up.\n\u003e \n\u003e On the forums Matt stated that block chain pruning was a no-go because\n\u003e \"it makes bitcoin more centralized\". I think we've thrashed this one\n\u003e out sufficiently well by now that there should be a united opinion on\n\u003e it. There are technical ways to implement it such that there is no\n\u003e change of trust requirements. All the other issues (finding archival\n\u003e nodes, etc) can be again addressed with sufficient programming.\nMy point was that the easiest way to do it would be to ship a pruned\nsnapshot with Bitcoin, and such a system, while verifiable, would\nincrease Bitocin's centralization. Though it is quite possible to prune\nthe chain while downloading at checkpoints or when blocks are N deep, it\ncomplicates the initial download if no one has the chain to begin with. \n\nAnother point I made was that by doing chain pruning by default, we may\nsee a decrease in non-fClient nodes (for compatibility, I would assume\npruned nodes have to set fClient) which is what old clients look for to\nconnect to, possibly complicating using Bitcoin for clients that either\nwish to run a full IBD or older clients which need a non-fClient node\nbefore they are happy (which could be an issue when you look at the very\npoor \"upgrade-apathy\" in the Bitcoin community with people running\nlong-outdated versions because they don't feel like upgrading).\n\nAll that said, I do believe pruning will eventually have to come to\nencourage p2pool and other getmemorypool-based pool mining, but\n(obviously) its something that needs careful consideration in its\noverall effects across the network before its applied.\n\u003e \n\u003e For the case of huge blocks slowing down end user syncing and wasting\n\u003e their resources, SPV clients like MultiBit and Android Wallet already\n\u003e exist and will get better with time. If Jeff implements the bloom\n\u003e filtering p2p commands I'll make bitcoinj use them and that'll knock\n\u003e out excessive bandwidth usage and parse overheads from end users who\n\u003e are on these clients. At some point Bitcoin-Qt can have a dual mode,\n\u003e but who knows when that'll get implemented.\n\u003e \n\u003e Does that all sound reasonable?",
"sig": "129a1333d92e6ec8b91daef8698d970a1064530fd00ca866f22b776f3ad491337f73b630c1286892caf65aec1e6e512cf176bb89f00c620b30f2dd72b00f3e0c"
}