--- Log opened Tue May 18 00:00:58 2021
03:08 -!- nubis [~nubis@119.12.230.31] has joined #lnp-bp
03:16 < nubis> Hi, I'm Nubis. I'm currently working on timestamping solution that aims to offer extremely cheap bitcoin timestamping in a way that commitments can be easily understood by judges. Also, a digital signing service so that anyone with a bitcoin wallet can sign legally valid documents. I've recently discovered LNP/BP and it makes me think I may be reinventing the wheel with some protocols. But I
03:16 < nubis> haven't read them all. Still catching up with the amazing work you are doing.
03:17 < dr-orlovsky> Hi Nubis! Thank you for writing us :) Regarding the timestamping, you probably do not need all the complexity of what we have in LNP/BP with single-use-seals etc
03:17 < nubis> I'm essentially reading from https://github.com/LNP-BP/LNPBPs all the specs that talk about identity and timestamping.
03:18 < dr-orlovsky> probably what you need is just to put commitments inside public keys and than transactions and store the proofs of the commitment at client-side
03:18 < dr-orlovsky> so these are LNPBP-1, 2 and 3 standard and we do have their rust implementation which you can use. We call these standards "deterministic bitcoin commitments"
03:18 < nubis> Hi there! Yeah, my prototype now looks more like an extremely dumbed down open timestamps.
03:20 < nubis> Ok, so I probably won't be needing to use these unless I start offering tools for people to build smart contracts in which I'm not one of the interested parties.
03:20 < nubis> by me I mean my company.
03:20 < dr-orlovsky> Next, you will need to merklize multiple commitments, and that can be probably done in a more efficient and safe way (than in the original opentimestamps) with LNPBP-81, which takes a lot from more recent Peter Todd ideas. I have not finished its text, but the implementation is already in place inside client_side_validation repository
03:21 < dr-orlovsky> to store the information about timestamps you may find useful client_side_validation::strict_encoding crate
03:21 < nubis> (taking notes)
03:21 < dr-orlovsky> the rest of stuff is probably not needed for you
03:21 < nubis> ok, strict encoding seems useful. I'm intentionally not using merkle trees for the timestamps. I know, sounds crazy.
03:22 < dr-orlovsky> So, LNPBP-81 merklization: https://github.com/LNP-BP/client_side_validation/blob/master/commit_verify/src/merkle.rs
03:22 < nubis> and expensive.
03:22 < dr-orlovsky> oh, ok, than you do not need that
03:22 < dr-orlovsky> well, you can do that without Merkle trees by just utilizing elliptic curve homomorphic properties
03:23 < dr-orlovsky> however you will need an interactive protocol for that (if you will use some centralized provider for making timestamping cheaper)
03:23 < nubis> I think it deserves an explanation: I'm building plain bulletins full of hashes (commitments) and trying to distribute those bulletins, which are in turn commited as an OP_RETURN on chain.
03:23 < dr-orlovsky> ok, but why do you need OP_RETURN? It is more expensive than without it
03:24 < dr-orlovsky> just put the commitment into public key, that's all you need. Use LNPBP-1 and that is all you need in this case
03:25 < nubis> I intend to provide a simple set of instructions where hashing the document, and seeing is commited to a bulletin, and then hashing the bulletin and seeing it's commited to a TX in the block explorer, would help explain a judge about its validity without needing an expert forensics
03:25 < dr-orlovsky> the implementation of LNPBP-1 is here: https://github.com/LNP-BP/rust-lnpbp/blob/master/src/dbc/pubkey.rs
03:27 < nubis> Oh, I think I get what you mean. If I put the commitment in the public key, then I can 'chain' all bulletins by spending to new commitments?
03:27 < dr-orlovsky> if you will use OP_RETURN in this case you would not need anything else than strict encoding for serializing the data & creating commitments. But be aware: strict encoding is created for client-side-validation and restricts structured data to 64k elements only. If you will have a larger data than strict encoding might not be needed or you need to fork it
03:27 < dr-orlovsky> > If I put the commitment in the public key, then I can 'chain' all bulletins by spending to new commitments?
03:27 < dr-orlovsky> not exactly
03:28 < dr-orlovsky> by putting commitment to pubkey you (1) save onchain storage, since you will do a transaction with 1 input and 1 output only (and the output will basically pay a change back to you)
03:28 < nubis> as a previous 'commitment' or rules of this timestamping, I'll set up a specific address, so all TX's that have the OP_RETURN also have to come and return to the same address.
03:28 < nubis> ohhh
03:28 < nubis> got it.
03:28 < nubis> Yeah, no OP_RETURN is cheaper.
03:28 < nubis> I'll look into that.
03:29 < dr-orlovsky> yes, 42 bytes cheaper
03:29 < nubis> But I was curious if maybe I was missing some protocol where I could use LN for incremental commits then do a single 'big one' on chain.
03:29 < dr-orlovsky> however when you will be spending the output with tweaked pubkey you will need a custom signer to tweak the private key
03:30 < dr-orlovsky> LN idea is a nice one, but no such protocol exists today. You are welcome to propose it and we can do it a LNPBP standard
03:32 < nubis> I know LN has arbitrary data, but on the other hand, it's not persistent once the channel is closed, so for timestamping is kind of ephemeral, the judge will end up looking at an on-chain tx and can only be sure of the block time.
03:32 < nubis> I haven't read up on LN arbitrary data space though. Just read it exists.
03:33 < nubis> the other standard I think I'd like to implement is "BIP32/43-based standard for Schnorr signatures & decentralized identity"
03:34 < nubis> I think government issued digital certificates and signatures are kludgy and old tech. Bitcoin has incentiviced the creation of digital signatures for the masses.
03:35 < dr-orlovsky> nubis: LN timestamping is not a proof, but you may construct a custom channel which will emit onchain transactions from time to time and still will not close the channel ("channel factory"-style functionality)
03:35 < nubis> So for signing legally valid documents I'll be KYC'ing people and letting them use bitcoin sign message.
03:36 < dr-orlovsky> yeah, that will be nice. My time is very limited so I am unable to do everything that is needed for this :(
03:36 < nubis> RE: "channel factory" got it, makes sense, I can make my own channel and never close it, makes sense, and I have an incentive to do that.
03:37 < dr-orlovsky> this will require a custom LN node supporting that, but we have one (called LNP Node) which can be easily customized for doing such stuff
03:37 < nubis> no worries, I'll make sure that the legacy legal system treats bitcoiners as first class citizens.
03:38 < dr-orlovsky> anyway I am willing to help you in what you do, at least on a suggestion level (+ peer reviwing). Do not hesitate to write about your stuff once you will review what we have so far in regard to your area of interest - or just simply asking questions in the process
03:38 < dr-orlovsky> have to run, will be able to check in later at night (i'm on european time)
03:39 < nubis> I'll definitely look into custom LN channel rather soon. Otherwise by my calculations my timestamps are going to cost me 1000 EUR a month and will be precise for a 12 hour window. Got to get that window down, and that fees bill down as well, until I get funding hehe.
03:39 < nubis> I'm in Spain, don't want to take much of your time either, it was really helpful talking to you.
03:40 < nubis> I'll write a bit more about what I'm doing for signatures and see if there's a protocol I can use for key derivation instead of coming up with my own.
03:40 < nubis> thanks again!
04:03 < dr-orlovsky> nubis: just not to forget. I think "perfect" timestamping protocol (if I will be designing one) will use sign-to-contract commitments (which will require no tweaks to private keys in spent time), custom LN channels for calendaring service (with scheduled onchain transaction containing commitments emitted from the channel), strict encoding LNPBP-81 merklization and RGB anchor-like data structures for storing proofs. Proofs may be stored and
04:03 < dr-orlovsky> provided upon request via P2P API using LN P2P protocol extension I call Bifrost.
04:06 < dr-orlovsky> and, probably, should like with bitcoin-based identity from that "BIP32/43-based standard for Schnorr signatures & decentralized identity"
04:07 < dr-orlovsky> *like -> link
04:18 -!- nubis [~nubis@119.12.230.31] has quit [Ping timeout: 265 seconds]
04:19 -!- nubis [~nubis@119.12.230.31] has joined #lnp-bp
04:32 < nubis> Thanks dr-orlovsky, I've read about bifrost, decentralizing storage is in my roadmap, was looking at IPFS and Storj, but I think for my incentives a Bifrost type of contract would be better as I'd like to contract with specific counterparties (even if pseudonyms), not a cloud of freelancers. I'm in a weird spot because I have to interface with the legal world which is still dominated by human
04:32 < nubis> interaction, so my tech proposal is a bit 'cyborg'
04:33 < dr-orlovsky> nubis: wrote you in private, can you confirm that you've got my message there?
04:34 < nubis> I like to think about it like in the robocop movies, where they had to put up with feeding the cyborg baby food, but in the end having a human in the machine proved valuable vs the pure machines that went nuts and starting shooting up everything.
06:23 -!- johnonchain[m] [johnonchai@gateway/shell/matrix.org/x-pehgldadxxtqeqfa] has quit [Ping timeout: 276 seconds]
06:23 -!- lederstrumpf [lederstrum@gateway/shell/matrix.org/x-rmhoqptmadmadnis] has quit [Ping timeout: 276 seconds]
06:23 -!- OlivLutinus[m] [lutinusneo@gateway/shell/matrix.org/x-tfsistqrbaixxooi] has quit [Ping timeout: 260 seconds]
06:24 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-syflqngawnpoajif] has quit [Ping timeout: 245 seconds]
06:25 -!- johnonchain[m] [johnonchai@gateway/shell/matrix.org/x-jvtajdawukceavhi] has joined #lnp-bp
06:27 -!- lederstrumpf [lederstrum@gateway/shell/matrix.org/x-whwzixontdytfzyz] has joined #lnp-bp
06:29 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-oarzsnkfbxwexdyu] has joined #lnp-bp
06:33 -!- rocket_fuel_ [sid2662@gateway/web/irccloud.com/x-hgvozpozjqabbadi] has quit [Ping timeout: 245 seconds]
06:37 -!- OlivLutinus[m] [lutinusneo@gateway/shell/matrix.org/x-arcvspaezbgvdlbb] has joined #lnp-bp
06:44 -!- rocket_fuel_ [sid2662@gateway/web/irccloud.com/x-chqckcguingicqbj] has joined #lnp-bp
09:55 -!- h4sh3d [~h4sh3dm]@109.202.212.237] has joined #lnp-bp
12:43 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Quit: ZNC 1.8.0 - https://znc.in]
13:04 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has joined #lnp-bp
14:01 < nubis> hi dr-orlovsky
14:02 < nubis> quick question (still catching up on my reading of the things we talked about today) Are you familiar with https://eips.ethereum.org/EIPS/eip-712 ?
14:03 < nubis> Although it's a work in progress, I like how they focused on helping the person know about what they're signing
14:07 < nubis> and I think something like that may mix well with proposal 43 of LNP/BP
14:10 < nubis> I'll come back with a more refined idea
16:26 -!- OlivLutinus[m] [lutinusneo@gateway/shell/matrix.org/x-arcvspaezbgvdlbb] has quit [Ping timeout: 245 seconds]
16:50 -!- OlivLutinus[m] [lutinusneo@gateway/shell/matrix.org/x-zkkpwzgcbqhfdyan] has joined #lnp-bp
18:17 -!- zkao [~zkao@2001:1620:4392:0:3253:2fe8:d245:70ca] has quit [Ping timeout: 250 seconds]
18:18 -!- zkao [~zkao@185.183.195.146] has joined #lnp-bp
--- Log closed Wed May 19 00:00:59 2021