01:39:19 <DataHoarder> On the above 0-fee txs discussion (was away for stargazing): I am also working on producing zero-fee txs that prove their inputs (so they can be confirmed p2pool) and verify Txs fully (I can already do this pre-FCMP++, on FCMP++ I can only verify BP/SAL). That'd could be something to have along sech1 in case there is contention over these spots.
01:39:19 <DataHoarder> Additionally also have all the tools now to make chained aggregated outputs (so a set of up to 16 miners could spontaneously commit to aggregate their payouts, and reduce their outputs to one per block, with "exit" payout txs pre-signed so they don't need any party trust. They could chain these along when finding blocks and aggregate. 
01:45:30 <DataHoarder> And to add, I'd also prefer an explicit coinbase consolidation tx, N coinbase in, either 1 or 2 out max. FCMP++ means public coinbase inputs no longer pollute rings and the linked issue has a long discussion about these, also see previous meetings where it was brought up. That failing reasonably implemented zero-fee could exist within the blocks.
01:45:30 <DataHoarder> I'm of the opinion to only allow p2pool txs within p2pool, as other mining pools could include their own txs on theirs, and though I haven't checked the details of the PoW proof inclusion in the merge mining that is also likely to disclose and link the tx and miner address or other details. This is fine for coinbase aggregation, but if they are
01:45:30 <DataHoarder> used for other purposes (after mining the fee properly to prevent abuse) that could still be a privacy leak due to tx linkage
10:03:02 <br-m> <routingerror:metropolis.nexus> Probably offtopic probably asked a lot but I am gonna ask anyway because I need help understanding this
10:03:02 <br-m> <routingerror:metropolis.nexus> Isn't encryption in onion routing of Bitcoin lightning transactions better in terms of privacy than monero?
10:24:54 <sech1> It isn't
10:26:32 <sech1> And they solve slightly different tasks (lightning tx routing and Monero's Dandelion++), so it's not apples-to-apples
10:28:21 <sech1> D++ solves the task of "broadcast this tx to everyone without revealing sender's IP", lightning onion routing solves the task of "send from A to B while hiding it from intermediate nodes"
10:46:59 <br-m> <routingerror:metropolis.nexus> sech1: Why is IP such a big deal the internet is decentrallized
10:47:00 <br-m> <routingerror:metropolis.nexus> You can just use lightning over TOR
10:47:00 <br-m> <routingerror:metropolis.nexus> Even chainanlysis proved that you need to run monero nodes over TOR only. (They were able to track with KYC and IP)
10:47:15 <sech1> IP = KYC in most cases
10:47:35 <br-m> <routingerror:metropolis.nexus> ISP's have internal NAT's...
10:47:46 <br-m> <routingerror:metropolis.nexus> IP isn't static...
10:47:47 <br-m> <routingerror:metropolis.nexus> Etc
10:47:58 <DataHoarder> Maybe a discussion for lounge?
10:48:04 <sech1> IP, outgoing port numbers, time of activity is enough to pinpoint an exact user even with ISP's NAT
10:48:14 <sech1> yes, better move to -lounge
10:51:20 <br-m> <routingerror:metropolis.nexus> Also how does monero prevent amount of txns, in those time periods, with these amount of funds kinda attack > <sech1> D++ solves the task of "broadcast this tx to everyone without revealing sender's IP", lightning onion routing solves the task of "send from A to B while hiding it from intermediate nodes"
10:51:35 <sech1> #monero-research-lounge