<unnamed>

Public Key

npub1snw7t4auupm70ntyeywuzqn80cf6es53ym8rlzymh8ft97qmyq9qrg9vl0

Profile Code

nprofile1qqsgfh09677wqal8e4jvj8wpqfnhuyavc2gjdn3l3zdmn54jlqdjqzspzpmhxue69uhkummnw3ezuamfdejs3j8ejk

Publishing to

nostr.wine

Last Notes

2023-06-09 15:00:17 CEST

- reply

📅 Original date posted:2020-05-20
📝 Original message:
Hi,
We went through the discussion of Griefing Attack
<https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002608.html>
and after a thorough analysis, we realized that the attack cannot be
prevented as the adversary doesn’t suffer any loss of funds.
We propose an efficient countermeasure for the attack, known as
Griefing-Penalty. Our proposed strategy works for any timelock based
payment protocol. The penalty compensates for the loss incurred by the
intermediaries, affected by griefing attack. You will find the paper
Griefing-Penalty:
Countermeasure for Griefing Attack in Bitcoin-compatible PCNs
<https://arxiv.org/abs/2005.09327> on arXiv. We look forward to hearing
from the community on the feasibility of the approach and whether it can be
implemented or not.
Our Contribution to the paper:
• We propose a countermeasure for mitigating griefing attack in
Bitcoin-compatible PCNs, known as Griefing-Penalty. It punishes the griefer
by forcing it to pay compensation to all the parties whose funds got locked
for a certain time period as a result of the attack.
• The loss of funds incurred upon mounting griefing-attack is proportional
to the collateral cost of each channel involved in routing the payment.
• To illustrate the benefit of the proposed countermeasure, we propose a
new payment protocol, called as HTLC-GP or Hashed Timelock Contract with
Griefing-Penalty.
• We provide a security analysis which proves that our protocol is
privacy-preserving as well as mitigates loss due to griefing attack by
compensating the honest nodes
We will briefly summarize the problem and our contribution through an
example.
The problem of Griefing Attack explained briefly
Consider the situation where A wants to transfer 1 msat to C. It figures
out a path connecting it to C, in the form A->B->C. A establishes an HTLC
with B, locking 1 msat in the contract having expiration time of say 2
days. B after receiving the incoming contract, forms a contract with C,
locking 1 msat in the contract with locktime of 1 day.
A------------------------->B---------------------->C
HTLC(1msat, 2 day) HTLC(1msat, 1 day)
Now if C griefs, funds of A and B remain locked as they cannot resolve
HTLC. After an elapsed time of 1 day, the fund gets unlocked and B gets
back 1 msat. Similarly, B cancels contract with A after 1 day, A unlocks 1
msat. The problem with this construction is that C doesn’t lose anything.
Griefing-Penalty: a strategy to penalize the adversary
Hence we have come up with the following idea:
1) An off-chain contract established between 2 parties requires both the
parties to lock funds – one party locking the amount that is to be
forwarded and the other party locking the fund which can be claimed as a
penalty, if this party griefs.
2) The penalty locked is proportional to the product of the amount being
forwarded and the expiration time of the contract. All the parties affected
by griefing must get compensation since their liquidity is tied up for a
certain period of time.
Considering the example used for demonstrating griefing attack. We modify
the contract and term it as HTLC-GP (Hashed Timelock Contract with Griefing
Penalty). We assume a rate of penalty, say 0.01 per hour, for calculating
the penalty the party has to lock in order to accept an off-chain contract
request.
A forwards the term of the contract to B, requesting B to lock
0.01*1*48=0.48 msat as a penalty. A locks 1 msat in the contract, so the
total amount locked in the contract is 1.48 msat. In the same way, B
forwards the term of the contract to C, requesting C to lock 0.01*1*24=0.24
msat as a penalty. B locks 1 msat in the contract, so the total amount
locked in the contract is 1.24 msat. If the payment is not resolved within
1 day, all the parties who have forwarded the contract will claim the
penalty locked in the contract.
A-------------------------------------->B-------------------------------->C
HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.24 msat,1 day)
If C releases the preimage before the expiration of locktime, it will claim
the full amount locked in the contract, i.e. 1.24 msat. Similarly, B claims
1.48 msat from the contract established with A.
Suppose C griefs. After an elapse of 1 day, B claims 1.24 msat from the
contract. C loses 0.24 msat. When B cancels contract with A, it will settle
by paying 1.48 msat to A. But then B loses an additional 0.24 msat. This is
not desired as B was not involved in mounting the attack. As per the
objective, even B should earn a remuneration as it got affected by griefing.
Hence, B should have asked C to lock funds in the contract which can be
used for compensating both B and A. So C must lock 0.48 msat + 0.24 msat =
0.72 msat. So if C griefs, now it loses 0.72 msat (proportional to the
collateral cost of the path). B pays 0.48 msat to A, keeping 0.24 msat with
itself as compensation.
A-------------------------------------->B-------------------------------->C
HTLC-GP(1.48 msat, 2 days) HTLC-GP(1.72 msat,1 day)
A------------------------------------->B-------------------------------->C
(griefs)
(A gain 0.48 msat) (B gain 0.24 msat) (C loses 0.72 msat)
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200520/c67d82af/attachment-0001.html>

