< sdaftuar>
jeremyrubin: i caught up on the scrollback. i think to get a sense of why large numbers of descendants are currently problematic (even if total size of descendant package is not too big) it might be helpful for you to take a look at CreateNewBlock, and the mempool's RemoveForBlock functions
< sdaftuar>
one possibility is that you might come up with algorithmic improvements to how we do things, which would mitigate the issues around large numbers of descendants
< sdaftuar>
it sounds like you're aware of the basic problems we have with relay policy for transactions involving lots of different users - a low feerate tx with many outputs to different users can be effectively "pinned" with a low feerate by any recipient who chains a bunch of low-feerate descendants
< sdaftuar>
so i think if we can improve that basic problem, that's likely to help your usecase as well
< sdaftuar>
harding: i thought your CSV idea was pretty clever, and sounds to me like it would work exactly as you suggest (current mempool policy doesn't allow things that are not confirmable in the next block to be accepted to the mempool)
< sdaftuar>
jeremyrubin: one practical thought to the issue you're seeing with a payment to 1000 outputs using a radix of 4: couldn't the sender just put a likely-to-be-confirmed-soon fee on the first five transactions (top 2 levels of the tree)? seems like that's a really small number of bytes, and once those are confirmed the situation gets much better
< instagibbs>
CSV on output idea is a non-starter unless you have wallet-buyin(was discussed early 2018), though I hear LN might do it(yay bolts)
< sdaftuar>
instagibbs: i actually misspoke when i said CSV; i think the sender could just put appropriate sequence numbers on the transaction tree (which are enforced by the COSHV hash, if i understand correctly)
< sipa>
jonasschnelli: feel free to cherry pick them
< jonasschnelli>
will do
< instagibbs>
sdaftuar, I'm just speaking in general about pinning, I haven't had time to dive into the other proposals
< sdaftuar>
ah, fair point
< instagibbs>
but yeah I think that sounds right, you encumber the future spends' sequence number right?
< instagibbs>
no need for CSV
< sdaftuar>
right, jeremy's proposal has the property that (at least in his specific use-case discussed above) the sender is manufacturing a tree of transactions and committing to a bunch of state in those transactions, so enforcing a sequence number in some of those spends is doable (though he says undesirable, so perhaps a pointless discussion)
< instagibbs>
In general I think accidental pinning(which disallows CPFP at least) is ~solved provided you have a change output for 0.19. Malicious pinning still unsolved.
< * instagibbs>
end digression
< gleb>
><wumpus> might be able to smuggle that into addrv2 somehow; it has a proposed message for a peer to signify support for v2 addrsses, maybe it could signify 'no addr support' as well
< gleb>
I'm looking at the BIP-155 in bips repo and it has only 1 new type of message which contains addresses. No signalling for support.
< MarcoFalke>
gleb: bip 155 is a draft in the rep
< MarcoFalke>
*repo
< MarcoFalke>
dongcarl is going to fix it up some day (tm)
< bitcoin-git>
[bitcoin] Sjors opened pull request #17219: wallet: allow transaction without change if keypool is empty (master...2019/10/change-without-keypool) https://github.com/bitcoin/bitcoin/pull/17219
< bitcoin-git>
[bitcoin] JeremyCrookshank closed pull request #17180: gui: Improved tooltip for send amount field (master...sendamounttooltip) https://github.com/bitcoin/bitcoin/pull/17180
< bitcoin-git>
[bitcoin] JeremyCrookshank reopened pull request #17180: gui: Improved tooltip for send amount field (master...sendamounttooltip) https://github.com/bitcoin/bitcoin/pull/17180
< bitcoin-git>
[bitcoin] adamjonas opened pull request #17220: tests: Add unit testing for the CompressScript function (master...add_compress_test_cases) https://github.com/bitcoin/bitcoin/pull/17220
< bitcoin-git>
[bitcoin] JeremyCrookshank opened pull request #17221: refactor: call getDisplayUnit() once instead of three times (master...sendcoincodereuse) https://github.com/bitcoin/bitcoin/pull/17221
< bitcoin-git>
[bitcoin] JeremyCrookshank closed pull request #17221: refactor: call getDisplayUnit() once instead of three times (master...sendcoincodereuse) https://github.com/bitcoin/bitcoin/pull/17221