05:11:10 <m-relay> <r​brunner7:monero.social> Alright. Will go onto a fact finding mission first.
07:32:40 <m-relay> <s​pirobel:kernal.eu> bip39 has an ecosystem of audited libraries
07:33:09 <m-relay> <s​pirobel:kernal.eu> other networks + multicoin wallets rely on it as well
07:37:10 <m-relay> <s​pirobel:kernal.eu> are there any other features besides this, that differentiate polyseed from bip39?
08:44:27 <m-relay> <o​frnxmr:monero.social> Embedded birthday is probably the main one
08:59:16 <m-relay> <r​brunner7:monero.social> Yes. And it seems it can reliably correct one-word-errors based on a clever checksum.
12:14:31 <m-relay> <s​pirobel:kernal.eu> opportunity cost is quite high to not just use bip39. not sure if that is a strong enough reason. especially for multiwallet setups
12:16:10 <m-relay> <s​pirobel:kernal.eu> we should think harder about how we can get rid of the requirement for wallets to scan every single output. I saw this in the carrot spec: "the payment ID pid is encrypted by exclusive or (XOR) with an encryption mask mpid. The encryption mask is derived from the shared secrets of the payment enote." is there any good reason for this to depend on secrets only known to the sender b<clipped message>
12:16:10 <m-relay> <s​pirobel:kernal.eu> esides otherwise having the sender know that somebody already sent to this address?
12:17:29 <m-relay> <s​pirobel:kernal.eu> we should think harder about how we can get rid of the requirement for wallets to scan every single output. I saw this in the carrot spec: "the payment ID pid is encrypted by exclusive or (XOR) with an encryption mask mpid. The encryption mask is derived from the shared secrets of the payment enote." is there any good reason for this to depend on secrets only known to the sender b<clipped message>
12:17:30 <m-relay> <s​pirobel:kernal.eu> esides otherwise having the sender not know that somebody already sent to this address?