2023-06-09 14:59:32 CEST

- reply

📅 Original date posted:2020-04-01
📝 Original message:
Commenting on it : "As for ZmnSCPxj's suggestion, I think there is the same
kind of issue.
The secrets we establish with anonymous multi-hops locks are between the
*sender*
and each of the hops. In the route blinding case, what we're adding are
secrets
between the *recipient* and the hops, and we don't want the sender to be
able to
influence those."
Is it a good idea to rely entirely on the sender for sampling the secrets
as well as generating the PTLC? As happens in anonymous multi-hops locks,
for example. Or as it has been discussed later in the thread, both receiver
and sender must be involved in creation of PTLC? What happens if
sender/receiver is/(or both are) corrupted? Can it leak secrets to other
parties?
On Wed, Mar 11, 2020 at 9:57 PM Bastien TEINTURIER via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning list,
>
> Thanks Rusty for following up on this, I'm glad it may be useful for
> offers!
> I certainly want this as well for wallet users' privacy.
>
> I have gathered my proposal in a better format than my previous gist here:
>
> https://github.com/lightningnetwork/lightning-rfc/blob/route-blinding/proposals/route-blinding.md
>
> You will note that I've been able to simplify the scheme a bit compared to
> my
> gist. It's now very clear that this is exactly the same kind of secrets
> derivation than what Sphinx does. I still have things I want to add to the
> proposal, but at least the crypto part should be ready to review (and I
> think
> it does need more eyes on it).
>
> Feel free to add comments directly on the branch commits, it may be easier
> to
> review that way. Let me know if you think I should turn it into a draft PR
> to
> facilitate discussions. It kept it vague on some specific parts on purpose
> (such as invoice fields, encrypted blob format); we will learn from early
> prototype implementations and enrich the proposal as we go.
>
> A few comments on your previous mails. I have removed the (ab)use of
> `payment_secret`, but I think your comment on using the `blinding` to
> replace
> it would not work because that blinding is known by the next-to-last node
> (which computes it and forwards it to the final node).
> The goal of `payment_secret` is explicitly to avoid having the
> next-to-last node
> discover it to prevent him from probing. But I think that you didn't plan
> on
> doing the blinding the same way I'm doing it, which may explain the
> difference.
>
> As for ZmnSCPxj's suggestion, I think there is the same kind of issue.
> The secrets we establish with anonymous multi-hops locks are between the
> *sender*
> and each of the hops. In the route blinding case, what we're adding are
> secrets
> between the *recipient* and the hops, and we don't want the sender to be
> able to
> influence those. It's a kind of reverse Sphinx. So I'm not sure yet the
> recipient
> could safely contribute to those secrets, but maybe we'll find a nice
> trick in
> the future!
>
> Cheers,
> Bastien
>
> Le mer. 11 mars 2020 à 00:22, Rusty Russell <rusty at rustcorp.com.au> a
> écrit :
>
>> ZmnSCPxj <ZmnSCPxj at protonmail.com> writes:
>> > Good morning Rusty, et al.,
>> >
>> >
>> >> Note that this means no payment secret is necessary, since the incoming
>> >> `blinding` serves the same purpose. If we wanted to, we could (ab)use
>> >> payment_secret as the first 32-bytes to put in Carol's enc1 (i.e. it's
>> >> the ECDH for Carol to decrypt enc1).
>> >
>> > I confess to not reading everything in detail, but it seems to me that,
>> with payment point + scalar and path decorrelation, we need to establish a
>> secret with each hop anyway (the blinding scalar for path decorrelation),
>> so if you need a secret per hop, possibly this could be reused as well?
>>
>> Indeed, this could be used the same way, though for that secret it can
>> simply be placed inside the onion rather than passed alongside.
>>
>> Cheers,
>> Rusty.
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200401/1e7b9725/attachment.html>

