00:12:23 <br-m> <sgp_> PoT, described above, is utter nonsense as currently written. One clear example of this is that using the public key as a primary anti-sybil measure (e.g. in 4.4) is in direct opposition to 4.6. 4.6 says miners should avoid public key reuse to protect their privacy, entirely negating the "benefit" of the anti-sybil mechanism. In any case, public keys are free to generate.
00:12:23 <br-m> <sgp_> "the P2P layer enforces a strict limit of one intent per peer submitted strictly via localhost connection" ???
02:53:18 <br-m> <kayabanerve:matrix.org> It claims to be asynchronous yet has multiple explicit synchrony assumptions. It has a lack of formal bounds and actual proofs of neither correctness nor liveness.
09:03:49 <br-m> <articmine> It can be, but we need to be very careful here. > <@jberman> I think tying min fee to network hashpower is a valid research avenue and interesting idea
09:03:49 <br-m> <articmine> The current min fee is based upon the ability of certain transactions to scale. If we lower the min fee without compromising increase in on chain adoption we break scaling.  So in reality this is only useful to raise fees above the min required for scaling.
09:03:49 <br-m> <articmine> It is of course a good alternative to lowering the min penalty free zone to increase fees for example
09:09:55 <br-m> <articmine> An example of where this would not work would be a sudden increase in the price of Monero due to the sudden adoption of Monero by large centralized exchanges, without a corresponding increase in on-chain adoption or the advert of Monero ETFs
09:11:11 <br-m> <articmine> Again without a significant increase in on chain adoption 
09:13:59 <br-m> <articmine> The large scale adoption of Monero by custodial entities could for example be triggered by a legal collapse of blockchain surveillance.
09:27:31 <br-m> <radanne:matrix.org> > <@sgp_> PoT, described above, is utter nonsense as currently written. One clear example of this is that using the public key as a primary anti-sybil measure (e.g. in 4.4) is in direct opposition to 4.6. 4.6 says miners should avoid public key reuse to protect their privacy, entirely negating the "benefit" of the anti-sybil mechanism. In any case, public keys are free to generate.
09:27:31 <br-m> <radanne:matrix.org> You'd need to read it all in detail, it requires signing. But we will discuss on git, my time is extremely limited for the time being, as mentioned.
09:57:57 <br-m> <articmine> I would not be so fast to dismiss other options such as block signing which can be used in addition to SoP > <tevador> >50% would need the Finality layer or Lucky transactions
15:48:54 <br-m> <articmine> Interestingly Zcash had a surge in price due to a Gray-scale trust, but it was accompanied by ~4x surge in on-chain transactions. So the correlation between on chain adoption and price predicted by the Equation of Exchange did hold 
15:50:00 <br-m> <articmine> On chain adoption does correlate with  price
15:52:34 <br-m> <articmine> Monero's are designed to adapt, but only after the short term median is vetted by the long term median 
15:53:04 <br-m> <articmine> Monero's fees
16:08:17 <br-m> <reuben:firo.org> Oh some ETF? can share? Though surge in onchain transactions could be just people trading and moving funds around too across different CEXes. > <@articmine> Interestingly Zcash had a surge in price due to a Gray-scale trust, but it was accompanied by ~4x surge in on-chain transactions. So the correlation between on chain adoption and price predicted by the Equation of Exchange did hold 
16:11:01 <br-m> <articmine> It is moving funds to and from exchanges combined with price speculation. The key is that there is significant settlement on the chain. 
16:13:07 <br-m> <articmine> It is when there is significant settlement off chain between different custodians that we see a divergence between on chain transactions and price. This is exactly what is happening with Bitcoin 
16:25:14 <br-m> <articmine> Another way to look at this is: Is the travel rule involving a third party involved?
16:25:14 <br-m> <articmine> If the answer is NO then the transaction is on chain
16:25:14 <br-m> <articmine> If the answer is YES then the transaction is off chain 
17:00:11 <br-m> <kayabanerve:matrix.org> As a heads up, I updated the helioselene library to the new curves.
17:00:47 <br-m> <syntheticbird> can we avoid fast work like that, it's actually harmful to to the banking system
17:01:16 <br-m> <syntheticbird> im sorry i thought this was lounge. dont mind my joke
17:01:59 <br-m> <kayabanerve:matrix.org> It was just updating the constants after independently verifying it. The latter was the most annoying, yet tevador's new script is very helpful in that it prints why curves weren't chosen with their reasoning.
18:36:34 <br-m> <interestingband:matrix.org> "... The latter was the most annoying" yeah, verification of abtriray claims is the hardest part, it's easy to generate unproven statements
18:36:37 <br-m> <interestingband:matrix.org> aka nonsense