01:25:48 <kayabaNerve> Rucknium[m]: Doesn't look like any code in existence will be worth anything
01:26:11 <kayabaNerve> Beyond saying in the paper it's incomplete, the researcher doesn't seem to be a developer
01:27:34 <kayabaNerve> I'm not denying the existence of supporting staff. I just don't believe the person who's work it primarily is would understand the needs of production code and so on. It'd be a partial reference if that, if we could get him to publicize it which I'm asking about
04:25:40 <maxwellsdemon[m]> Rucknium: when you get a chance, maybe in a 1 on 1 chat, could you fill me in on the steps forward to making a proposal and seeking funding to improve the hash rate estimator that we talked about. Been thinking a lot about it lately
04:34:37 <Rucknium[m]> maxwellsdemon: Sure. I did a short write-up of funding options in #monero-recruitment:monero.social  . You can start by reading that for now.
07:37:54 <h4sh3d> kayabaNerve: IIRC PayMo was theoretically correct but did completely omit the fact you cannot chain unbroadcasted transactions, so not feasible in practice. What’s about this work?
07:38:14 <h4sh3d> I means for monero 
07:38:23 <kayabaNerve> Was unbroadcasted TXs part of PayMo?
07:38:23 <h4sh3d> *mean
07:38:41 <kayabaNerve> Oh. Right. You can't
07:38:56 <kayabaNerve> Because the spender which has the VDF signature needs to have a valid signature before lock.
07:39:01 <kayabaNerve> This has the same problem
07:39:24 <h4sh3d> I think so, you create the the “refund” before locking, and use the vdf sigs for delaying refund validity, again IIRC
07:39:35 <kayabaNerve> Those words are a bit jumbled, sorry. I think you get me :p
07:39:56 <h4sh3d> yep
07:40:03 <kayabaNerve> Right, except you can't create XMR refunds before locking due to referential output indexes, as you point out
07:41:03 <kayabaNerve> I still think the UX is absolutely unusable. Imagine being told you had to solve a multiple hour CPU puzzle to get your money back. It's not a 2 hour delay yet a 8 hour power draw. You're working from a phone instead of a Ryzen? Try 16 hours because it needs to be timed for the more powerful device
07:41:10 <kayabaNerve> Not to mention FPGAs 0_o
07:41:21 <kayabaNerve> But I still appreciate the theoretical developments.
07:42:06 <kayabaNerve> This also shouldn't be usable for Zcash because of that actually. You need the merkle tree mined in a block included in spends. If any other shielded TX is present before the lock is mined... different merkle
07:42:10 <h4sh3d> Yeah, I really dislike the title of the paper but will give it a read during the holidays. I’m sure there is plenty of good work but looks like they claim a lot… so :)
07:42:48 <kayabaNerve> I legitimately don't hate it. The atomic swap proposals I hate are the ones saying "just send $1 at a time" or "multisig with a third party, ez, solved"
07:43:04 <h4sh3d> haha
07:43:18 <kayabaNerve> And it's legitimate improvements on the generalized application of VDF signatures (however they're called, this paper doesn't use the term VDF once)
07:43:33 <h4sh3d> ^ this
07:43:44 <kayabaNerve> But I also don't see it as a usable UX... ever? So I want to stay up to date on it but I don't care to do any work without it
07:43:52 <kayabaNerve> Except asking for them to publish their impl. That I want to see.
07:47:15 <h4sh3d> The vdf sig thing can work ;p, imagine a world where every chip as a little module, let’s say a proprietary one, that is total black box, capped in computation power, where you can send a calcul and receive the result when finished… now it doesn’t matter if you have a ryzen or you’re on the phone, little black box saves you :) /s
07:47:36 <h4sh3d> What a wonderful world that would be
07:49:21 <kayabaNerve> > first n-to- ̃n swap protocol for Monero that is
07:49:21 <kayabaNerve> efficient, does not require any hard fork,
07:49:27 <kayabaNerve> :(
07:49:40 <kayabaNerve> I feel like this dude is an extremely smart cryptographer and I love him for it
07:49:56 <kayabaNerve> Yet he published a blockchain paper without knowing the actual impl details of these blockchains
07:50:58 <h4sh3d> Let’s make sure we understand correctly the paper before saying his work is invalid, maybe they found a trick to not require any chained tx?!
07:51:49 <kayabaNerve> > To build some intuition on how to use this tool to simulate
07:51:50 <kayabaNerve> a transaction timelock, consider the case of two users (Alice
07:51:50 <kayabaNerve> and Bob) sharing an address pk AB (where each party owns
07:51:50 <kayabaNerve> a share of the corresponding secret key). Before sending
07:51:50 <kayabaNerve> the funds to pk AB , Alice and Bob jointly sign a “refund”
07:51:50 <kayabaNerve> transaction tx rfnd that transfers all funds from pk AB back to
07:51:52 <kayabaNerve> the address of Alice,
07:52:09 <kayabaNerve> Sorry for sending a IRC message flood. That should've been a single line. I'll preprocess in the future.
08:04:55 <h4sh3d> Yeah ok that’s obvious now, just started reading the paper, where is that line?
08:07:16 <kayabaNerve> P4 Second paragraph
08:18:55 <h4sh3d> P3 II. SOLUTION OVERVIEW is not precise enough about requirements: “…which is compatible with any blockchain, assuming the minimal ability to verify signatures on transactions…” < this lacks the “Segwit” thing people have some much trouble to get 
09:30:54 <kayabanerve[m]> Yep