Rucknium[m]: Doesn't look like any code in existence will be worth anything

Beyond saying in the paper it's incomplete, the researcher doesn't seem to be a developer

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

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

maxwellsdemon: Sure. I did a short write-up of funding options in #monero-recruitment:monero.social . You can start by reading that for now.

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?

I means for monero

Was unbroadcasted TXs part of PayMo?

*mean

Oh. Right. You can't

Because the spender which has the VDF signature needs to have a valid signature before lock.

This has the same problem

I think so, you create the the “refund” before locking, and use the vdf sigs for delaying refund validity, again IIRC

Those words are a bit jumbled, sorry. I think you get me :p

yep

Right, except you can't create XMR refunds before locking due to referential output indexes, as you point out

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

Not to mention FPGAs 0_o

But I still appreciate the theoretical developments.

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

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 :)

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"

haha

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)

^ this

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

Except asking for them to publish their impl. That I want to see.

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

What a wonderful world that would be

> first n-to- ̃n swap protocol for Monero that is

efficient, does not require any hard fork,

:(

I feel like this dude is an extremely smart cryptographer and I love him for it

Yet he published a blockchain paper without knowing the actual impl details of these blockchains

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?!

> To build some intuition on how to use this tool to simulate

a transaction timelock, consider the case of two users (Alice

and Bob) sharing an address pk AB (where each party owns

a share of the corresponding secret key). Before sending

the funds to pk AB , Alice and Bob jointly sign a “refund”

transaction tx rfnd that transfers all funds from pk AB back to

the address of Alice,

Sorry for sending a IRC message flood. That should've been a single line. I'll preprocess in the future.

Yeah ok that’s obvious now, just started reading the paper, where is that line?

P4 Second paragraph

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

Yep