<a​rticmine:monero.social> Google docs not play well with external storage

<a​rticmine:monero.social> They want to force cloud storage

<a​rticmine:monero.social> This is not really a technical issue.

<o​frnxmr:monero.social> Older android versions accept external ssd's

<o​frnxmr:monero.social> android 14 terminal doesnt like to mount them properly

<o​frnxmr:monero.social> My point was that me android 10 phone can be expanded to likely >1tb via usb. My pixel 8 cannot

<a​rticmine:monero.social> It is a very valid point. Understanding why is in my view necessary to solve this

<a​rticmine:monero.social> The solution may be to fork Android and make it incompatible with Google's business model.

ofrnxmr: is it just form factor that makes you prefer an old phone to an old laptop?

<k​ayabanerve:matrix.org> monero-project/research-lab #129 was intended to be about extending to support PCNs but it establishes a private time lock proposal at minimal cost which wouldn't require the existing time lock queue (which is a DoS risk).

<s​yntheticbird:monero.social> Enough! We already tolerated Serai XMR integration, let you build the next adaptation of FCMP for RingCT solving privacy issues of monero, AND NOW payment channels? You know a single ground breaking achievement is enough to be remembered in history right?

<s​yntheticbird:monero.social> (more seriously very exciting MRL issue)

<k​ayabanerve:matrix.org> TBF I'd have supported this a few months ago but I don't believe I do now

<k​ayabanerve:matrix.org> Assuming it fits into the set size budget (the 210 billion current set size targeted is overkill, we potentially can shave it down to fit this in), it's better than the queue to accumulate into the tree and associated DoS risk we're now discussing mitigation of. While I believe it's a better solution, I don't think it's such a better solution it's worth moving to. I'd alternativel<clipped message

<k​ayabanerve:matrix.org> y argue the best solution is to void all existing timelocks and be done with them until the potential reintroduction as a conditional selector here (though that solution burns a lot of political capital and we decided honoring timelocks with the queue was simple enough).

<k​ayabanerve:matrix.org> I mainly wanted to advertise how we can extend the membership proof with logic to accomplish applications such as PCNs. I gave a talk on full SCs at Monerokon (via having the spend-auth proof not prove knowledge of a secret, yet correct execution of the program associated with the spent output). This isn't nearly as complicated. This is just a few small pieces in the circuit which<clipped message

<k​ayabanerve:matrix.org> achieve specific functionality in a private manner.

<k​ayabanerve:matrix.org> Sorry for the late response, I got pulled away (out of office and all)

<k​ayabanerve:matrix.org> Curve forests to shave down bandwidth, support for PCNs, an IVC scheme to achieve constant size/time bandwidth regardless of inputs/outputs... there's a lot of interesting paths forward with various years of time which can be estimated

<k​ayabanerve:matrix.org> The private timelock scheme alone is trivial enough in the scheme of things. The conditional key selection... may not be enough to support PCNs? Does it qualify as a PTLC? Is a PTLC sufficient?

<k​ayabanerve:matrix.org> There really has to be a survey of PCNs and their requirements (and nice-to-haves like lnhance) for that issue to make progress.

<k​ayabanerve:matrix.org> *I'd have supported the private timelock scheme a few months ago