Alexander Leishman [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-10-25 to 2019-08-21
💬 Posted a total of 8 messages
📚 Participated in the following categories: bitcoin-dev, Lightning-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:55:24

- reply

📅 Original date posted:2019-07-05
📝 Original message:
Chris,
Thanks for that explanation. I could see how this makes sense for
lightweight data payloads because it reduces the round trip count, but I
agree with ZmnSCPxj that this could pose a DoS risk for larger data
payloads. This DoS risk is even more magnified for ZKCPs.
I would guess that APIs selling data for lightning payments might take
different approaches:
1. You could purchase an auth token upfront that allows you access for some
amount of time of some number of requests (seems to be the most efficient
for APIs that would be called more than once)
2. You could pay per request (good for when you would want 1 big blob of
data)
So for the case where a customer is calling the API multiple times per day,
wouldn't it make more sense to pay upfront for future requests?
Best,
Alex
Best,
Alex
On Thu, Jul 4, 2019 at 8:36 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
> Good morning Alexander,
>
> > > > 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?
>
> It is possible I simply misunderstand the proper use of MAC, so I shall
> research it in more depth.
>
>
> > I think the benefit here is in reducing the client-server interaction
> for REST apis while still ensuring payment to the merchant.
> >
> > Let's assume that we don't have this scheme, and want to provide a
> monetized REST API. The workflow looks like this, which is similar to what
> our behavior is now at Suredbits with websockets.
> >
> > 1. Client sends request to server for invoice
> > 2. Server returns invoice
> > 3. Client pays invoice
> > 4. Server sends data back, or client makes request _again_ to a server
> and then server returns data
> >
> > With Nadav's scheme this is simplified to
> >
> > 1. Client sends request to server
> > 2. Serves returns invoice, and encrypted payload
> > 3. Client pays invoice
> > 4. Client decrypts data according to Nadav's scheme
> >
> > This saves a round trip between the server and client. It also gives
> atomicity to the transaction, although as you stated before there is no
> guarantees about integrity of the encrypted data. This is generally a hard
> problem to solve in the technical sense, but I think the reputational harm
> of the server sending bad data will be enough to prevent this, who wants to
> do business with some one that isn't providing the advertised service? This
> is a interaction that is could be repeated thousands of times on a daily
> basis.
>
> A client can easily DoS the server by requesting and requesting (thus
> convincing the server to encrypt and send data immediately) and never
> paying.
> Whereas the first would require more resources on the client side, as the
> server does not encrypt (or never encrypts at all) until the client has
> shown proof-of-payment.
>
> Regards,
> ZmnSCPxj
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190705/0b609eb3/attachment.html>

2023-06-09 12:55:23

- 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

- 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

- 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 18:20:04

- reply

📅 Original date posted:2019-08-21
📝 Original message:Hey Niels,
I'm no expert on bitcoind tests, but maybe these bits of information can
help you get started:
The steps to build bitcoind typically involve running:
./autogen.sh
./configure
make
make install
When you run autogen, the autoreconf
<https://www.gnu.org/software/autoconf/manual/autoconf-2.68/html_node/autoreconf-Invocation.html>
tool
is invoked which creates the configure script that gets run next. The
configure script is generated based on the configure.ac
<https://github.com/bitcoin/bitcoin/blob/master/configure.ac> file, which
performs a number of compatibility checks for the compiler and other
tooling. You can see these checks being performed with
the AX_CHECK_COMPILE_FLAG calls.
My understanding is that running configure does a lot of system
compatibility checks. When you run "make", I do not think any tests get run
by default, but I could be wrong about this. If you want to run unit tests
you need to run "make check". You can read more about this here
<https://github.com/bitcoin/bitcoin/blob/master/src/test/README.md>
There are unit tests for bitcoind written in C++ and a lot of integration
and higher level tests written in python.
Hopefully this information was useful and accurate. Again, I could be wrong
about exactly how the build process works as it's not super obvious.
Hopefully someone else more knowledgeable than me can chime in here if I
got anything wrong.
Best,
Alex
On Wed, Aug 21, 2019 at 10:06 AM Niels Thijssen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> As no one was able to respond, a gentle reminder : 😊
>
> Hi,
>
> I'm working as (software) test specialist and run private a full bitcoin
> node (based upon Raspberry Pi 4).
> I've been trying to figure out the tests performed during
> installation/upgrade/compilation of the software for the node.
> Is there any overview on what's the (common) test approach, or other
> stuff. Because the tests on GitHub don't help me that much.
> I'd like to figure out what/how is tested, maybe refine test cases, and
> try some manual test also, as part of learning.
>
> Who would be able to join me or share information that guides me.
> Thanks in advance,
>
> Niels.
>
>
>
> -------- Disclaimer --------
> This email and any files transmitted may contain proprietary and
> confidential information of Improve Quality Services B.V. (‘Improve QS’)
> and is intended only for the (use of the) named recipient(s) above. If you
> have received this message in error or are not the intended or named
> recipient(s) of this message, please immediately notify the sender by
> return and delete this email message from your computer. Any views or
> opinions presented are solely those of its author and do not necessarily
> represent those of Improve QS. You are hereby notified that unauthorized
> disclosure, use, dissemination, forwarding, printing or copying of this
> e-mail and its attachments either whole or partial of its contents is
> strictly prohibited. Improve QS cannot guarantee that email communications
> are secured and error-free and does not accept any liability for damages
> resulting from the use of email. The general terms and conditions of
> purchase respectively sale and delivery of Improve QS are applicable to all
> transactions and undertakings resulting therefrom.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190821/2d435f7f/attachment-0001.html>

2023-06-07 18:13:55

- reply

📅 Original date posted:2018-08-03
📝 Original message:Awesome! Haven’t had the chance to run it myself yet, so curious what benchmarks you are getting?
Best,
Alex
> On Aug 3, 2018, at 14:22, Bram Cohen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> BLS signatures have the same aggregation feature as Schnorr signatures but even better because the aggregation can be done non-interactively, at the expense of being a bit slower. We just released a first draft (but fully functional) library for doing BLS signatures based on a construction based on musig. Feedback, discussion, and usage is very welcome.
>
> https://github.com/Chia-Network/bls-signatures
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180803/4f4dc17d/attachment-0001.html>

2023-06-07 18:13:20

- reply

📅 Original date posted:2018-06-18
📝 Original message:Well miners already regularly mine empty blocks. However, it is usually in
the economic interest of the miners to collect transaction fees. This
incentive should hopefully be enough to prevent miners from choosing to
produce many empty blocks.
If a nation state attacker decides to allocate billions in resources to
attack Bitcoin, then that is a bigger discussion. The risk there is
double-spends, not empty blocks.
-Alex
On Mon, Jun 18, 2018 at 11:39 AM Артём Литвинович via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Dilution is a potential attack i randomly came up with in a Twitter
> arguement and couldn't find any references to or convincing arguments of it
> being implausible.
>
> Suppose a malicious actor were to acquire a majority of hash power, and
> proceed to use that hash power to produce valid, but empty blocks.
>
> As far as i understand it, this would effectively reduce the block rate by
> half or more and since nodes can't differentiate block relay and block
> production there would be nothing they can do to adjust difficulty or black
> list the attacker.
>
> At a rough estimate of $52 per TH equipment cost (Antminer pricing) and
> 12.5 BTC per 10 minutes power cost we are looking at an order of $2 billion
> of equipment and $0.4 billion a month of power costs (ignoring block
> reward) to maintain an attack - easily within means of even a minor
> government-scale actor.
>
> Is that a plausible scenario, or am i chasing a mirage? If it is
> plausible, what could be done to mitigate it?
>
>
> -Artem
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180618/35c7a580/attachment.html>

2023-06-07 15:26:49

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