2023-06-09 14:59:11 CEST

- reply

📅 Original date posted:2020-03-06
📝 Original message:
Hi,
I was reading the paper by Poon and Dryja on Bitcoin Lightning
Network and was going through the construction of HTLC. Suppose 2 parties A
and B have a channel with each party locking 0.5 BTC. Suppose A wants to
transfer 0.1 BTC to B contingent to the knowledge of R : H=h(R) produced
within a locktime of say t days. So the script output for A is -
1. 0.4 BTC to A
2. 0.5 BTC to B
3. 0.1 BTC locked in HTLC between A & B.
Why we cannot set the terms as say 0.4 BTC to A, 0.2 BTC to B and 0.4 BTC
to HTLC, where HTLC output can follow either of the paths - If B produces R
within t days then it gets back 0.4 BTC else after t days A can broadcast
with 0.4 BTC going to the A? This prevents B from not responding (and
induce possibly griefing attack across a longer path by withholding the
solution) since it will lose out 0.3 BTC. What can be the problem if the
terms of HTLC itself tries to enforce a penalty on the counterparty?
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200306/6350cd37/attachment.html>

2023-06-09 14:58:12 CEST

- reply

📅 Original date posted:2020-01-27
📝 Original message:
Hi ZmnSCPxj,
It is stated in the paper "Atomic multi-channel updates with constant
collateral in bitcoin-compatible payment-channel networks" and I am quoting
verbatim (page 11) (last email still waiting moderator approval) "Phase I:
Setup. The first phase requires to freeze the coins available at each
channel involved in the protocol. Doing this naively (i.e., locking the
complete balance in the channel at once) would lock more coins than
required, unnecessarily increasing the collateral in the protocol. Instead,
during the setup phase, the balance at each payment channel is split in
two, effectively creating thereby two sub-channels: one sub-channel is set
with the coins required for the present protocol session, while the other
one is set with the
remaining coins, which can then be freely spent. In the illustrative
example shown in Figure 4.2, the setup phase starts with the user A
collaborating with user B to create the transaction Tx A
setup , where they split the 10 coins they have in the channel in two
sub-channels: one sub-channel with 8 coins to be used in the rest of the
protocol session and one sub-channel with the rest (i.e., 2 coins). This
transaction is signed by both users so that it can be eventually enforced
on-chain if required. The rest of the users behave analogously. Note that
operations at each channel in this phase of the protocol can be carried out
in parallel." Does this sound good ?
On Mon, Jan 27, 2020 at 9:41 AM Subhra Mazumdar <
subhra.mazumdar1993 at gmail.com> wrote:
> Hi ZmnSCPxj,
> It is stated in the paper "Atomic multi-channel updates with
> constant collateral in bitcoin-compatible payment-channel networks". I am
> attaching the screenshot of the paragraph which mentions about locking the
> amount which is required for payment transfer and not the entire channel
> fund.
>
> On Mon, Jan 27, 2020 at 6:15 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning Subhra,
>>
>> This does not seem to make sense?
>> For a payment that is less than the channel funds on your side, only that
>> amount is locked behind an HTLC, and the rest remains useable for other
>> HTLCs.
>>
>> What exactly are you referring to?
>>
>> Regards,
>> ZmnSCPxj
>>
>> > Hi,
>> > I was wondering when parties apply condition on fraction of
>> channel fund for ensuring successful payment, entire channel fund is held.
>> Is it possible to lock just partial amount of fund of a payment channel and
>> leave the rest to be used by some another payment request ? Concept of
>> subchannels of a single channel has been suggested in "Atomic multi-channel
>> updates with constant collateral in bitcoin-compatible payment-channel
>> networks"
>> https://scholar.google.com/scholar?cluster=40566801298747858&hl=en&as_sdt=2005&sciodt=0,5
>> but I am still in doubt what happens during closing of subchannel ?
>> > --
>> > Yours sincerely,
>> > Subhra Mazumdar.
>>
>>
>>
>
> --
> Yours sincerely,
> Subhra Mazumdar.
>
>
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200127/b8248846/attachment.html>

2023-06-09 14:58:12 CEST

- reply

