<unnamed>

Public Key

npub1rtekrjhlvzkn8yq6leancxprgjd0jgumuqpd2n3y94rr9w4wdqfsdmae8s

Profile Code

nprofile1qqsp4umpetlkptfnjqd0u7eurq35fxheywd7qqk4fcjz633jh2hxsycpzpmhxue69uhkummnw3ezuamfdejsqdceqx

Publishing to

nostr.wine

Last Notes

2023-06-09 12:55:23 UTC

- reply

📅 Original date posted:2019-07-04
📝 Original message:
Nadav,
This is an interesting proposal, but because this still requires the
customer to trust the merchant, I am concerned that it adds complexity
without any meaningful guarantee to the customer. Perhaps it makes sense to
at least include some extension field here that allows the merchant to
include a ZKP for ZKCP-compatible data transfers? However, there are a number
of limitations <http://stevengoldfeder.com/papers/ZKCSP.pdf> to consider
with those.
My two cents, is that the proposed standard would only be useful for the
edge case where a customer wants to pre-download the data before paying,
but still trusts the merchant. What's the main use you see for that? My gut
tells me there's a higher-level abstraction here to be standardized that
would handle more mainstream use-cases.
ZmnSCPxj,
> Putting MAC inside the encryption would help ensure that we can detect
data replacement over insecure channel, and use of shared secret ensures
only intended recipient can decrypt.
Generally you want to MAC the ciphertext + IV, otherwise you lose
ciphertext integrity guarantees. Why do you want to MAC, then encrypt?
-Alex
On Wed, Jun 26, 2019 at 4:55 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good morning Nadav et al.,
>
> > > Any node on the route of the payment knows the preimage and can
> decrypt the data. It would be nice to tune the protocol in a way that only
> the buyer can decrypt the data. For example we could use something like
> this:
> >
> > Is this not covered by sending over the pre-image encrypted data over a
> secure channel such as HTTPS? If anyone along the route who learns the
> pre-image does intercept the message with the encrypted data, that data
> will already be encrypted for the intended recipient right?
>
> True, but the added protection allows sending the option of sending data
> over a non-secure channel.
> In particular, a secure channel like HTTPS would impose an
> encryption/decryption overhead, and then you will *also* encrypt/decrypt at
> the application layer i.e. you are encrypting twice.
> If you have the choice of using an insecure channel, you could take that
> and only have the encrypt/decrypt overhead only for the preimage-encrypted
> data.
>
> i.e. with this, you have the option of sending over both secure and
> insecure channels.
> It does not hinder use of secure channel, but enables use of insecure
> channel.
> Putting MAC inside the encryption would help ensure that we can detect
> data replacement over insecure channel, and use of shared secret ensures
> only intended recipient can decrypt.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> 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/20190704/1713b5d3/attachment.html>

2023-06-09 12:53:36 UTC

- reply

