William Morriss [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-11-30 to 2017-11-30
💬 Posted a total of 3 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:07:59

- reply

📅 Original date posted:2017-11-30
📝 Original message:On Wed, Nov 29, 2017 at 9:52 PM, Chenxi Cai <Chenxi_Cai at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171129/e5fd0f84/attachment.html>

2023-06-07 18:07:57

- reply

📅 Original date posted:2017-11-30
📝 Original message:On Wed, Nov 29, 2017 at 6:38 PM, Ben Kloester <benkloester at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171129/e53585b8/attachment.html>

2023-06-07 18:07:56

- reply

📅 Original date posted:2017-11-29
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171129/96ea6877/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedblocksize.png
Type: image/png
Size: 18199 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171129/96ea6877/attachment-0003.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: fixedblocksize.png
Type: image/png
Size: 18199 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171129/96ea6877/attachment-0004.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: marginal.png
Type: image/png
Size: 21403 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171129/96ea6877/attachment-0005.png>