{"type":"rich","version":"1.0","title":"ZmnSCPxj [ARCHIVE] wrote","author_name":"ZmnSCPxj [ARCHIVE] (npub1g5…3ms3l)","author_url":"https://yabu.me/npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3l","provider_name":"njump","provider_url":"https://yabu.me","html":"📅 Original date posted:2019-09-25\n📝 Original message:\nGood morning aj, and list,\n\n\u003e \u003e Solution: buy a place in a merkle tree \"risk-free\"\n\u003e \u003e\n\u003e \u003e 1.  send hash x of my message (or the merkle root of another tree) to the\n\u003e \u003e     timstamping server\n\u003e \u003e\n\u003e \u003e 2.  server calculates Pedersen commit: C = xH + rG, hashes it, builds merkle\n\u003e \u003e     tree with other commits in it and publishes a valid transaction containing the\n\u003e \u003e     merkle root to the Bitcoin blockchain\n\u003e \u003e\n\u003e \u003e 3.  after a certain number of block confirmations and with the given proof I can\n\u003e \u003e     confirm that the commitment C is indeed part of the Bitcoin blockchain\n\u003e \u003e\n\u003e \u003e 4.  I now have to send a lightning payment with C - xH = rG as the payment\n\u003e \u003e     point\u0026nbsp; to the timestamping server and as a proof of payment the server must\n\u003e \u003e     reveal r to receive the money.\n\u003e \u003e\n\u003e\n\u003e Nice.\n\nI agree.\nThis is quite correct for its needs, and kudos to Konstantin for deriving this.\nDo note that Lightning today does not yet support payment points / scalars, only payment hashes / preimages.\n\nIn particular the client might induce the server to \"waste\" a slot on committing some information onchain, but the client will still not be able to get a commitment \"for free\" as it cannot know the blinding key for the commitment.\nThat is, the client can DoS the server and have it make commitments without getting paid, wasting the server capacity, but the client would not be able to prove the commitment does commit to its message without paying.\nThis can be avoided with aj suggestion of \"floating\" and \"subscriber\" clients.\n\nI would have personally used sign-to-contract onchain directly myself for such \"rare\" operations, but aggregation certainly has its efficiency benefits and this is still useful.\n\nSo far it seems, we can use EC magic (payment point / scalar) to:\n\n* Prevent route correlation especially for multipath payments.\n* Allow pay-for-signature.\n* Allow pay-for-pedersen-commitment (this thread).\n* Support multiple parallel payments (\"stuckless\").\n* Support noncustodial Lightning escrow.\n* Probably some other things I have forgotten.\n\n\u003e\n\u003e Since it's off chain, you could also provide R and C and a zero knowledge\n\u003e proof that you know an r such that:\n\u003e\n\u003e R = SHA256( r )\n\u003e C = SHA256( x || r )\n\u003e\n\u003e in which case you could do it with lightning as it exists today.\n\nI can insist on paying only if the server reveals an `r` that matches some known `R` such that `R = SHA256(r)`, as currently in Lightning network.\n\nHowever, how would I prove, knowing only `R` and `x`, and that there exists some `r` such that `R = SHA256(r)`, that `C = SHA256(x || r)`?\nI am curious about this operation, as this is beyond what little I know of cryptography.\n\n\nRegards,\nZmnSCPxj"}