📅 Original date posted:2020-01-25
📝 Original message:
Hi,
I was wondering when parties apply condition on fraction of channel
fund for ensuring successful payment, entire channel fund is held. Is it
possible to lock just partial amount of fund of a payment channel and leave
the rest to be used by some another payment request ? Concept of
subchannels of a single channel has been suggested in "Atomic multi-channel
updates with constant collateral in bitcoin-compatible payment-channel
networks"
https://scholar.google.com/scholar?cluster=40566801298747858&hl=en&as_sdt=2005&sciodt=0,5
but I am still in doubt what happens during closing of subchannel ?
--
Yours sincerely,
Subhra Mazumdar.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200125/7db6f203/attachment.html>

2023-06-09 14:58:06 CEST

- reply

📅 Original date posted:2020-01-20
📝 Original message:
Are you referring to the paper Zero knowledge contingent payment revisited
? I will look into the construction. Thanks for the information! :)
On Mon, Jan 20, 2020, 23:31 Matt Corallo <lf-lists at mattcorallo.com> wrote:
> On 11/9/19 4:31 AM, Takaya Imai wrote:
> > [What I do not describe]
> > * A way to detect that data is correct or not, namely zero knowledge
> > proof process.
>
> Have you come across Zero Knowledge Contingent Payments? Originally it
> was designed for on-chain applications but it slots neatly into
> lightning as it only requires a method to lock funds to a hash preimage.
>
> Matt
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200120/3823fa3d/attachment.html>

2023-06-09 14:58:05 CEST

- reply

