* [bitcoin-dev] Upcoming Transaction Priority Changes @ 2015-11-12 19:47 Matt Corallo 2015-11-12 20:12 ` Luke Dashjr 0 siblings, 1 reply; 9+ messages in thread From: Matt Corallo @ 2015-11-12 19:47 UTC (permalink / raw) To: bitcoin-dev On the IRC meeting today there was a long discussion on how to handle the old "transaction priority" stuff in 0.12. Over time the "transaction priority" stuff has added a huge amount of code and taken a bunch of otherwise-useful developer effort. There is still some debate about its usefulness going forward, but there was general agreement that it will either be removed entirely or replaced with something a bit less costly to maintain some time around 0.13. With the mempool limiting stuff already in git master, high-priority relay is disabled when mempools are full. In addition, there was agreement to take the following steps for 0.12: * Mining code will use starting priority for ease of implementation * Default block priority size will be 0 * Wallet will no longer create 0-fee transactions when mempool limiting is in effect. What this means for you is, essentially, be more careful when relying on priority to mine your transactions. If mempools are full, your transactions will be increasingly less likely to be relayed and more miners may start disabling high-priority block space. Make sure you analyze previous blocks to determine if high-priority mining is still enabled and ensure your transactions will be relayed. Matt ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes 2015-11-12 19:47 [bitcoin-dev] Upcoming Transaction Priority Changes Matt Corallo @ 2015-11-12 20:12 ` Luke Dashjr 2015-11-12 20:20 ` Chun Wang 2015-11-12 20:43 ` Jorge Timón 0 siblings, 2 replies; 9+ messages in thread From: Luke Dashjr @ 2015-11-12 20:12 UTC (permalink / raw) To: bitcoin-dev, Matt Corallo On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev wrote: > With the mempool limiting stuff already in git master, high-priority > relay is disabled when mempools are full. In addition, there was > agreement to take the following steps for 0.12: > > * Mining code will use starting priority for ease of implementation This should be optional, at least for 0.12. > * Default block priority size will be 0 We should not be influencing miner policy by changing defaults. Luke ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes 2015-11-12 20:12 ` Luke Dashjr @ 2015-11-12 20:20 ` Chun Wang 2015-11-12 20:25 ` Luke Dashjr 2015-11-12 20:43 ` Jorge Timón 1 sibling, 1 reply; 9+ messages in thread From: Chun Wang @ 2015-11-12 20:20 UTC (permalink / raw) To: Luke Dashjr; +Cc: bitcoin-dev I doubt changing the default value is useful as casual mining had long dead, and pools all have their own customized policies. But I think change the priority size to 0 is the right way to do. The sort by priority part in the block is always the best place for spam nowadays. I would think about to merge the priority, feerate, and probably sigoprate into one number, probably 576 priorities trade for 1 satoshi per kb? On Fri, Nov 13, 2015 at 4:12 AM, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev wrote: >> With the mempool limiting stuff already in git master, high-priority >> relay is disabled when mempools are full. In addition, there was >> agreement to take the following steps for 0.12: >> >> * Mining code will use starting priority for ease of implementation > > This should be optional, at least for 0.12. > >> * Default block priority size will be 0 > > We should not be influencing miner policy by changing defaults. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes 2015-11-12 20:20 ` Chun Wang @ 2015-11-12 20:25 ` Luke Dashjr 2015-11-12 20:35 ` James Hilliard 0 siblings, 1 reply; 9+ messages in thread From: Luke Dashjr @ 2015-11-12 20:25 UTC (permalink / raw) To: Chun Wang; +Cc: bitcoin-dev On Thursday, November 12, 2015 8:20:45 PM Chun Wang wrote: > The sort by priority part in the block is always the best place for spam > nowadays. What are you saying here? Spammers generally can't use the priority space at all, and it is a major way for legitimate users to get their transactions mined cheaply despite ongoing spam attempts. You're suggesting the exact opposite is true?? Please explain. Luke ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes 2015-11-12 20:25 ` Luke Dashjr @ 2015-11-12 20:35 ` James Hilliard 0 siblings, 0 replies; 9+ messages in thread From: James Hilliard @ 2015-11-12 20:35 UTC (permalink / raw) To: Luke Dashjr; +Cc: bitcoin-dev [-- Attachment #1: Type: text/plain, Size: 1212 bytes --] The priority space is causing major mempool bloating and GBT latency right now since many of the free transactions aren't getting mined and cleared out of the mempool anymore. From my testing setting minrelaytxfee=0.0001 is not enough to prevent the mempool from getting large during a spam attack, it is also necessary to set limitfreerelay=0 in order to prevent GBT latency degradation. Without setting limitfreerelay=0 GBT degrades significantly for every hour bitcoind is running. On Thu, Nov 12, 2015 at 2:25 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Thursday, November 12, 2015 8:20:45 PM Chun Wang wrote: > > The sort by priority part in the block is always the best place for spam > > nowadays. > > What are you saying here? Spammers generally can't use the priority space > at > all, and it is a major way for legitimate users to get their transactions > mined cheaply despite ongoing spam attempts. You're suggesting the exact > opposite is true?? Please explain. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 1824 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes 2015-11-12 20:12 ` Luke Dashjr 2015-11-12 20:20 ` Chun Wang @ 2015-11-12 20:43 ` Jorge Timón 2015-11-12 21:10 ` Luke Dashjr 1 sibling, 1 reply; 9+ messages in thread From: Jorge Timón @ 2015-11-12 20:43 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev wrote: >> * Mining code will use starting priority for ease of implementation > > This should be optional, at least for 0.12. The ease of implementation is not gained if it's maintained optionally. >> * Default block priority size will be 0 > > We should not be influencing miner policy by changing defaults. I agree changing policy defaults is meaningless, but in this case it is supposed to signal deprecation of the policy option. On Thu, Nov 12, 2015 at 9:20 PM, Chun Wang via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote: > I would think about to merge the priority, feerate, and probably > sigoprate into one number, probably 576 priorities trade for 1 satoshi > per kb? I am in favor of having customizable cost (currently tx size but it has been proposed to also include sigoprate) and reward (currently feerate). The main problem I see for keep maintaining the code is that priority is not integrated in the reward function and cannot easily be with its current functionality unchanged (which slows down other very necessary improvements in the mempool limits). ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes 2015-11-12 20:43 ` Jorge Timón @ 2015-11-12 21:10 ` Luke Dashjr 2015-11-12 21:21 ` Alex Morcos 0 siblings, 1 reply; 9+ messages in thread From: Luke Dashjr @ 2015-11-12 21:10 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev On Thursday, November 12, 2015 8:43:17 PM Jorge Timón wrote: > On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev > > wrote: > >> * Mining code will use starting priority for ease of implementation > > > > This should be optional, at least for 0.12. > > The ease of implementation is not gained if it's maintained optionally. It has come to my attention maintaining the current priority algorithm is not even expensive, so I think I'm inclined to NACK using starting priority altogether. Since I am the mining maintainer for Core, I believe it's reasonable for me to decide on maintenance tradeoffs... Therefore, my goal in this matter will be to review #6357 in depth to be merged, and follow up with #6898 based on the current default policies. > >> * Default block priority size will be 0 > > > > We should not be influencing miner policy by changing defaults. > > I agree changing policy defaults is meaningless, but in this case it > is supposed to signal deprecation of the policy option. This is a bad idea anyway, since priority is the best metric we have right now for ensuring legitimate transactions get mined despite spam attacks. Luke ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes 2015-11-12 21:10 ` Luke Dashjr @ 2015-11-12 21:21 ` Alex Morcos 2015-11-12 21:26 ` Luke Dashjr 0 siblings, 1 reply; 9+ messages in thread From: Alex Morcos @ 2015-11-12 21:21 UTC (permalink / raw) To: Luke Dashjr; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2353 bytes --] To be clear Luke, its not THAT complicated to maintain the mining policy, but preserving the ability of people to place priority based transactions in a limited mempool world is quite complicated. See recently closed #6992. I think the biggest issue with #6357 is being sure the logic doesn't break in future changes. There are a lot of things that need to be updated in the right order when blocks are connected or disconnected. And whats the point of having even that added extra complication if its not easy to place free transactions and starting priority is a decent approximation for mining anyway (txs can just be rebroadcast in the worst case). On Thu, Nov 12, 2015 at 4:10 PM, Luke Dashjr via bitcoin-dev < bitcoin-dev@lists•linuxfoundation.org> wrote: > On Thursday, November 12, 2015 8:43:17 PM Jorge Timón wrote: > > On Thu, Nov 12, 2015 at 9:12 PM, Luke Dashjr via bitcoin-dev > > <bitcoin-dev@lists•linuxfoundation.org> wrote: > > > On Thursday, November 12, 2015 7:47:50 PM Matt Corallo via bitcoin-dev > > > wrote: > > >> * Mining code will use starting priority for ease of implementation > > > > > > This should be optional, at least for 0.12. > > > > The ease of implementation is not gained if it's maintained optionally. > > It has come to my attention maintaining the current priority algorithm is > not > even expensive, so I think I'm inclined to NACK using starting priority > altogether. Since I am the mining maintainer for Core, I believe it's > reasonable for me to decide on maintenance tradeoffs... > > Therefore, my goal in this matter will be to review #6357 in depth to be > merged, and follow up with #6898 based on the current default policies. > > > >> * Default block priority size will be 0 > > > > > > We should not be influencing miner policy by changing defaults. > > > > I agree changing policy defaults is meaningless, but in this case it > > is supposed to signal deprecation of the policy option. > > This is a bad idea anyway, since priority is the best metric we have right > now > for ensuring legitimate transactions get mined despite spam attacks. > > Luke > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists•linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > [-- Attachment #2: Type: text/html, Size: 3173 bytes --] ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [bitcoin-dev] Upcoming Transaction Priority Changes 2015-11-12 21:21 ` Alex Morcos @ 2015-11-12 21:26 ` Luke Dashjr 0 siblings, 0 replies; 9+ messages in thread From: Luke Dashjr @ 2015-11-12 21:26 UTC (permalink / raw) To: Alex Morcos; +Cc: Bitcoin Dev On Thursday, November 12, 2015 9:21:57 PM Alex Morcos wrote: > To be clear Luke, its not THAT complicated to maintain the mining policy, > but preserving the ability of people to place priority based transactions > in a limited mempool world is quite complicated. See recently closed > #6992. > I think the biggest issue with #6357 is being sure the logic doesn't break > in future changes. There are a lot of things that need to be updated in > the right order when blocks are connected or disconnected. That's what unit tests are for. :) > And whats the point of having even that added extra complication if its not > easy to place free transactions and starting priority is a decent > approximation for mining anyway (txs can just be rebroadcast in the worst > case). I'm not sure what you're getting at here, but rebroadcasting won't work if they're still in the memory pools (unless we open the door to DoS from reprocessing the same tx over and over). Luke ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2015-11-12 21:27 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-11-12 19:47 [bitcoin-dev] Upcoming Transaction Priority Changes Matt Corallo 2015-11-12 20:12 ` Luke Dashjr 2015-11-12 20:20 ` Chun Wang 2015-11-12 20:25 ` Luke Dashjr 2015-11-12 20:35 ` James Hilliard 2015-11-12 20:43 ` Jorge Timón 2015-11-12 21:10 ` Luke Dashjr 2015-11-12 21:21 ` Alex Morcos 2015-11-12 21:26 ` Luke Dashjr
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox