* Re: [bitcoin-dev] BIP Idea: Marginal Pricing
2017-11-30 0:47 [bitcoin-dev] BIP Idea: Marginal Pricing William Morriss
@ 2017-11-30 2:38 ` Ben Kloester
2017-11-30 6:13 ` William Morriss
2017-11-30 9:37 ` Federico Tenga
2017-11-30 5:52 ` Chenxi Cai
` (3 subsequent siblings)
4 siblings, 2 replies; 12+ messages in thread
From: Ben Kloester @ 2017-11-30 2:38 UTC (permalink / raw)
To: William Morriss, Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 4298 bytes --]
Something similar to this has been proposed in this article by Ron Lavi,
Or Sattath, and Aviv Zohar, and discussed in this bitcoin-dev thread
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015093.html
They only discussed changing the fee structure, not removing the block size
limit, as far as I know.
"Redesigning Bitcoin's fee market"
https://arxiv.org/abs/1709.08881
*Ben Kloester*
On 30 November 2017 at 11:47, William Morriss via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Comrades,
>
> Long term, tx fees must support hash power by themselves. The following is
> an economic approach to maximize total fee collection, and therefore
> hashpower.
>
> *Goals*
> Maximize total transaction fees
> Reduce pending transaction time
> Reduce individual transaction fees
>
> *Challenges*
> Validators must agree on the maximum block size, else miners can cheat and
> include extra transactions.
> Allowing too many transactions per block will increase the cost of the
> mining without collecting much income for the network.
>
>
> *Problem*
> In the transaction market, users are the demand curve, because they will
> transact less when fees are higher, and prefer altcoins. The block size is
> the supply curve, because it represents miners' willingness to accept
> transactions.
> Currently, the supply curve is inelastic:
>
> Increasing the block size will not affect the inelasticity for any fixed
> block size. The downsides of a fixed block size limit are well-known:
> - Unpredictable transaction settlement time
> - Variable transaction fees depending on network congestion
> - Frequent overpay
>
> *Proposal*
> 1. Miners implicitly choose the market sat/byte rate with the cheapest-fee
> transaction included in their block. Excess transaction fees are refunded
> to the inputs.
> 2. Remove the block size limit, which is no longer necessary.
>
> *Benefits*
> - Dynamic block size limit regulated by profit motive
> - Transaction fees maximized for every block
> - No overpay; all fees are fair
>
> Miners individually will make decisions to maximize their block-reward
> profit.
> Miners are incentivized to ignore low-fee transactions because they would
> shave the profits of their other transactions and increase their hash time.
> Users and services are free to bid higher transaction fees in order to
> reach the next block, since their excess bid will be refunded.
>
> The block size limit was added as a spam-prevention measure, but in order
> for an attacker to spam the network with low-fee transactions, they would
> have to offset the marginal cost of reducing the price with their own
> transaction fees. Anti-spam is thus built into the marginal system without
> the need for an explicit limit.
>
> Rarely, sections of the backlog would become large enough to be
> profitable. This means every so many blocks, lower-fee transactions would
> be included en masse after having been ignored long enough. Low-fee
> transactions thus gain a liveness property not previously enjoyed: low-fee
> transactions will eventually confirm. Miners targeting these transactions
> would be at a noteworthy disadvantage because they would be hashing a
> larger block. I predict that this scheme would result in two markets: a
> backlog market and a real-time market. Users targeting the backlog market
> would match the price of the largest backlog section in order to be
> included in the next backlog block.
>
> *Examples*
>
> Scenario 1
> Sat/byte Bytes Reward
> 400 500000 200000000
> 300 700000 210000000
> 200 1000000 200000000
> 100 1500000 150000000
> 50 5000000 250000000
> 20 10000000 200000000
> A miner would create a 5MB block and receive 0.25 BTC
>
> Scenario 2
> Sat/byte Bytes Reward
> 400 600000 240000000
> 300 700000 210000000
> 200 1000000 200000000
> 100 1800000 180000000
> 50 4000000 200000000
> 20 10000000 200000000
> A miner would create a 600KB block and receive 0.24 BTC
>
> Thanks,
> William Morriss
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #1.2: Type: text/html, Size: 11065 bytes --]
[-- Attachment #2: fixedblocksize.png --]
[-- Type: image/png, Size: 18199 bytes --]
[-- Attachment #3: marginal.png --]
[-- Type: image/png, Size: 21403 bytes --]
[-- Attachment #4: fixedblocksize.png --]
[-- Type: image/png, Size: 18199 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [bitcoin-dev] BIP Idea: Marginal Pricing
2017-11-30 2:38 ` Ben Kloester
@ 2017-11-30 6:13 ` William Morriss
2017-11-30 11:40 ` Gregory Maxwell
2017-11-30 12:03 ` Eric Voskuil
2017-11-30 9:37 ` Federico Tenga
1 sibling, 2 replies; 12+ messages in thread
From: William Morriss @ 2017-11-30 6:13 UTC (permalink / raw)
To: Ben Kloester; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]
On Wed, Nov 29, 2017 at 6:38 PM, Ben Kloester <benkloester@gmail•com> wrote:
> Something similar to this has been proposed in this article by Ron Lavi,
> Or Sattath, and Aviv Zohar, and discussed in this bitcoin-dev thread
> https://lists.linuxfoundation.org/pipermail/bitcoin-
> dev/2017-September/015093.html
>
> They only discussed changing the fee structure, not removing the block
> size limit, as far as I know.
>
> "Redesigning Bitcoin's fee market"
> https://arxiv.org/abs/1709.08881
>
> *Ben Kloester*
>
Thanks. Marginal pricing is equivalent to the "Monopolistic Price
Mechanism" discussed in https://arxiv.org/abs/1709.08881. The mechanism is
the same, including the block size adjustment, but as you noted the prior
discussion only concerns the fee structure.
It looks like the prior proposal broke down because of Peter Todd's concern
with out-of-band payments (https://lists.linuxfoundation.org/pipermail/
bitcoin-dev/2017-September/015103.html). Restated, miners can circumvent
the system through out of band payments. Mark Friedenbach argues that
out-of-band payments are penalized in part because the end-user could have
just as easily bid higher instead of paying OOB. Peter Todd argues that a
miner could mine only out-of-band transactions. Such transactions could
have no on-chain fees and thus be disregarded by other miners.
I believe this OOB scenario is imaginary. Either it would be more
profitable for a miner to mine fairly, or cheaper for the end-user to pay
the fee in-band. Consider MINFEE to the the effective fee paid for the
block mined by the OOB-incentivized miner. Consider MARKFEE to the the
market fee collected by non-OOB-incentivized miners. Call the OOB effective
tx fee OOB. Then,
For a user to prefer OOB: MINFEE+OOB<MARKFEE
For a miner to prefer OOB: MINFEE+OOB>MARKFEE
It is impossible for both scenarios to be true. As previously argued by
Mark Friedenbach, the system disincentivizes OOB tx fees.
I don't think there is any more centralization pressure with marginal fees
than before. What prevents miners from colluding to move tx fees OOB is the
value of the on-band pending tx fees. The hashpower of individual miners is
not impressive compared to the entire network, so individual miners could
not offer a service to speed up confirmation that would be superior to
simply doing a RBP. OOB fees are perhaps a symptom of the current setup,
wherein there is no penalty for arbitrarily favoring individual
transactions with lower fees.
[-- Attachment #2: Type: text/html, Size: 4200 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP Idea: Marginal Pricing
2017-11-30 6:13 ` William Morriss
@ 2017-11-30 11:40 ` Gregory Maxwell
2017-11-30 12:03 ` Eric Voskuil
1 sibling, 0 replies; 12+ messages in thread
From: Gregory Maxwell @ 2017-11-30 11:40 UTC (permalink / raw)
To: William Morriss, Bitcoin Protocol Discussion
On Thu, Nov 30, 2017 at 6:13 AM, William Morriss via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> I believe this OOB scenario is imaginary. Either it would be more profitable
Out of band fees are a reality even today-- and have for most of
Bitcoin's life--, without a system that has any particular incentive
for them.
> for a miner to mine fairly, or cheaper for the end-user to pay the fee
> in-band. Consider MINFEE to the the effective fee paid for the block mined
> by the OOB-incentivized miner. Consider MARKFEE to the the market fee
> collected by non-OOB-incentivized miners. Call the OOB effective tx fee OOB.
> Then,
> For a user to prefer OOB: MINFEE+OOB<MARKFEE
> For a miner to prefer OOB: MINFEE+OOB>MARKFEE
> It is impossible for both scenarios to be true. As previously argued by Mark
> Friedenbach, the system disincentivizes OOB tx fees.
This kind of analysis seems to imagine that a single decision maker is
making a globally optimal decision and that also people are somehow
forced to only make one choice. Both are untrue in this case (and most
other economic circumstances). Instead, participants can take the best
of multiple choices and will often act locally for their own best
interest even when it reduces revenue for their industry in total.
Concretely: as a user with competent wallet software, I would be
automatically drafting two transactions-- one paying OOB and one
paying min fee, at equivalent expected rates. Miners would construct
blocks which locally maximized their revenue. It is far from clear
that use of the minfee scheme is an equilibrium-- in fact I think it
is clearly not an equilibrium: a user that writes both transactions
will always pay equal or less fees for the transactions where they do
both (even if all users doing this causes users collectively to pay
higher fees), a miner who considers both will always make equal or
greater fee income on a block by block basis (even if it lowers miner
income collectively when all do this).
(If it were in fact preferred by users and miners alike: why doesn't
it already exist? Since the existence of OOB fees cannot be
eliminated, as far as we know, any use of MINFEE would be inherently
voluntary-- so in one sense we already 'have' voluntary minfee, but no
one uses it.)
Ignoring the possibility of evasion, there are some other concerns
that you might want to consider:
I believe the idea converts variance in fee willingness into variance
in capacity for the network. If rich uncle bill wants to waste money
with uneconomically high fees, with a constant flow of transactions,
he'll effectively knock out a large number of participants. You could
argue that bill could spend those same fees in spam to displace the
same amount of transactions while also using more capacity; but I
UncleBill isn't trying to attack the capacity of the system. It's just
collateral damage. I worry also about related strategies that arise
in that world: For example, lets imagine that world consisted of a
couple unclebill who will pay high fees, and the unwashed masses that
will not and pay a much lower consistent feerate. Honest conformance
with your protocol would result in miners either processing only the
UncleBill txn or processing all of them at the lower rate, whichever
is more profitable. Super-rational behavior might be for a majority
of hashpower to collude to only permit high fee-rate transactions
every other block and only permit low feerate in the others, and then
the network processes all unclebills in one block (at full rate), and
all the unwashed in the others. From a fee perspective it arguably
isn't any worse than today, but I believe it significantly handicaps
your capacity limiting argument.
> wherein there is no penalty for arbitrarily favoring individual transactions with lower fees
Nor does a MINFEE system; since the user can near costlessly construct
as many variations of their transaction as they like.
> The hashpower of individual miners is not impressive compared to the entire network,
That is unfortunately not the reality of Bitcoin today.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP Idea: Marginal Pricing
2017-11-30 6:13 ` William Morriss
2017-11-30 11:40 ` Gregory Maxwell
@ 2017-11-30 12:03 ` Eric Voskuil
1 sibling, 0 replies; 12+ messages in thread
From: Eric Voskuil @ 2017-11-30 12:03 UTC (permalink / raw)
To: William Morriss, Bitcoin Protocol Discussion, Ben Kloester
[-- Attachment #1.1: Type: text/plain, Size: 3232 bytes --]
On 11/29/2017 10:13 PM, William Morriss via bitcoin-dev wrote:
> On Wed, Nov 29, 2017 at 6:38 PM, Ben Kloester <benkloester@gmail•com
> <mailto:benkloester@gmail•com>> wrote:
>
> Something similar to this has been proposed in this article by Ron
> Lavi, Or Sattath, and Aviv Zohar, and discussed in this bitcoin-dev
> thread https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015093.html
>
> They only discussed changing the fee structure, not removing the
> block size limit, as far as I know.
>
> "Redesigning Bitcoin's fee market"
> https://arxiv.org/abs/1709.08881 <https://arxiv.org/abs/1709.08881>
>
> *Ben Kloester*
>
> Thanks. Marginal pricing is equivalent to the "Monopolistic Price
> Mechanism" discussed in https://arxiv.org/abs/1709.08881
> The mechanism is the same, including
> the block size adjustment, but as you noted the prior discussion only
> concerns the fee structure.
>
> It looks like the prior proposal broke down because of Peter Todd's
> concern with out-of-band payments
> (https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/015103.html).
> Restated, miners can circumvent the system through out of band payments.
> Mark Friedenbach argues that out-of-band payments are penalized in part
> because the end-user could have just as easily bid higher instead of
> paying OOB. Peter Todd argues that a miner could mine only out-of-band
> transactions. Such transactions could have no on-chain fees and thus be
> disregarded by other miners.
>
> I believe this OOB scenario is imaginary. Either it would be more
> profitable for a miner to mine fairly, or cheaper for the end-user to
> pay the fee in-band.
> Consider MINFEE to the the effective fee paid for
> the block mined by the OOB-incentivized miner. Consider MARKFEE to the
> the market fee collected by non-OOB-incentivized miners. Call the OOB
> effective tx fee OOB. Then,
> For a user to prefer OOB: MINFEE+OOB<MARKFEE
> For a miner to prefer OOB: MINFEE+OOB>MARKFEE
> It is impossible for both scenarios to be true. As previously argued by
> Mark Friedenbach, the system disincentivizes OOB tx fees.
Bitcoin is neutral on how miners are paid. The benefit of on-chain fee
payment is that a fee can be paid with no communication between the
miner and the merchant, preserving anonymity. It also serves as a
convenience that anonymous fees are published, as it provides a basis
for anonymous fee estimation. There is no centralization pressure that
arises from side fees.
https://github.com/libbitcoin/libbitcoin/wiki/Side-Fee-Fallacy
> I don't think there is any more centralization pressure with marginal
> fees than before. What prevents miners from colluding to move tx fees
> OOB is the value of the on-band pending tx fees. The hashpower of
> individual miners is not impressive compared to the entire network, so
> individual miners could not offer a service to speed up confirmation
> that would be superior to simply doing a RBP. OOB fees are perhaps a
> symptom of the current setup, wherein there is no penalty for
> arbitrarily favoring individual transactions with lower fees.
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP Idea: Marginal Pricing
2017-11-30 2:38 ` Ben Kloester
2017-11-30 6:13 ` William Morriss
@ 2017-11-30 9:37 ` Federico Tenga
1 sibling, 0 replies; 12+ messages in thread
From: Federico Tenga @ 2017-11-30 9:37 UTC (permalink / raw)
To: Ben Kloester, Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 4972 bytes --]
The main issue that I see with this proposal is that miners can still spam
the network for free even with high sat/byte fee levels. They can first
choose the sat/byte rate that maximize their profit, and then include a lot
of spam transactions at that rate that will only pay fees to themselves,
effectively spamming the chain for free and increasing the cost of running
a node.
On 30 Nov 2017 03:40, "Ben Kloester via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
Something similar to this has been proposed in this article by Ron Lavi,
Or Sattath, and Aviv Zohar, and discussed in this bitcoin-dev thread
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/
015093.html
They only discussed changing the fee structure, not removing the block size
limit, as far as I know.
"Redesigning Bitcoin's fee market"
https://arxiv.org/abs/1709.08881
*Ben Kloester*
On 30 November 2017 at 11:47, William Morriss via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> Comrades,
>
> Long term, tx fees must support hash power by themselves. The following is
> an economic approach to maximize total fee collection, and therefore
> hashpower.
>
> *Goals*
> Maximize total transaction fees
> Reduce pending transaction time
> Reduce individual transaction fees
>
> *Challenges*
> Validators must agree on the maximum block size, else miners can cheat and
> include extra transactions.
> Allowing too many transactions per block will increase the cost of the
> mining without collecting much income for the network.
>
>
> *Problem*
> In the transaction market, users are the demand curve, because they will
> transact less when fees are higher, and prefer altcoins. The block size is
> the supply curve, because it represents miners' willingness to accept
> transactions.
> Currently, the supply curve is inelastic:
>
> Increasing the block size will not affect the inelasticity for any fixed
> block size. The downsides of a fixed block size limit are well-known:
> - Unpredictable transaction settlement time
> - Variable transaction fees depending on network congestion
> - Frequent overpay
>
> *Proposal*
> 1. Miners implicitly choose the market sat/byte rate with the cheapest-fee
> transaction included in their block. Excess transaction fees are refunded
> to the inputs.
> 2. Remove the block size limit, which is no longer necessary.
>
> *Benefits*
> - Dynamic block size limit regulated by profit motive
> - Transaction fees maximized for every block
> - No overpay; all fees are fair
>
> Miners individually will make decisions to maximize their block-reward
> profit.
> Miners are incentivized to ignore low-fee transactions because they would
> shave the profits of their other transactions and increase their hash time.
> Users and services are free to bid higher transaction fees in order to
> reach the next block, since their excess bid will be refunded.
>
> The block size limit was added as a spam-prevention measure, but in order
> for an attacker to spam the network with low-fee transactions, they would
> have to offset the marginal cost of reducing the price with their own
> transaction fees. Anti-spam is thus built into the marginal system without
> the need for an explicit limit.
>
> Rarely, sections of the backlog would become large enough to be
> profitable. This means every so many blocks, lower-fee transactions would
> be included en masse after having been ignored long enough. Low-fee
> transactions thus gain a liveness property not previously enjoyed: low-fee
> transactions will eventually confirm. Miners targeting these transactions
> would be at a noteworthy disadvantage because they would be hashing a
> larger block. I predict that this scheme would result in two markets: a
> backlog market and a real-time market. Users targeting the backlog market
> would match the price of the largest backlog section in order to be
> included in the next backlog block.
>
> *Examples*
>
> Scenario 1
> Sat/byte Bytes Reward
> 400 500000 200000000
> 300 700000 210000000
> 200 1000000 200000000
> 100 1500000 150000000
> 50 5000000 250000000
> 20 10000000 200000000
> A miner would create a 5MB block and receive 0.25 BTC
>
> Scenario 2
> Sat/byte Bytes Reward
> 400 600000 240000000
> 300 700000 210000000
> 200 1000000 200000000
> 100 1800000 180000000
> 50 4000000 200000000
> 20 10000000 200000000
> A miner would create a 600KB block and receive 0.24 BTC
>
> Thanks,
> William Morriss
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists•linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[-- Attachment #1.2: Type: text/html, Size: 12434 bytes --]
[-- Attachment #2: fixedblocksize.png --]
[-- Type: image/png, Size: 18199 bytes --]
[-- Attachment #3: fixedblocksize.png --]
[-- Type: image/png, Size: 18199 bytes --]
[-- Attachment #4: marginal.png --]
[-- Type: image/png, Size: 21403 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP Idea: Marginal Pricing
2017-11-30 0:47 [bitcoin-dev] BIP Idea: Marginal Pricing William Morriss
2017-11-30 2:38 ` Ben Kloester
@ 2017-11-30 5:52 ` Chenxi Cai
2017-11-30 6:05 ` William Morriss
[not found] ` <CAAS2fgS5jiNCmdwEt3YtZMJ0SfhC8Hw1eXr_0Vo5AQhYv7bJfg@mail.gmail.com>
` (2 subsequent siblings)
4 siblings, 1 reply; 12+ messages in thread
From: Chenxi Cai @ 2017-11-30 5:52 UTC (permalink / raw)
To: William Morriss, Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 5176 bytes --]
Hi All,
Auction theory is a well-studied problem in the economics literature. Currently what bitcoin has is Generalized first-price auction, where winning bidders pay their full bids. Alternatively, two approaches are potentially viable, which are Generalized second-price auction and Vickrey–Clarke–Groves auction. Generalized second-price auction, where winning bidders pay their next highest bids, reduces (but not eliminate) the need for bidders to strategize by allowing them to bid closer to their reservation price. Vickrey–Clarke–Groves auction, a more sophisticated system that considers all bids in relation to one another, elicit truthful bids from bidders, but may not maximize miners' fees as the other two systems will.
Due to one result called Revenue Equivalence, the choice of fee design will not impact miners' fees unless the outcomes of the auction changes (i.e, the highest bidders do not always win). In addition, the sole benefit of second-price auction over first-price auction is to spare people's mental troubles from strategizing, rather than actually saving mining fees, because in equilibrium the fees bidders pay remain the same. Therefore, in balance, I do not see substantial material benefits arising from switching to a different fee schedule.
Best,
Chenxi Cai
________________________________
From: bitcoin-dev-bounces@lists•linuxfoundation.org <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of William Morriss via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Sent: Wednesday, November 29, 2017 5:47 PM
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] BIP Idea: Marginal Pricing
Comrades,
Long term, tx fees must support hash power by themselves. The following is an economic approach to maximize total fee collection, and therefore hashpower.
Goals
Maximize total transaction fees
Reduce pending transaction time
Reduce individual transaction fees
Challenges
Validators must agree on the maximum block size, else miners can cheat and include extra transactions.
Allowing too many transactions per block will increase the cost of the mining without collecting much income for the network.
Problem
In the transaction market, users are the demand curve, because they will transact less when fees are higher, and prefer altcoins. The block size is the supply curve, because it represents miners' willingness to accept transactions.
Currently, the supply curve is inelastic:
[cid:ii_jalpxsnl1_1600a3d9def1eaff]
Increasing the block size will not affect the inelasticity for any fixed block size. The downsides of a fixed block size limit are well-known:
- Unpredictable transaction settlement time
- Variable transaction fees depending on network congestion
- Frequent overpay
Proposal
1. Miners implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block. Excess transaction fees are refunded to the inputs.
2. Remove the block size limit, which is no longer necessary.
Benefits
- Dynamic block size limit regulated by profit motive
- Transaction fees maximized for every block
- No overpay; all fees are fair
[cid:ii_jalqir4g2_1600a4c89811347a]
Miners individually will make decisions to maximize their block-reward profit.
Miners are incentivized to ignore low-fee transactions because they would shave the profits of their other transactions and increase their hash time.
Users and services are free to bid higher transaction fees in order to reach the next block, since their excess bid will be refunded.
The block size limit was added as a spam-prevention measure, but in order for an attacker to spam the network with low-fee transactions, they would have to offset the marginal cost of reducing the price with their own transaction fees. Anti-spam is thus built into the marginal system without the need for an explicit limit.
Rarely, sections of the backlog would become large enough to be profitable. This means every so many blocks, lower-fee transactions would be included en masse after having been ignored long enough. Low-fee transactions thus gain a liveness property not previously enjoyed: low-fee transactions will eventually confirm. Miners targeting these transactions would be at a noteworthy disadvantage because they would be hashing a larger block. I predict that this scheme would result in two markets: a backlog market and a real-time market. Users targeting the backlog market would match the price of the largest backlog section in order to be included in the next backlog block.
Examples
Scenario 1
Sat/byte Bytes Reward
400 500000 200000000
300 700000 210000000
200 1000000 200000000
100 1500000 150000000
50 5000000 250000000
20 10000000 200000000
A miner would create a 5MB block and receive 0.25 BTC
Scenario 2
Sat/byte Bytes Reward
400 600000 240000000
300 700000 210000000
200 1000000 200000000
100 1800000 180000000
50 4000000 200000000
20 10000000 200000000
A miner would create a 600KB block and receive 0.24 BTC
Thanks,
William Morriss
[-- Attachment #1.2: Type: text/html, Size: 12562 bytes --]
[-- Attachment #2: fixedblocksize.png --]
[-- Type: image/png, Size: 18199 bytes --]
[-- Attachment #3: fixedblocksize.png --]
[-- Type: image/png, Size: 18199 bytes --]
[-- Attachment #4: marginal.png --]
[-- Type: image/png, Size: 21403 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [bitcoin-dev] BIP Idea: Marginal Pricing
2017-11-30 5:52 ` Chenxi Cai
@ 2017-11-30 6:05 ` William Morriss
[not found] ` <CY4PR1201MB0197936CBE467B38DCC26DC986380@CY4PR1201MB0197.namprd12.prod.outlook.com>
0 siblings, 1 reply; 12+ messages in thread
From: William Morriss @ 2017-11-30 6:05 UTC (permalink / raw)
To: Chenxi Cai; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]
On Wed, Nov 29, 2017 at 9:52 PM, Chenxi Cai <Chenxi_Cai@live•com> wrote:
> Hi All,
>
>
> Auction theory is a well-studied problem in the economics literature.
> Currently what bitcoin has is Generalized first-price auction, where
> winning bidders pay their full bids. Alternatively, two approaches are
> potentially viable, which are Generalized second-price auction and Vickrey–Clarke–Groves
> auction. Generalized second-price auction, where winning bidders pay their
> next highest bids, reduces (but not eliminate) the need for bidders to
> strategize by allowing them to bid closer to their reservation
> price. Vickrey–Clarke–Groves auction, a more sophisticated system that
> considers all bids in relation to one another, elicit truthful bids from
> bidders, but may not maximize miners' fees as the other two systems will.
>
>
> Due to one result called Revenue Equivalence, the choice of fee design
> will not impact miners' fees unless the outcomes of the auction changes
> (i.e, the highest bidders do not always win). In addition, the sole benefit
> of second-price auction over first-price auction is to spare people's
> mental troubles from strategizing, rather than actually saving mining fees,
> because in equilibrium the fees bidders pay remain the same. Therefore, in
> balance, I do not see substantial material benefits arising from switching
> to a different fee schedule.
>
>
> Best,
>
> Chenxi Cai
>
>
Changing the bidding system to the marginal price allows us to supersede
the block size limit, which changes the outcome of the auction, as
different transactions are included.
[-- Attachment #2: Type: text/html, Size: 2579 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
[parent not found: <CAAS2fgS5jiNCmdwEt3YtZMJ0SfhC8Hw1eXr_0Vo5AQhYv7bJfg@mail.gmail.com>]
* Re: [bitcoin-dev] BIP Idea: Marginal Pricing
[not found] ` <CAAS2fgS5jiNCmdwEt3YtZMJ0SfhC8Hw1eXr_0Vo5AQhYv7bJfg@mail.gmail.com>
@ 2017-11-30 9:12 ` Gregory Maxwell
0 siblings, 0 replies; 12+ messages in thread
From: Gregory Maxwell @ 2017-11-30 9:12 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 5341 bytes --]
This idea presumes that the protocol has any ability to regulate fees. I
believe the locally optimal strategy for both miners and payers alike is to
accept (pay) zero fees natively in the protocol and instead accept (pay)
their actual fees out-of-band or via OP_TRUE outputs which the miner can
simply collect. Then the miner sets the fee threshold to ~0 and selects
transactions on the basis of out of band fees.
Miners today already accept out-of-band fees, and as far back as at least
2011 there were miners that would also accept fees in the form of
additional transaction outputs which they were able to spend.
On Thu, Nov 30, 2017 at 9:11 AM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
>
>
> This idea presumes that the protocol has any ability to regulate fees. I
> believe the locally optimal strategy for both miners and payers alike is to
> accept (pay) zero fees natively in the protocol and instead accept (pay)
> their actual fees out-of-band or via OP_TRUE outputs which the miner can
> simply collect. Then the miner sets the fee threshold to ~0 and selects
> transactions on the basis of out of band fees.
>
> Miners today already accept out-of-band fees, and as far back as at least
> 2011 there were miners that would also accept fees in the form of
> additional transaction outputs which they were able to spend.
>
>
>
> On Thu, Nov 30, 2017 at 12:47 AM, William Morriss via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> Comrades,
>>
>> Long term, tx fees must support hash power by themselves. The following
>> is an economic approach to maximize total fee collection, and therefore
>> hashpower.
>>
>> *Goals*
>> Maximize total transaction fees
>> Reduce pending transaction time
>> Reduce individual transaction fees
>>
>> *Challenges*
>> Validators must agree on the maximum block size, else miners can cheat
>> and include extra transactions.
>> Allowing too many transactions per block will increase the cost of the
>> mining without collecting much income for the network.
>>
>>
>> *Problem*
>> In the transaction market, users are the demand curve, because they will
>> transact less when fees are higher, and prefer altcoins. The block size is
>> the supply curve, because it represents miners' willingness to accept
>> transactions.
>> Currently, the supply curve is inelastic:
>>
>> Increasing the block size will not affect the inelasticity for any
>> fixed block size. The downsides of a fixed block size limit are well-known:
>> - Unpredictable transaction settlement time
>> - Variable transaction fees depending on network congestion
>> - Frequent overpay
>>
>> *Proposal*
>> 1. Miners implicitly choose the market sat/byte rate with the
>> cheapest-fee transaction included in their block. Excess transaction fees
>> are refunded to the inputs.
>> 2. Remove the block size limit, which is no longer necessary.
>>
>> *Benefits*
>> - Dynamic block size limit regulated by profit motive
>> - Transaction fees maximized for every block
>> - No overpay; all fees are fair
>>
>> Miners individually will make decisions to maximize their block-reward
>> profit.
>> Miners are incentivized to ignore low-fee transactions because they would
>> shave the profits of their other transactions and increase their hash time.
>> Users and services are free to bid higher transaction fees in order to
>> reach the next block, since their excess bid will be refunded.
>>
>> The block size limit was added as a spam-prevention measure, but in order
>> for an attacker to spam the network with low-fee transactions, they would
>> have to offset the marginal cost of reducing the price with their own
>> transaction fees. Anti-spam is thus built into the marginal system without
>> the need for an explicit limit.
>>
>> Rarely, sections of the backlog would become large enough to be
>> profitable. This means every so many blocks, lower-fee transactions would
>> be included en masse after having been ignored long enough. Low-fee
>> transactions thus gain a liveness property not previously enjoyed: low-fee
>> transactions will eventually confirm. Miners targeting these transactions
>> would be at a noteworthy disadvantage because they would be hashing a
>> larger block. I predict that this scheme would result in two markets: a
>> backlog market and a real-time market. Users targeting the backlog market
>> would match the price of the largest backlog section in order to be
>> included in the next backlog block.
>>
>> *Examples*
>>
>> Scenario 1
>> Sat/byte Bytes Reward
>> 400 500000 200000000
>> 300 700000 210000000
>> 200 1000000 200000000
>> 100 1500000 150000000
>> 50 5000000 250000000
>> 20 10000000 200000000
>> A miner would create a 5MB block and receive 0.25 BTC
>>
>> Scenario 2
>> Sat/byte Bytes Reward
>> 400 600000 240000000
>> 300 700000 210000000
>> 200 1000000 200000000
>> 100 1800000 180000000
>> 50 4000000 200000000
>> 20 10000000 200000000
>> A miner would create a 600KB block and receive 0.24 BTC
>>
>> Thanks,
>> William Morriss
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
[-- Attachment #2: Type: text/html, Size: 11430 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [bitcoin-dev] BIP Idea: Marginal Pricing
2017-11-30 0:47 [bitcoin-dev] BIP Idea: Marginal Pricing William Morriss
` (2 preceding siblings ...)
[not found] ` <CAAS2fgS5jiNCmdwEt3YtZMJ0SfhC8Hw1eXr_0Vo5AQhYv7bJfg@mail.gmail.com>
@ 2017-12-01 7:58 ` Ryan J Martin
2017-12-02 3:55 ` Damian Williamson
4 siblings, 0 replies; 12+ messages in thread
From: Ryan J Martin @ 2017-12-01 7:58 UTC (permalink / raw)
To: William Morriss, Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 7463 bytes --]
Interesting thoughts William, however much of what you describe already exists:
"I predict that this scheme would result in two markets: a backlog market and a real-time market. Users targeting the backlog market would match the price of the largest backlog section in order to be included in the next backlog block."
This happens with users deciding to pay (essentially) a fee smaller or larger than the 1999th tx in the mempool. If user is willing to pay more than the 1999th highest fee tx in mempool (or whatever tx byte 1,000,000 in a mempool ranked by tx fee) then they will get to be on the next block. This is a simplification but you get the idea.
Further, Greg Maxwell's one reply covers alot of the biggest pitfalls well. Especially that much of this already happens and that behavior in response to such a change could be hairy to predict. So I'm not sure that---what is basically--- a multi-unit Vickrey auction is the best way to go... but it is an interesting idea worth further examination.
Second, minimizing invididual user tx fees and maximizing total tx fees are essentially incompatible within the current development structure. Even if the block limit is increased to 3mb the same problem will eventually occur. While I agree it would be ideal to maximize social benefit (i.e. maximize both consumer and producer surplus) through more simple protocol changes---at least in the medium term, that isn't on the table so it is better to move on.
This is not an easy optimization problem to solve though. The difficulty is trying to model a market like bitcoin; the only thing that comes close is electricity markets. With 2,000 tx in the pool, users aren't willing to pay shit to send a tx; there is always a miner to process it. So at 2,000tx per 10 min (3.333 txps, 1mb/10min,etc) and below users price elasticity is flat. Once the pool has >2,000 tx in it, especially for any extended amount of time, users price elasticity is about as elastic as a brick and goes near vertical. This creates a situation where miners are always better off when there is a significant backlog (this can be seen in miners revenue from tx fees anytime there is an ongoing backlog).
Simply put, it would take some very large blocks to have total fees/block exceed total fees/block for constrained size blocks given the near vertical price elasticity users face when there is a backlog.
So I suspect that the multi-unit Vickrey would potentially do some to help this, but likely not much:
Users willingness to pay is what they pay---no surplus. Miner elasticity is more or less flat but we can call their willingness to accept whatever the lowest fee tx is in a block. Say it is 180 sat/b (NL), and the highest tx fee in a block (NH)is 320 sat/b. If you subtract each tx in the block (N) greater than NL
and sum the result you get surplus to miners: Σ(N1,2...- NL)
So, yes, the multi-unit Vickrey simply shifts the surplus to users. However, a case could be made that since---as mentioned in an earlier reply, the optimal strategy for miners is to accept zero fees (given their flat elasticity), and therefore all fees are surplus benefit to miners---shifting this surplus over to consumers could create some good effects. Primarily pushing users' price elasticity away from near vertical inelasticity as it would take some of the upward pressure off rapidly increasing fees in a backlog scenario.
It would be interesting to see a simulation of how this would play out, but without that this is too risky to implement.
Regards,
Ryan J. Martin (tunafizz / ohituna)
________________________________
From: bitcoin-dev-bounces@lists•linuxfoundation.org [bitcoin-dev-bounces@lists•linuxfoundation.org] on behalf of William Morriss via bitcoin-dev [bitcoin-dev@lists•linuxfoundation.org]
Sent: Wednesday, November 29, 2017 7:47 PM
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] BIP Idea: Marginal Pricing
Comrades,
Long term, tx fees must support hash power by themselves. The following is an economic approach to maximize total fee collection, and therefore hashpower.
Goals
Maximize total transaction fees
Reduce pending transaction time
Reduce individual transaction fees
Challenges
Validators must agree on the maximum block size, else miners can cheat and include extra transactions.
Allowing too many transactions per block will increase the cost of the mining without collecting much income for the network.
Problem
In the transaction market, users are the demand curve, because they will transact less when fees are higher, and prefer altcoins. The block size is the supply curve, because it represents miners' willingness to accept transactions.
Currently, the supply curve is inelastic:
[cid:ii_jalpxsnl1_1600a3d9def1eaff]
Increasing the block size will not affect the inelasticity for any fixed block size. The downsides of a fixed block size limit are well-known:
- Unpredictable transaction settlement time
- Variable transaction fees depending on network congestion
- Frequent overpay
Proposal
1. Miners implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block. Excess transaction fees are refunded to the inputs.
2. Remove the block size limit, which is no longer necessary.
Benefits
- Dynamic block size limit regulated by profit motive
- Transaction fees maximized for every block
- No overpay; all fees are fair
[cid:ii_jalqir4g2_1600a4c89811347a]
Miners individually will make decisions to maximize their block-reward profit.
Miners are incentivized to ignore low-fee transactions because they would shave the profits of their other transactions and increase their hash time.
Users and services are free to bid higher transaction fees in order to reach the next block, since their excess bid will be refunded.
The block size limit was added as a spam-prevention measure, but in order for an attacker to spam the network with low-fee transactions, they would have to offset the marginal cost of reducing the price with their own transaction fees. Anti-spam is thus built into the marginal system without the need for an explicit limit.
Rarely, sections of the backlog would become large enough to be profitable. This means every so many blocks, lower-fee transactions would be included en masse after having been ignored long enough. Low-fee transactions thus gain a liveness property not previously enjoyed: low-fee transactions will eventually confirm. Miners targeting these transactions would be at a noteworthy disadvantage because they would be hashing a larger block. I predict that this scheme would result in two markets: a backlog market and a real-time market. Users targeting the backlog market would match the price of the largest backlog section in order to be included in the next backlog block.
Examples
Scenario 1
Sat/byte Bytes Reward
400 500000 200000000
300 700000 210000000
200 1000000 200000000
100 1500000 150000000
50 5000000 250000000
20 10000000 200000000
A miner would create a 5MB block and receive 0.25 BTC
Scenario 2
Sat/byte Bytes Reward
400 600000 240000000
300 700000 210000000
200 1000000 200000000
100 1800000 180000000
50 4000000 200000000
20 10000000 200000000
A miner would create a 600KB block and receive 0.24 BTC
Thanks,
William Morriss
[-- Attachment #1.2: Type: text/html, Size: 17328 bytes --]
[-- Attachment #2: fixedblocksize.png --]
[-- Type: image/png, Size: 18199 bytes --]
[-- Attachment #3: fixedblocksize.png --]
[-- Type: image/png, Size: 18199 bytes --]
[-- Attachment #4: marginal.png --]
[-- Type: image/png, Size: 21403 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread* Re: [bitcoin-dev] BIP Idea: Marginal Pricing
2017-11-30 0:47 [bitcoin-dev] BIP Idea: Marginal Pricing William Morriss
` (3 preceding siblings ...)
2017-12-01 7:58 ` Ryan J Martin
@ 2017-12-02 3:55 ` Damian Williamson
4 siblings, 0 replies; 12+ messages in thread
From: Damian Williamson @ 2017-12-02 3:55 UTC (permalink / raw)
To: William Morriss, Bitcoin Protocol Discussion
[-- Attachment #1.1: Type: text/plain, Size: 5051 bytes --]
I also am for the idea of removing blocksize limits if it is workable, however, would propose an alternative method for selecting transactions to be included in a block.
Some of the issues discussed in other replies to this thread are valid.
Alternative proposal:
Provide each transaction with a transaction weight, being a function of the fee paid (on a curve), and the time waiting in the 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 an uncapped block size. The curve allows that the higher a fee allows a transaction to be much more likely to be included, the highest fee gets 100%, and, transactions at the n days limit get near 100%. Would need protocol enforcement since, as I understand, no miner would mine more transactions than are necessary to meet min blocksize. Other than that it should function fine. Non-urgent transactions pay a lower fee, people choose fees from fee recommendation based on how many days before a tx begins confirmation, all transactions are eventually included in the blockchain.
Regards,
Damian Williamson
________________________________
From: bitcoin-dev-bounces@lists•linuxfoundation.org <bitcoin-dev-bounces@lists•linuxfoundation.org> on behalf of William Morriss via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Sent: Thursday, 30 November 2017 11:47:43 AM
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] BIP Idea: Marginal Pricing
Comrades,
Long term, tx fees must support hash power by themselves. The following is an economic approach to maximize total fee collection, and therefore hashpower.
Goals
Maximize total transaction fees
Reduce pending transaction time
Reduce individual transaction fees
Challenges
Validators must agree on the maximum block size, else miners can cheat and include extra transactions.
Allowing too many transactions per block will increase the cost of the mining without collecting much income for the network.
Problem
In the transaction market, users are the demand curve, because they will transact less when fees are higher, and prefer altcoins. The block size is the supply curve, because it represents miners' willingness to accept transactions.
Currently, the supply curve is inelastic:
[cid:ii_jalpxsnl1_1600a3d9def1eaff]
Increasing the block size will not affect the inelasticity for any fixed block size. The downsides of a fixed block size limit are well-known:
- Unpredictable transaction settlement time
- Variable transaction fees depending on network congestion
- Frequent overpay
Proposal
1. Miners implicitly choose the market sat/byte rate with the cheapest-fee transaction included in their block. Excess transaction fees are refunded to the inputs.
2. Remove the block size limit, which is no longer necessary.
Benefits
- Dynamic block size limit regulated by profit motive
- Transaction fees maximized for every block
- No overpay; all fees are fair
[cid:ii_jalqir4g2_1600a4c89811347a]
Miners individually will make decisions to maximize their block-reward profit.
Miners are incentivized to ignore low-fee transactions because they would shave the profits of their other transactions and increase their hash time.
Users and services are free to bid higher transaction fees in order to reach the next block, since their excess bid will be refunded.
The block size limit was added as a spam-prevention measure, but in order for an attacker to spam the network with low-fee transactions, they would have to offset the marginal cost of reducing the price with their own transaction fees. Anti-spam is thus built into the marginal system without the need for an explicit limit.
Rarely, sections of the backlog would become large enough to be profitable. This means every so many blocks, lower-fee transactions would be included en masse after having been ignored long enough. Low-fee transactions thus gain a liveness property not previously enjoyed: low-fee transactions will eventually confirm. Miners targeting these transactions would be at a noteworthy disadvantage because they would be hashing a larger block. I predict that this scheme would result in two markets: a backlog market and a real-time market. Users targeting the backlog market would match the price of the largest backlog section in order to be included in the next backlog block.
Examples
Scenario 1
Sat/byte Bytes Reward
400 500000 200000000
300 700000 210000000
200 1000000 200000000
100 1500000 150000000
50 5000000 250000000
20 10000000 200000000
A miner would create a 5MB block and receive 0.25 BTC
Scenario 2
Sat/byte Bytes Reward
400 600000 240000000
300 700000 210000000
200 1000000 200000000
100 1800000 180000000
50 4000000 200000000
20 10000000 200000000
A miner would create a 600KB block and receive 0.24 BTC
Thanks,
William Morriss
[-- Attachment #1.2: Type: text/html, Size: 12058 bytes --]
[-- Attachment #2: fixedblocksize.png --]
[-- Type: image/png, Size: 18199 bytes --]
[-- Attachment #3: fixedblocksize.png --]
[-- Type: image/png, Size: 18199 bytes --]
[-- Attachment #4: marginal.png --]
[-- Type: image/png, Size: 21403 bytes --]
^ permalink raw reply [flat|nested] 12+ messages in thread
![[-- Attachment #2: fixedblocksize.png --] [-- Type: image/png, Size: 18199 bytes --]](../../CANgJ=T8ZHbC4R3Rs5kZG8HfGs8810jj01WN4Ssiketej0md4kA@mail.gmail.com/2-fixedblocksize.png){kind=link}
![[-- Attachment #3: marginal.png --] [-- Type: image/png, Size: 21403 bytes --]](../../CANgJ=T8ZHbC4R3Rs5kZG8HfGs8810jj01WN4Ssiketej0md4kA@mail.gmail.com/3-marginal.png){kind=link}
![[-- Attachment #4: fixedblocksize.png --] [-- Type: image/png, Size: 18199 bytes --]](../../CANgJ=T8ZHbC4R3Rs5kZG8HfGs8810jj01WN4Ssiketej0md4kA@mail.gmail.com/4-fixedblocksize.png){kind=link}
![[-- Attachment #2: fixedblocksize.png --] [-- Type: image/png, Size: 18199 bytes --]](../../CAP=-fx7gGhR1G+kGZuS8OLgRk1KWGcNz8EDX=6KuhRaOrpPCVA@mail.gmail.com/2-fixedblocksize.png){kind=link}
![[-- Attachment #3: fixedblocksize.png --] [-- Type: image/png, Size: 18199 bytes --]](../../CAP=-fx7gGhR1G+kGZuS8OLgRk1KWGcNz8EDX=6KuhRaOrpPCVA@mail.gmail.com/3-fixedblocksize.png){kind=link}
![[-- Attachment #4: marginal.png --] [-- Type: image/png, Size: 21403 bytes --]](../../CAP=-fx7gGhR1G+kGZuS8OLgRk1KWGcNz8EDX=6KuhRaOrpPCVA@mail.gmail.com/4-marginal.png){kind=link}
![[-- Attachment #2: fixedblocksize.png --] [-- Type: image/png, Size: 18199 bytes --]](../../CY4PR1201MB019720B8D7C7AE10182F893186380@CY4PR1201MB0197.namprd12.prod.outlook.com/2-fixedblocksize.png){kind=link}
![[-- Attachment #3: fixedblocksize.png --] [-- Type: image/png, Size: 18199 bytes --]](../../CY4PR1201MB019720B8D7C7AE10182F893186380@CY4PR1201MB0197.namprd12.prod.outlook.com/3-fixedblocksize.png){kind=link}
![[-- Attachment #4: marginal.png --] [-- Type: image/png, Size: 21403 bytes --]](../../CY4PR1201MB019720B8D7C7AE10182F893186380@CY4PR1201MB0197.namprd12.prod.outlook.com/4-marginal.png){kind=link}
![[-- Attachment #2: fixedblocksize.png --] [-- Type: image/png, Size: 18199 bytes --]](../../127281C1AA02374F8AAD9EE04FAE878A0218FACE16@STUDMail1.muad.local/2-fixedblocksize.png){kind=link}
![[-- Attachment #3: fixedblocksize.png --] [-- Type: image/png, Size: 18199 bytes --]](../../127281C1AA02374F8AAD9EE04FAE878A0218FACE16@STUDMail1.muad.local/3-fixedblocksize.png){kind=link}
![[-- Attachment #4: marginal.png --] [-- Type: image/png, Size: 21403 bytes --]](../../127281C1AA02374F8AAD9EE04FAE878A0218FACE16@STUDMail1.muad.local/4-marginal.png){kind=link}
![[-- Attachment #2: fixedblocksize.png --] [-- Type: image/png, Size: 18199 bytes --]](../../PS2P216MB01795C34139200B8537AF2549D3E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM/2-fixedblocksize.png){kind=link}
![[-- Attachment #3: fixedblocksize.png --] [-- Type: image/png, Size: 18199 bytes --]](../../PS2P216MB01795C34139200B8537AF2549D3E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM/3-fixedblocksize.png){kind=link}
![[-- Attachment #4: marginal.png --] [-- Type: image/png, Size: 21403 bytes --]](../../PS2P216MB01795C34139200B8537AF2549D3E0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM/4-marginal.png){kind=link}