📅 Original date posted:2020-01-20
📝 Original message:
Thanks Takaya for clearing my doubts. Regarding the answer to the question
"What happens if it fails in an iteration ? So the recipient of the file
remains happy with the partial content ? Or will the payment be revoked
(not sure how) if recipient doesn't get the full content ?
This is about the DLAS-up protocol.
The protocol uses OG AMP so the payments and data transfers are revoked in
case that it fails"
I am talking about different iterations. If it's the case that you have a
5GB file then you are sending 256bit via each path. May be in one iteration
you are able to send some 200 byte (assuming we get 8 paths at a time). So
it's the case that you need 5GB/200B iterations. But og amp guarantees
atomic delivery for blocks per iteration right and not for all the
iterations taken together ? Also how do you ensure correctness of the file
shared (using Zk proof ?) ?
On Mon, Jan 20, 2020, 12:03 Takaya Imai <takaya.imai at frontier-ptnrs.com>
wrote:
> Hi Subhra,
>
> thanks for your question.
>
> > So as of now if we consider transfer of a file (may of few KB) then you
> split it into several blocks and use atomic multi path payment whole using
> the blocks for embedding with the preimage inorder to obtain payment.
> > But it might be the case you may not have sufficient number of path to
> transfer all the blocks at one go because of preimage size limitation of
> 256 bit (I didn't get the point that there is no limitation on data size,
> can anyone explain that ?).
>
> Yes. It needs many blocks and paths if large file.
> But it has no problem because it can use the same path several times.
>
> Of course it needs much money to transfer large file. But this is good
> point in order to retain lightning network stable.
>
> For DOS attack, OG AMP has the same problem. It might that recipient needs
> a limit how many split blocks the recipient accept
>
> > So may be you need several iteration and I presume thats what lightning
> network will pitch in where we have several such microtransactions going on.
> >.
>
> Thanks,
> Takaya Imai
>
> 2020年1月16日(木) 16:14 Subhra Mazumdar <subhra.mazumdar1993 at gmail.com>:
>
>> Hello Takaya,
>> I really liked the idea of data atomic swap mentioned over here.
>> So as of now if we consider transfer of a file (may of few KB) then you
>> split it into several blocks and use atomic multi path payment whole using
>> the blocks for embedding with the preimage inorder to obtain payment. But
>> it might be the case you may not have sufficient number of path to transfer
>> all the blocks at one go because of preimage size limitation of 256 bit (I
>> didn't get the point that there is no limitation on data size, can anyone
>> explain that ?). So may be you need several iteration and I presume thats
>> what lightning network will pitch in where we have several such
>> microtransactions going on. What happens if it fails in an iteration ? So
>> the recipient of the file remains happy with the partial content ? Or will
>> the payment be revoked (not sure how) if recipient doesn't get the full
>> content ?
>>
>> On Mon, Nov 11, 2019 at 6:29 AM Takaya Imai <
>> takaya.imai at frontier-ptnrs.com> wrote:
>>
>>> Hi all,
>>>
>>> I propose Data Lightning Atomic Swap.
>>> Anyone already have the same idea?
>>>
>>>
>>> [Abstract]
>>> This proposal is a way to swap data and lightning payment atomically.
>>> It has two patterns, one is for a payer to swap data-download with
>>> lightning payment to a payee (DLAS-down), the other is for a payer to swap
>>> data-upload with lightning payment to a payee (DLAS-up).
>>>
>>> The data is embedded to preimage so sending and receiving the data need
>>> lightning payment at the same time.
>>>
>>> ---------
>>>
>>> [Motivation]
>>> Atomic Swaps among crypto currencies has various ways to implement
>>> (on-chain to on-chain[1], on-chain to of-chain(Submarine Swap[2])). And
>>> Atomic Swaps between data and crypto currencies are also proposed as a part
>>> of TumbleBit mechanism[3], Storm mechanism[4] and so on.
>>>
>>> Recently Joost Jager proposed Instant messages with lightning onion
>>> routing, whatsat[5], which use recent sphinx payload change[6]. This is
>>> very awesome but not atomic with lightning payment.
>>>
>>> Atomic lightning mechanism for data is useful in use cases below.
>>>
>>> ---------
>>>
>>> [Pros & Cons]
>>>
>>> * DLAS-down
>>> ** Pros
>>> *** Atomic data download exchange with lightning payment
>>> ** Cons
>>> *** It needs better mechanism to expand data size
>>>
>>> * DLAS-up
>>> ** Pros
>>> *** Atomic data upload exchange with lightning payment
>>> ** Cons
>>> *** OG AMP[7] is needed to implement
>>>
>>> ---------
>>>
>>> [What I describe]
>>> * A way to swap data with lightning payment atomically.
>>>
>>> ---------
>>>
>>> [What I do not describe]
>>> * A way to detect that data is correct or not, namely zero knowledge
>>> proof process.
>>>
>>> For example, probabilistic checkable proof like TumbleBit[3] proposed.
>>> Just message as data is no problem because no need to check the message
>>> is correct or not.
>>>
>>> * A way in case that different preimages are used in a payment route
>>> like Multi-hop locks.
>>>
>>> ---------
>>>
>>> [Specification]
>>>
>>> Lightning Network(LN) has a mechanism about preimage like a brief image
>>> below.
>>>
>>> Payer Mediators
>>> Payee
>>>
>>> =================================================================================
>>>
>>> Preimage
>>> Preimage Hash <--------------------- invoice ------------------------
>>> Preimage Hash
>>> Preimage Hash ----------------> Preimage Hash -------------------->
>>> Preimage Hash
>>> Preimage <—-------------—- Preimage <--------------------
>>> Preimage
>>>
>>> As you know, preimage Payer gets can be a proof of payment because Payer
>>> can not get it if the payment is executed correctly.
>>>
>>>
>>>
>>> 1, Data download <-> lightning (DLAS-down)
>>>
>>>
>>> Payer sends lightning payment and receives data from Payee atomically.
>>>
>>>
>>> Payer Mediators
>>> Payee
>>>
>>> =================================================================================
>>> Payer Channel Pubkey <----------------------------------------------->
>>> Payee Channel Pubkey
>>>
>>>
>>> data(256bit, padded)
>>>
>>> enc_key = (Payee Channel Secret Key * Payer Channel Pubkey).x (256bit)
>>> enc_key = (Payer Channel Secret Key * Payee Channel Pubkey).x (256bit)
>>>
>>> enc_data = data XOR enc_key
>>> sha256(enc_data) <--------------------- invoice ----------------------
>>> sha256(enc_data)
>>> sha256(enc_data) ----------------> sha256(enc_data) ----------------->
>>> sha256(enc_data)
>>> enc_data <---------------- enc_data <-------------------------
>>> enc_data
>>> data = enc_data XOR enc_key
>>>
>>>
>>> * The size of data is restricted to 256 bits. Identically, it should be
>>> extended to larger data and the data should be transferred in several
>>> payment paths like DLAS-up.
>>> * Channel Pubkey is only one for one channel and the data can be
>>> decrypted if enc_key is leaked. So enc_key should be generated newly every
>>> time by a way like hash chain but the protocol image above is just example
>>> for simplicity.
>>> * .x means X axis value of points on Elliptic Curve.
>>> * If data is less than 256 bits, then 0x00 is padded (I am not sure
>>> which of big endian and little endian is better).
>>>
>>>
>>>
>>> 2, Data upload <-> lightning (DLAS-down)
>>>
>>> Payer sends data and lightning payment from Payee atomically.
>>> This is like OG AMP(Atomic Multi-path Payment)[7] system.
>>>
>>> Payer Mediators
>>> Payee
>>>
>>> =================================================================================
>>> data(512bit, padded)
>>>
>>> share1(256bit)
>>> share2(256bit)
>>>
>>> base_s = share1 XOR share2
>>> data1(256bit) || data2(256bit) = data(512bit)
>>> XOR_d1 = data1 XOR base_s
>>> XOR_d2 = data2 XOR base_s
>>> PreImg1 = sha256(base_s || data || 1)
>>> PreImg2 = sha256(base_s || data || 2)
>>>
>>> sha256(PreImg1), XOR_d1, share1 -> sha256(PreImg1), XOR_d1, share1 ->
>>> sha256(PreImg1), XOR_d1, share1
>>> sha256(PreImg2), XOR_d2, share2 -> sha256(PreImg2), XOR_d2, share2 ->
>>> sha256(PreImg2), XOR_d2, share1
>>>
>>>
>>> base s = share1 XOR share2
>>>
>>> data = (XOR_d1 XOR base_s) || (XOR_d2 XOR base_s)
>>>
>>> PreImg1 = sha256(base_s || data || 1)
>>>
>>> PreImg2 = sha256(base_s || data || 2)
>>>
>>> PreImg1 <------------------- PreImg1 <---------------------
>>> PreImg1
>>> PreImg2 <------------------- PreImg2 <---------------------
>>> PreImg2
>>>
>>>
>>> * This protocol example has 512 bits data and they are transferred in
>>> two paths. However, it can transfer larger data in several payment paths
>>> like [5].
>>> * || means string concatenation.
>>> * If data is less than 512 bits, then 0x00 is padded(I am not sure which
>>> of big endian and little endian is better).
>>>
>>>
>>> ---------
>>>
>>>
>>> [Use Cases]
>>>
>>> 1, Lightning Network ecosystem
>>>
>>> * Hosting Incentives like Acai Protocol
>>> ** Watchtower Hosting incentive, Backup Hosting incentive
>>> *** Commitment tx data sending to Data Host(DLAS-up)
>>> **** Commitment tx data is embedded in preimage so that Payer can not
>>> send the data without remittance
>>> *** Channel backup data receiving from Data Host(DLAS-down)
>>> **** Channel backup data is embedded in preimage so that Payer can not
>>> receive the data without remittance
>>>
>>> 2, Crypto currency Problems
>>>
>>> * Distributed secret key sharing (just come up with an idea though)
>>> ** As a key backup, one of secret key shares is distributed with
>>> encryption(DLAS-up) to some nodes, which nodes receive lightning payment as
>>> key managing fee. And the nodes send a proof for managing the key as
>>> response of bloom filter periodically, and exchange encrypted secret key
>>> share with lightning payment to asset holder(DLAS-down).
>>> ** For example 2 out of 3 multi signature key sharing, asset holder puts
>>> the first key, the custodial has the second key, and the third key at the
>>> lightning distribution nodes. Asset holders usually spend assets using
>>> their key and the key on Distributed Nodes.
>>>
>>>
>>> 3, Problems so far
>>>
>>> * Prevention email spam and DDoS attack with large data
>>> ** Payer can not send email or data without remittance(DLAS-up)
>>> ** Payer can not receive reply-email without remittance(DLAS-down)
>>>
>>> * Incentive of receiving advertisements on browser or desktop/mobile app
>>> ** Payer can not send advertisements without remittance(DLAS-up)
>>>
>>> * Bounty for code bug fixes based on cryptographic proofs or secret
>>> computations
>>> ** (DLAS-down)
>>>
>>>
>>>
>>> [References]
>>>
>>> [1] https://bitcointalk.org/index.php?topic=321228
>>> [2] https://twitter.com/roasbeef/status/964608261830750208
>>> [3] https://eprint.iacr.org/2016/575
>>> [4] https://github.com/storm-org/storm-spec
>>> [5] https://twitter.com/joostjgr/status/1190714028626251779
>>> [6] https://github.com/lightningnetwork/lightning-rfc/pull/619
>>> [7]
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html
>>>
>>>
>>> document on github:
>>> https://github.com/takaya-imai/data_lightning_atomic_swap
>>>
>>> Best regards,
>>> Takaya Imai
>>> Email: takaya.imai at frontier-ptnrs.com, takaya.imai at unitedbitcoiners.com
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> Lightning-dev at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>>
>>
>>
>> --
>> Yours sincerely,
>> Subhra Mazumdar.
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200120/257e2885/attachment-0001.html>