📅 Original date posted:2018-12-27
📝 Original message:
Hello ZmnSCPxj,
> Do you mean, that if you make a swap on Lightning, which *might* be a
Bitcoin-to-WJT American Call Option, I will refuse to forward until I also
get something that is a WJT-to-Bitcoin call option, similar to a butterfly
spread?
> That implies that in the "normal", non-American-call-option case, the
payer has the target asset, which brings up the question: why would the
payer even go through the cross-asset broker in a Lightning route if the
payer already has the target asset?
No this isn't what I'm suggesting. Let me try to explain again. Apologies
if this isn't clear:
Let's assume only two parties are engaging in this interaction, you and me.
You offer me the WJT/BTC exchange rate from your mult-chain node and I
route an LN payment from my BTC node to my WJT node through your
multi-chain node. My understanding is that the main problem with this is
the free optionality I get when my WJT node does not return the hash
preimage immediately to you and instead waits to see if the market price
fluctuates out of my favor until option/HTLC expiry. But what if we could
atomically swap this preimage for the final HTLC you sent me? If this
magical atomic information swap could happen (I don't get the final HTLC
unless I reveal the preimage) the payment would settle immediately (in the
two party case, let's assume no other intermediary nodes). A timed
commitment approach could potentially be feasible if the time required to
brute force the commitment is longer than the life of the "option"/HTLC.
I'm not necessarily suggesting this the optimal solution, but I haven't
seen the idea mentioned before.
-Alex
On Thu, Dec 27, 2018 at 2:01 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Alex and Will,
>
> > 1. Cross-asset brokers charge a standard option premium to perform the
> brokerage. I can't tell if you think this is totally broken or if it's just
> sad. I don't understand lightning well enough to figure that out on my own
> - could you expand more on what effects this would have?
>
> It is quite broken.
> We assume generally that if a payment route fails, that the payer making
> the payment route loses nothing.
>
> Unfortunately, once there is a premium involved for cross-asset swaps, it
> implies that any failures *after* the swap will now have a cost,
> specifically, the premium paid.
> Perhaps you could inform the cross-asset broker who the ultimate payee is
> so it can retry failures after it on your behalf, but now the broker has
> the ability to censor payments to payees it does not like.
>
> > 2. Cross-asset brokers require counterparties to issue them a symmetric
> but slightly more out-of-the-money call, which they can redeem in the event
> of a large FX swing. This bounds their FX losses.
>
> I am uncertain what you mean exactly.
>
> Do you mean, that if you make a swap on Lightning, which *might* be a
> Bitcoin-to-WJT American Call Option, I will refuse to forward until I also
> get something that is a WJT-to-Bitcoin call option, similar to a butterfly
> spread?
> That implies that in the "normal", non-American-call-option case, the
> payer has the target asset, which brings up the question: why would the
> payer even go through the cross-asset broker in a Lightning route if the
> payer already has the target asset?
>
>
> > There’s another potential partial solution here if we can create some
> cryptographic protocol for atomically swapping information. This would be
> used to swap the final HTLC sig for the hash preimage, preventing the
> optionality issue. This idea was inspired by a paper called “Timed
> Commitments” by Dan Boneh
> > (https://www.iacr.org/archive/crypto2000/18800237/18800237.pdf).
> >
> > The high level idea is that each party swaps a commitment to the
> information they want to atomically swap and then slowly reveal verifiable
> “hints” that make it easier and easier to brute force the commitment. Each
> party takes turns revealing a hint.
> >
> > The protocol to do something like this in lightning doesn’t exist afaik
> but it seems feasible. This also may fail to work when there are
> intermediary nodes not controlled by the two trading parties.
>
> The entire point of using HTLCs in Lightning routing is to enforce that
> the final payee actually gets paid, or nobody along the route gets paid.
> From my understanding of this, if this is used, then an intermediate node
> can try to brute force the preimage instead of actually bothering to
> forward payments or hints.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181227/ea806ad1/attachment.html>

2023-06-09 12:53:36 UTC

- reply

📅 Original date posted:2018-12-27
📝 Original message:
There’s another potential partial solution here if we can create some cryptographic protocol for atomically swapping information. This would be used to swap the final HTLC sig for the hash preimage, preventing the optionality issue. This idea was inspired by a paper called “Timed Commitments” by Dan Boneh
(https://www.iacr.org/archive/crypto2000/18800237/18800237.pdf).
The high level idea is that each party swaps a commitment to the information they want to atomically swap and then slowly reveal verifiable “hints” that make it easier and easier to brute force the commitment. Each party takes turns revealing a hint.
The protocol to do something like this in lightning doesn’t exist afaik but it seems feasible. This also may fail to work when there are intermediary nodes not controlled by the two trading parties.
I also could be completely off here but I thought the idea was worth sharing.
Best
Alex
> On Dec 27, 2018, at 10:47, Will Yager <lists at yager.io> wrote:
>
> Very good point.
>
> Two possible responses come to mind.
>
> 1. Cross-asset brokers charge a standard option premium to perform the brokerage. I can't tell if you think this is totally broken or if it's just sad. I don't understand lightning well enough to figure that out on my own - could you expand more on what effects this would have?
>
> 2. Cross-asset brokers require counterparties to issue them a symmetric but slightly more out-of-the-money call, which they can redeem in the event of a large FX swing. This bounds their FX losses.
>
>
> Will
>
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Thursday, December 27, 2018 1:43 PM, ZmnSCPxj via Lightning-dev <lightning-dev at lists.linuxfoundation.org> wrote:
>
>
>> HTLCs allow creation of American Call Options.
>
> _______________________________________________
> 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/20181227/191b02f9/attachment.html>

2023-06-07 15:26:49 UTC

- reply

📅 Original date posted:2014-10-25
📝 Original message:Interesting analysis! I think there are a few important effects that aren't
being considered.
1. When the block reward is halved, inflation is halved as well. Is this
halving already priced in by the market or will it result in an upward
pressure on the price?
2. It was acknowledged that the referenced analysis did not take into
account the result of a double-spend attack on the bitcoin price. However,
the effect of a detectable double-spend attack on the Bitcoin network is
not isolated to Bitcoin markets. The price of altcoins often trend with the
price of Bitcoin, so attacking Bitcoin may reduce the profitability of
'multipool' mining. Any alt-coin market vulnerable to the malicious
hash-power would probably go into panic mode.
-Alex Leishman
On Sat Oct 25 2014 at 1:51:10 PM Alex Mizrahi <alex.mizrahi at gmail.com>
wrote:
>
>
>> For the sake of argument, lets assume that somehow (quite unlikely)
>
>
> Why is it unlikely? Do you believe that the cost of electricity cannot be
> higher than expected mining revenue?
> Or do you expect miners to keep mining when it costs them money?
>
>
>> half the mining equipment gets shut off.
>> The amount of hashes/second is such that it is currently, lets just say,
>> quite
>> secure against any takeover.
>>
>
> The equipment won't be simply turned off, it will be up for grabs.
>
> Please check this web sites:
>
> https://nicehash.com/
> https://www.multipool.us/
>
> One can use them in the same way he uses normal mining pools, and they
> switch between different chains.
> Say, multipool.us can switch between BTC and PPC (Peercoin).
> Mining BTC will be less profitable after a halving, so a miner who is
> willing to maximize his profits might use multipool to auto-switch to
> something more profitable.
> Which might be attack-on-Bitcoin.
> E.g. if 60% of bitcoin's total hashrate is available via "multipools", one
> can try to pull of a double-spending attack.
>
>
>> Your document makes a long series of assumptions about how this can turn
>> out
>> bad with each individually is implausible, together are just fiction.
>>
>
> It sounds like you failed to grasp even basics.
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141025/588c86c6/attachment.html>