adlai
commented
9 years ago We should adopt a flexible approach, letting takers each configure their own prioritization weightings, while provide sane (or even beneficial) defaults (similar to what we've done with merge policy). Prioritizing height (eg, [volume-weighted? [geometric] mean? ...] average number of confirmations on contributed inputs) or "Bitcoin days destroyed" (total of each input's size multiplied by its confirmation count) incentivises adding new coins to, and thus increasing, the anonymity set, aligning incentives with the common good rather than the current perversion of shuffling about the money already invested in a slightly more "fungible" manner.
We've already seen JoinMarket's incentive start to twist: before #266, the simplest way to boost your volume was redundant orders; today, it is running multiple yield generators. This either fragments your wallet (reducing the maximum output size, eroding the market's usefulness to transaction initiators), or requires you to operate multiple bots off the same wallet, running a risk of duplicated UTXOs in a single transaction (causing failed transactions, and alerting The Customer to twisted game afoot).
Prioritizing for coin age rewards liquidity provision over fee undercutting, and leads to better engagement of all market participants in transaction graph braiding. My inclination is that fee minimization should only enter the picture when performing iterated transactions (as in the tumbler script), or choosing between inputs with similar coinage priority.
Consider this, a common sight in recent days:
(for readability, I've converted these values to BTC, satoshi and percent) [2015/10/22 07:11:49] <<pubmsg nick=Tedokadix message=!relorder 0 100000 45.24945649 0 0.04999% [2015/10/22 07:11:50] <<pubmsg nick=Topihuruv message=!relorder 0 100000 51.38726145 0 0.00799% [2015/10/22 07:11:50] <<pubmsg nick=Rocibemic message=!relorder 0 100000 373.08731647 0 0.01999% [2015/10/22 07:11:50] <<pubmsg nick=Vufoqoxis message=!relorder 0 100000 76.20593615 0 0.00899% [2015/10/22 07:11:50] <<pubmsg nick=Fegonovug message=!relorder 0 100000 164.22799530 0 0.00999% [2015/10/22 07:11:50] <<pubmsg nick=Gatudilub message=!relorder 0 100000 208.95232675 0 0.01499% [2015/10/22 04:18:57] << :Rocibemic!username@CgAn-ac4.jrm.vk09of.IP QUIT :Ping timeout: 121 seconds [2015/10/22 04:18:58] << :Fegonovug!username@CgAn-ac4.jrm.vk09of.IP QUIT :Ping timeout: 121 seconds [2015/10/22 04:19:00] << :Tedokadix!username@CgAn-ac4.jrm.vk09of.IP QUIT :Ping timeout: 121 seconds [2015/10/22 04:19:21] << :Gatudilub!username@CgAn-ac4.jrm.vk09of.IP QUIT :Ping timeout: 121 seconds [2015/10/22 04:19:21] << :Topihuruv!username@CgAn-ac4.jrm.vk09of.IP QUIT :Ping timeout: 121 seconds [2015/10/22 04:19:34] << :Vufoqoxis!username@CgAn-ac4.jrm.vk09of.IP QUIT :Ping timeout: 121 seconds
Wouldn't it be nice if the participant formerly known as Torusexox could signal to the market the interest (and interest!) for three-digit BTC volume, while also being able to perform hundreds of single- or tens of double-digit transactions with the same liquidity? Who knows, it may even smoke out our first myriadaire maker.
Another (negative) consideration is the total size contributed by the maker to the transaction. Shouldn't a maker who can offer fewer inputs (best: a single input, just barely smaller than the coinjoin amount; the liquidity fee covers the difference and no change output is needed!) be prioritized over one who bloats the transaction with dozens of dusty nickles?
chris-belcher
To reduce possible sybil attacks, incentivize new coins being brought into the anonymity set, and increasing the chances of new makers being chosen for each coinjoin, I propose that takers somehow choose orders based on height, bitcoin-days-destroyed and maybe size in bytes.
There's a few ways this might work in practice.
One is the makers announce a list of bitcoin amounts, heights/confirmations, bytes, bitcoin-days-destroyed, priority, etc
So the yield generator algorithm could have a range (in log space) of bitcoin-days-destroyed or heights and announce the prices for each one. The taker checks at some point whether the send UTXOs match the maker's claims.
In practice the protocol would be modified with a 'soft fork'. Creating a new kind of order.
Another way is that the taker sends a !fill order to every single maker in the orderbook and simply throws away the unsuitable UTXOs. I think this is a bad idea for many many reasons.