-
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.
-
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.
-
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.
-
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
-
DataHoarder
used for other purposes (after mining the fee properly to prevent abuse) that could still be a privacy leak due to tx linkage
-
br-m
<routingerror:metropolis.nexus> Probably offtopic probably asked a lot but I am gonna ask anyway because I need help understanding this
-
br-m
<routingerror:metropolis.nexus> Isn't encryption in onion routing of Bitcoin lightning transactions better in terms of privacy than monero?
-
sech1
It isn't
-
sech1
And they solve slightly different tasks (lightning tx routing and Monero's Dandelion++), so it's not apples-to-apples
-
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"
-
br-m
<routingerror:metropolis.nexus> sech1: Why is IP such a big deal the internet is decentrallized
-
br-m
<routingerror:metropolis.nexus> You can just use lightning over TOR
-
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)
-
sech1
IP = KYC in most cases
-
br-m
<routingerror:metropolis.nexus> ISP's have internal NAT's...
-
br-m
<routingerror:metropolis.nexus> IP isn't static...
-
br-m
<routingerror:metropolis.nexus> Etc
-
DataHoarder
Maybe a discussion for lounge?
-
sech1
IP, outgoing port numbers, time of activity is enough to pinpoint an exact user even with ISP's NAT
-
sech1
yes, better move to -lounge
-
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"
-
sech1
#monero-research-lounge