Nostr notes by Martin Habovštiak [ARCHIVE]

📅 Original date posted:2023-07-15 🗒️ Summary of this ...

2023-07-17T13:04:44Z

In reply to nevent1q…y57w
_________________________

📅 Original date posted:2023-07-15
🗒️ Summary of this message: The author suggests that implementing self-payment of invoices in Lightning node implementations would be beneficial for testing and custodial service providers.
📝 Original message:
Hi folks,

I would also like to point out this can help testing a lot. I do
integration testing of payment flow by spawning a secondary node, setting
up a channel etc which takes considerable time even automated on regtest.
Also it sometimes fails for silly unrelated reasons.

Dňa so 15. 7. 2023, 20:22 fiatjaf <fiatjaf at gmail.com> napísal(a):

> On Thu, Jul 13, 2023 at 3:47 AM David A. Harding <dave at dtrt.org> wrote:
> > My question is whether you think it would be worthwhile to ask
> > developers of the underlying LN node implementations you use to support
> > self-payment of their own invoices (if they don't already).
>
> As far as I know no Lightning node has this ability, which is very
> unfortunate.
> If possible this should definitely be implemented. It would be the
> biggest feature for custodial Lightning service providers of all kinds
> since always.
> _______________________________________________
> 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/20230715/77032b7d/attachment.html>;

📅 Original date posted:2023-07-16 🗒️ Summary of this ...

2023-07-17T13:04:44Z

In reply to nevent1q…lhdr
_________________________

📅 Original date posted:2023-07-16
🗒️ Summary of this message: The user is testing LND <-> app integration and wants a flag to enable self-payment without going through the network.
📝 Original message:
Yeah, my point was to not have to setup any other instance of LND. I'm just
testing LND <-> app integration - whether the app receives payments from
LND. So another similar flag to do self-payment without going through
network would be ideal.

Dňa ne 16. 7. 2023, 19:32 Olaoluwa Osuntokun <laolu32 at gmail.com> napísal(a):

> lnd supports paying invoices it generates, you just need to set the
> `allow_self_payment` field using this
> API: https://lightning.engineering/api-docs/api/lnd/router/send-payment-v2
> .
>
> This _does_ end up actually finding a circular route through the network
> though, it's most commonly used to implement circular rebalancing.
>
> However if you set up another node, and then fund bi-lateral "trusted
> channels" (so zero conf channel that will never actually confirm as the
> funding point will never exist on chain), then you gain the ability to pay
> invoices without doing the actual network route. This doesn't need any
> other
> external software, and also gives you all the normal payment/invoice
> records
> you'd expect for normal payments.
>
> Another way to accomplish the same thing would be to use the
> `"allow-circular-route` flag, which'll let you double back on the same
> channel (incoming+outgoing channel is the same for the route).
>
> -- Laolu
>
> On Sat, Jul 15, 2023 at 8:22 PM fiatjaf <fiatjaf at gmail.com> wrote:
>
>> On Thu, Jul 13, 2023 at 3:47 AM David A. Harding <dave at dtrt.org> wrote:
>> > My question is whether you think it would be worthwhile to ask
>> > developers of the underlying LN node implementations you use to support
>> > self-payment of their own invoices (if they don't already).
>>
>> As far as I know no Lightning node has this ability, which is very
>> unfortunate.
>> If possible this should definitely be implemented. It would be the
>> biggest feature for custodial Lightning service providers of all kinds
>> since always.
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230716/b97a4c97/attachment-0001.html>;

📅 Original date posted:2022-08-31 📝 Original message: Hi ...

2023-06-09T13:06:43Z

In reply to nevent1q…eywd
_________________________

📅 Original date posted:2022-08-31
📝 Original message:
Hi folks,

I think I've seen wallets supporting "send max" when a zero-amount invoice
was used. So isn't it a problem with the custodial service not supporting
it?
Whatever idea we figure out they can just refuse to implement it so we
can't force them into improving and being custodial they could steal
already, so that shouldn't be an issue.

Have a nice day!
Martin

On Sat, 27 Aug 2022 at 04:06, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> Good morning Rene,
>
> > Dear fellow Lightning Developers,
> >
> > I was recently on an event where the visitors have been gifted 10k sats
> on a custodial wallet. They could spend those sats via some web interface
> and an NFC card. During the event I was contacted by several plebs who were
> confused about one particular thing:
> > It was impossible for them to withdraw the full amount from the service.
> >
> > Pasting an invoice for 10k sats would not work as the custodial service
> required a fee budget of 1%. However if people submitted an invoice for
> 9900 sats the remaining 100 sats were usually not fully required for the
> fees. Thus the users may have had a leftover of for example 67 sats. Now
> the problem repeated on the residual amount. While some services seem to
> have a drain feature for such a situation I find this frustrating and was
> wondering if we could help directly on a protocol level.
> >
> > Here is my proposal for a simple solution to this specific problem:
> `option_recipient_pays_routing_fees`
> >
> > This would be a new flag in invoices signaling that the recipient is
> willing to pay for the routing fees by releasing the preimage even if the
> full amount has not been arrived in htlcs at the recipient.
> >
> > So the workflow would be the following:
> >
> > 1. Alice creates an invoice for 10k sats setting the
> `option_recipient_pays_routing_fees` flag in the invoice and passes it
> either to custodial user Bob or to her own custodial account.
> > 2. The payer parses the invoice and searches for a payment path or
> payment flow to Alice.
> > 3. Because `option_recipient_pays_routing_fee` is set, the onion is not
> constructed in a way that the final HTLC will be for the amount of 10k sats
> but rather in a way that the first htlc will be for 10k sats and the
> following HTLCs will be of decreasing value so that routing nodes are
> compensated properly.
> > 4. When the HTLC(s) arrive at Alice she will release the preimage if and
> only if not too many sats (e.g. 1% of the amount) are missing. Of course it
> would be good if the 1% was not hard coded in the protocol / software but
> configurable by Alice at the time of invoice creation.
> >
> > I think the main issue with this proposal is that instead of confusing
> users who wish to drain an account we may now have to educate users about
> two different invoice types. On the other hand I think this can probably
> easily be achieved via the current wide spread user interfaces. Of course
> it may be nice to have folks from the Bitcoin Design community to join this
> specific part of the discussion.
>
> In theory, trampoline routes / whatever-the-cool-name-is-now should fix
> this problem as well.
> I am referring to that scheme where the invoice contains an onion and a
> "trampoline" node that is the only node that can decrypt the first layer of
> the onion.
> The sender then has to route to the trampoline node, and the trampoline
> node then receives the rest of the onion.
>
> In this scheme, the receiver provides an encrypted route from some node to
> itself.
> As the receiver provides the route in order to gain privacy from the
> sender, the onus is on the receiver to deduct the fees from its received
> funds.
> i.e. the sender is only responsible for paying for fees up to the entry
> point of the trampoline.
>
> Thus, such a drain requirement simply means that the custodial service has
> to give its node ID.
> Then the receiver finds a route from the custodial service to itself, and
> encodes that in the trampoline onion, with a direct neighbor of the
> custodial service node as the trampoline.
> The custodial service then does not care about any fees as the receiver
> decided the route; the receiver knows exactly how much to expect (since it
> calculated the route).
>
>
> Of course, it is also possible as you propose, but any level-1-selfish
> custodial service will then always keep the remaining fee budget and always
> ensure that the receiver gets 99% of the value (or 100% -
> whatever_setting_they_chose), paying fees, and keeping the remaining 1% for
> itself.
> The receiver in this case cannot audit the route anyway, and thus cannot
> determine how much the true fees are; whereas in the trampoline case the
> route is specifically selected by the receiver.
>
> 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/20220831/26c6eb67/attachment.html>;

📅 Original date posted:2022-02-01 📝 Original message: > ...

2023-06-09T13:05:06Z

In reply to nevent1q…6ut4
_________________________

📅 Original date posted:2022-02-01
📝 Original message:
> Specific items, maybe not, but maybe a use case for keeping description
> hash for this.
>
> You can't keep hash without making it possible to use it for AOPP-style
verification. The exchanges would just ask users to make invoices with that
hash.

> the envisioned scenario is that this AOPP-style regulation gets
> restrictive enough that nobody can use regulated custodians to make
> payments.
>
Not necessarily, it could also be just so frequent people develop muscle
memory and avoid even trying to pay from exchanges.

> Why do we need to comply with extreme node level KYC enforcement to make
> this the case?
>
I don't know if we *need* it maybe better education can replace it but
surely it helps.

> The enforcement won’t stop with the scenario you’ve described if everyone
> is complying and supporting these regulations in the first place.
>
In a way it was too late when KYC came to exist. Note that slippery slope
can be fallacious argument and I think it's the case here. The specific
regulation is only about proving that you aren't paying someone else. The
intention is for exchanges to not have to register as banks. The objective
is NOT to track people.

> They will get worse. They are already talking about how to DOX the sender
> of a payment by signing a message in a TLV field.
>
The only serious discussion I remember seeing about this proposed to make
it unlinkable. The recipient would not know which node it was.

> Also node IDs could be rotated.
>
> How so? Close down all channels, shut down node, coinjoining utxo’s and
> spin up a new one?
>

No, it literally only requires changing the receiver implementation to
accept messages for any known node ID. The only problem is channel id being
static and we need some protocol for private channels to generate new IDs.

> "KYC" of a private node ID is completely meaningless
>
> This will be the realization of the regulators as well.
>
When they get people smart enough to understand it they will also
understand the only solutions are ban Bitcoin completely or give up. We
can't change it anyway.

> This also assumes there are protective mechanisms in place to make sure a
> “private node” is actually private because that’s not the case and there
> are enough gotchas to break down that assumption.
>
That's also what I said. I encourage you to work on these instead of
removing description.

> An operator of popular public node can just connect to self and pretend
> it's some random person routing through him. It's essentially impossible to
> prove it's not the case.
>
> I think this is a good thing to do but if not done correctly, there can be
> enough correlations to break this down.
>
The only way I can see it being done incorrectly is user entering invoice
from the public node where he shouldn't. Can you see any other?

> Ideally, it’s like you’ve said, “popular public node”. What about everyone
> else?
>
Even unpopular public nodes have plausible deniability even though they
might have harder time. Fixing private nodes should be among top priorities.

> There is not a hard & fast rule that no custodian is processing anything
> except to the user’s (assumingly) private nodes.
>
> Not a big deal except for uninformed dissidents. People who break unjust
dictatorship laws should be more careful. This can't be changed anyway.

> Nodes are being KYC’d now. Invoices and payment reasons are being
> aggregated in mass. How do we stop this now except by removing the ability
> for it *to* happen?
>
We don't need to stop it, making it meaningless is a possibility. And
certainly stopping it by screwing up something else is not a good strategy.
Regardless, we need to educate people about this simple rule:

NEVER put invoices from others into any KYC wallet.

Finally, fixing privacy issues like ID reuse is much more important and
productive than removing description.

Cheers
Martin

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220201/ff49815b/attachment.html>;

📅 Original date posted:2022-01-31 📝 Original message: ...

2023-06-09T13:05:04Z

In reply to nevent1q…96an
_________________________

📅 Original date posted:2022-01-31
📝 Original message:
(sorry for double message, wrong button)

Hi,

I object to the idea that AOPP-like verification is harmful *to lightning*,
quite contrary, it's beneficial! Also removing description creates another
problem: impossibility to prove payment for goods or services making
arbitration hard or impossible.

Why it's beneficial?

Suppose there's a dissident in a dictatorship country wanting to buy banned
goods. He pays using LN. There are two possibilities:
0. exchange doesn't enforce description
1. exchange does enforce description

Let's look at case 0:
The dissident, who happens to not be that knowledgeable about security buys
sats at an exchange and inputs the destination invoice from whoever he pays
directly into the exchange. The exchange logs this along with the identity.
Some time later the node ID being paid for banned goods leaks (very likely
for public nodes) and the tyrants use this to track down dissidents. The
dissident is screwed.

Case 1:
The dissident withdraws to his non-custodial wallet (can't do anything
else) which he then uses to pay. The exchange can not possibly see where
the payment went from non-custodial wallet or if it was even sent away.
Recipients don't know identities of senders so no matter what information
leaks, it's impossible to link the payment.

The biggest real problem with the enforcement is the fact that invoices
leak txids of private channels even though they shouldn't have to. *This*
needs to be fixed, really. Also node IDs could be rotated.

Assuming it's fixed, "KYC" of a private node ID is completely meaningless.
The exchange can not see where the sats ultimately end up - either LN or
chain. It's essentially equivalent to assigning meaningless random number
to each transaction.

This assumes "private" channels but has a simple workaround for public
nodes too. An operator of popular public node can just connect to self and
pretend it's some random person routing through him. It's essentially
impossible to prove it's not the case.

Note that this whole reasoning doesn't apply to BTC chain as addresses
don't have such strong privacy properties but could be applied to e.g.
Monero (maybe a bit weaker guarantee; not endorsing it).

I'm not saying that we should (not) proactively support these efforts,
since accepting regulations is bad precedent but it could be the case here
that it's a good way to turn regulations against the regulators and it
could outweigh the cons.

Hope I'm clear enough. Cheers!
Martin

On Mon, Jan 31, 2022, 06:07 armdxxi via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:

> All,
>
> In light of recent AOPP concerns[0] where custodial users have to sign a
> message from an address to prove that it is theirs when withdrawing from
> highly regulated exchanges, I thought it was important to bring up that
> this is happening in the Lightning space as well.
>
> The tagged field d provides both payers and payees with a description of
> what the transaction is for. When a Lightning Node creates a BOLT11 invoice
> with a description, this is signed. The signature verification process
> validates that it came from a specific node and that it is unaltered.
>
> The problem is that this is being exploited by bad actors in the regulated
> space. Unsuspecting users are going along with it not knowing the
> repercussions.
> KYC Node Verification
>
> Companies like Bottlepay[1] are forcing some users to verify their node by
> creating a specialized invoice. They ask the user to put PII in the
> description and give the signed invoice to the service. Afterwards, a
> database of KYC'd users and their nodes may be stored and shared with 3rd
> parties, regulators, and governments.
>
> Given that the Lightning Network is a reputation-based system without an
> easy way to handle rotations, this has lasting effects if this practice
> were to scale out to all providers. At least with AOPP, one may spin up a
> new on-chain address with ease and attempt to mitigate linkage via coinjoin.
>
> This alone is enough to recommend wallet devs to remove the ability for
> users to unknowingly sign statements with their node. Just like with the
> widespread removal of AOPP from hardware/software wallets, exchanges may
> stop expecting that users are capable of handing over this information with
> ease.
> Payment Reason Aggregation
>
> On the payment receiver side, a user may add a description for their
> reference later on. In an ideal world, only the payer and payee are the
> ones that know the reason for the payment. However, given the current
> reliance on custodians today, these 3rd parties can see and store this
> information.
>
> A good thread[2] highlights some of these concerns. If exchanges are
> relaying invoices to chain analytic companies[3], this can be pretty
> revealing in aggregation.
>
> What they'd know solely on processing Bolt11 invoice data:
>
> 1. Which internal UserID is paying
> 2. Which Lightning Node is receiving a payment
> 3. Amount
> 4. Payment Reason
>
> This information collected in bulk will allow them to map out risk scores
> across the network. These risk scores will lead to censorship problems.
> Additionally, they may share suspected node owners and their known
> transactions with malicious parties.
>
> The onus is on the receiver to not create invoices that reveal personal
> information. But how is a user supposed to know that it could end up being
> collected by 3rd party analytic aggregators? In the end, users may just
> want to tag the invoice and store it internally for their reference. Even
> custodial wallet developers don't realize the repercussions to invoice
> descriptions[4].
>
> Given this, one suggestion I have is to clearly communicate that the
> information users put in invoices can be verified by 3rd parties. Ideally
> wallet devs should remove description completely.
> Description Hash
>
> Using the tagged field description hash h instead of description d might
> help but there are a few problems.
>
> For one, there's a transport problem that's not handled by the BOLT11
> specification. From the spec: the transport mechanism for the description
> in that case is transport specific and not defined here.
>
> A payer's wallet client needs to be able to receive two values from the
> payee now. Both the invoice with the description hash and the description
> text itself. This could happen via QR code in the typical flow today, but
> the problem is that information is still parsed by the payer's wallet.
>
> So if the payer's wallet is a custodian, the custodian is still capable of
> knowing and relaying both Bolt11 Invoice and the unhashed description. The
> benefit is that they may choose *not* to collect this description
> information. Though it still leaves the door open for bad actors.
>
> Further, a salt would need to be added to descriptions for common payment
> reasons to not be guessed.
>
> In the end, description hash is *better* than description, but there are
> UX considerations that may not solve the problem. My suggestion is to save
> the description to the wallet database instead of putting it in the
> invoice. Payers should be provided with a similar description text box that
> may be saved in their database. This gives both users the ability to
> conceal the real reason even if their wallet is a custodian.
> Summary
>
> There's enough exploitation currently happening with Bolt11 invoices that
> we should be concerned about this. My recommendation is to remove the
> ability for users to shoot themselves in the foot. This can happen at the
> application layer today by removing descriptions from wallets. The lack of
> description support will help hinder the ability for mass surveillance in
> the Lightning space.
>
> Regards,
> armdxxi
>
> Links:
> [0]
> https://bitcoinmagazine.com/technical/bitcoin-aopp-and-the-swiss-travel-rule
> [1]
> https://web.archive.org/web/20210616100214/https://help.bottlepay.com/en/articles/5303125-why-and-how-do-i-verify-my-node
> [2] https://twitter.com/niftynei/status/1479154453777465344
> [3] https://blog.chainalysis.com/reports/lightning-network-support/
> [4] https://twitter.com/MattAhlborg/status/1435350678814302211
> _______________________________________________
> 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/20220131/0b4903a4/attachment.html>;

📅 Original date posted:2021-12-06 📝 Original message: I ...

2023-06-09T13:04:33Z

In reply to nevent1q…d402
_________________________

📅 Original date posted:2021-12-06
📝 Original message:
I recommend you researching RGB: https://rgb-org.github.io/

On Mon, Dec 6, 2021, 11:21 Karl <gmkarl at gmail.com> wrote:

> Hi,
>
> I'm not a bitcoin developer.
>
> On Mon, Dec 6, 2021, 5:05 AM Héctor José Cárdenas Pacheco via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hello all,
>>
>> I’ve been thinking about how OP_RETURN is being used to create and trade
>> NFTs on Bitcoin (think RarePepes, SoG and other new ones) and was wondering
>> if it’s possible to
>>
>
> Do you have a link to any of these protocols?
>
> make transactions with this opcode via Lightning.
>>
>> More specific questions could be:
>>
>> 1. Can opcodes like OP_RETURN be inside a channel’s opening or
>> closing transaction?
>> 2. If so, could that OP_RETURN change hands within that channel or
>> network of channels?
>>
>> OP_RETURNs do not have ownership according to the bitcoin network. It is
> not hard to define a protocol that associates an OP_RETURN with ownership,
> and ownership could then be transferred via lightning by sending associated
> currency via lightning. Robustness improvements seem possible.
>
>
>> 1. If possible, could the OP_RETURN be divisible? Could one person
>> send a piece of a OP_RETURN just like one can do right now on the primary
>> ledger or would it need to maintain the OP_RETURN code intact?
>>
>> OP_RETURNs themselves do not have ownership, but you can define a
> protocol that gives them divisible ownership, including via lightning.
>
> I’m assuming that, if possible, this would need a protocol layer parallel
>> to Bitcoin/Lightning that stores and reads all Bitcoin transactions and the
>> ones which involve the node's channels as well as the ones with the
>> OP_RETURN, just like CounterParty does right now with the primary ledger.
>>
>> Thank in advance.
>> ——
>>
>> *Héctor Cárdenas*@hcarpach
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> 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/20211206/d86e56cb/attachment.html>;

📅 Original date posted:2021-10-11 📝 Original message: I can ...

2023-06-09T13:04:03Z

In reply to nevent1q…6h0n
_________________________

📅 Original date posted:2021-10-11
📝 Original message:
I can confirm I moved a repository few months ago and all links kept
working fine.

On Mon, Oct 11, 2021, 20:58 Matt Corallo <lf-lists at mattcorallo.com> wrote:

>
>
> On 10/11/21 05:29, Bryan Bishop wrote:
> > On Mon, Oct 11, 2021 at 12:25 AM Andrés G. Aragoneses <knocte at gmail.com
> <mailto:knocte at gmail.com>>
> > wrote:
> >
> > Completely agree with this. How to move this forward? Set up a vote?
> What would be the reasoning
> > for not moving it?
> >
> >
> > One consideration is broken links, which can be solved by a soft note in
> a README somewhere.
> >
> > - Bryan
> > https://twitter.com/kanzure <https://twitter.com/kanzure>;
>
> I believe the Github "move repository" feature makes all old links
> auto-redirects, so I'd hope this
> wouldn't happen. This information is at least a few years old, however.
>
> 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/20211012/3182a097/attachment.html>;

📅 Original date posted:2021-07-15 📝 Original message: What ...

2023-06-09T13:03:09Z

In reply to nevent1q…m7hm
_________________________

📅 Original date posted:2021-07-15
📝 Original message:
What would happen in 2) if the node has data but the peer returned an
incorrect state?

On Wed, Jul 14, 2021, 20:13 Christian Decker <decker.christian at gmail.com>
wrote:

> Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty
> loss-of-state equates to loss-of-funds, in eltoo this is reduced to
> impact only funds that are in a PTLC at the time of the loss-of-state.
>
> We have a couple of options here, that don't touch the blockchain, and
> are therefore rather lightweight:
>
> 1) Do nothing and keep the incentive to keep up to date backups. It
> still is a reduction in risk w.r.t. LN-penalty, since this is just an
> append only log of secrets, and old secrets don't harm you like
> attempting to close with an old commitment would.
> 2) Use the peer-storage idea, where we deposit an encrypted bundle with
> our peers, and which we expect the peers to return. by hiding the fact
> that we forgot some state, until the data has been exchanged we can
> ensure that peers always return the latest snapshot of whatever we gave
> them.
>
> The latter is the encrypted-blob idea that Rusty has been proposing for
> a while now.
>
> Cheers,
> Christian
>
> Anthony Towns <aj at erisian.com.au> writes:
> > Hello world,
> >
> > Suppose you have some payments going from Alice to Bob to Carol with
> > eltoo channels. Bob's lightning node crashes, and he recovers from an
> > old backup, and Alice and Carol end up dropping newer channel states
> > onto the blockchain.
> >
> > Suppose the timeout for the payments is a few hours away, while the
> > channels have specified a week long CSV delay to rectify any problems
> > on-chain.
> >
> > Then I think that that means that:
> >
> > 1) Carol will reveal the point preimages on-chain via adaptor
> > signatures, but Bob won't be able to decode those adaptor signatures
> > because those signatures will need to change for each state
> >
> > 2) Even if Bob knows the point preimages, he won't be able to
> > claim the PTLC payments on-chain, for the same reason: he needs
> > newer adaptor signatures that he'll have lost with the state update
> >
> > 3) For any payments that timeout, Carol doesn't have any particular
> > incentive to make it easy for Bob to claim the refund, and Bob won't
> > have the adaptor signatures for the latest state to do so
> >
> > 4) But Alice will be able to claim refunds easily. This is working how
> > it's meant to, at least!
> >
> > I think you could fix (3) by giving Carol (who does have all the adaptor
> > signatures for the latest state) the ability to steal funds that are
> > meant to have been refunded, provided she gives Bob the option of
> claiming
> > them first.
> >
> > However fixing (1) and (2) aren't really going against Alice or Carol's
> > interests, so maybe you can just ask: Carol loses nothing by allowing
> > Bob to claim funds from Alice; and Alice has already indicated that
> > knowing P is worth more to her than the PTLC's funds -- otherwise she
> > wouldn't have forwarded the PTLC to Bob in the first place.
> >
> > Likewise, everyone's probably incentivised to negotiate cooperative
> > closes instead of going on-chain -- better privacy, less fees, and less
> > delay before the funds can be used elsewhere.
> >
> > FWIW, I think a similar flaw exists even in the original eltoo spec --
> > Alice could simply decline to publish the settlement transaction until
> > the timeout has been reached, preventing Bob from revealing the HTLC
> > preimage before Alice can claim the refund.
> >
> > So I think that adds up to:
> >
> > a) Nodes should share state on reconnection; if you find a node that
> > doesn't do this, close the channel and put the node on your enemies
> > list. If you disagree on what the current state is, share your most
> > recent state, and if the other guy's state is more recent, and all
> > the signatures verify, update your state to match theirs.
> >
> > b) Always negotiate a mutual/cooperative close if possible, to avoid
> > actually using the eltoo protocol on-chain.
> >
> > c) If you want to allow continuing the channel after restoring an old
> > state from backup, set the channel state index based on the real
> time,
> > eg (real_time-start_time)*(max_updates_per_second). That way your
> > first update after a restore from backup will ensure that any old
> > states that your channel partner may not have told you about are
> > invalidated.
> >
> > d) Accept that if you lose connectivity to a channel partner, you will
> > have to pay any PTLCs that were going to them, and won't be able
> > to claim the PTLCs that were funding them. Perhaps limit the total
> > value of inbound PTLCs for forwarding that you're willing to accept
> > at any one itme?
> >
> > Also, layered commitments seem like they make channel factories
> > complicated too. Nobody came up with a way to avoid layered commitments
> > while I wasn't watching did they?
> >
> > Cheers,
> > aj
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210715/54d800a3/attachment.html>;

📅 Original date posted:2021-07-12 📝 Original message: Hi ...

2023-06-09T13:03:01Z

In reply to nevent1q…mpqp
_________________________

📅 Original date posted:2021-07-12
📝 Original message:
Hi guys,

happy to see this being discussed again! When I came up with the idea,
it was originally intended for cases when there's an inherently trusted
exchange,
such as trading fiat for sats using an ATM. In this scenario only the push
amount was spendable.
Receiving more on top of that was disabled.

Since then some implementations have made zero-conf channels fully
operational.
While strictly worse security, I'm not against it. I'd just really, really
like to have these
cases distinguished.

So I think we need one more bit to signal whether it's only push being
zeroconf or the
channel is fully zeroconf.

Cheers,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210712/63b84d91/attachment.html>;

📅 Original date posted:2021-07-15 📝 Original message: What ...

2023-06-09T12:40:41Z

In reply to nevent1q…4vf4
_________________________

📅 Original date posted:2021-07-15
📝 Original message:
What would happen in 2) if the node has data but the peer returned an
incorrect state?

On Wed, Jul 14, 2021, 20:13 Christian Decker <decker.christian at gmail.com>
wrote:

> Not quite sure if this issue is unique to eltoo tbh. While in LN-penalty
> loss-of-state equates to loss-of-funds, in eltoo this is reduced to
> impact only funds that are in a PTLC at the time of the loss-of-state.
>
> We have a couple of options here, that don't touch the blockchain, and
> are therefore rather lightweight:
>
> 1) Do nothing and keep the incentive to keep up to date backups. It
> still is a reduction in risk w.r.t. LN-penalty, since this is just an
> append only log of secrets, and old secrets don't harm you like
> attempting to close with an old commitment would.
> 2) Use the peer-storage idea, where we deposit an encrypted bundle with
> our peers, and which we expect the peers to return. by hiding the fact
> that we forgot some state, until the data has been exchanged we can
> ensure that peers always return the latest snapshot of whatever we gave
> them.
>
> The latter is the encrypted-blob idea that Rusty has been proposing for
> a while now.
>
> Cheers,
> Christian
>
> Anthony Towns <aj at erisian.com.au> writes:
> > Hello world,
> >
> > Suppose you have some payments going from Alice to Bob to Carol with
> > eltoo channels. Bob's lightning node crashes, and he recovers from an
> > old backup, and Alice and Carol end up dropping newer channel states
> > onto the blockchain.
> >
> > Suppose the timeout for the payments is a few hours away, while the
> > channels have specified a week long CSV delay to rectify any problems
> > on-chain.
> >
> > Then I think that that means that:
> >
> > 1) Carol will reveal the point preimages on-chain via adaptor
> > signatures, but Bob won't be able to decode those adaptor signatures
> > because those signatures will need to change for each state
> >
> > 2) Even if Bob knows the point preimages, he won't be able to
> > claim the PTLC payments on-chain, for the same reason: he needs
> > newer adaptor signatures that he'll have lost with the state update
> >
> > 3) For any payments that timeout, Carol doesn't have any particular
> > incentive to make it easy for Bob to claim the refund, and Bob won't
> > have the adaptor signatures for the latest state to do so
> >
> > 4) But Alice will be able to claim refunds easily. This is working how
> > it's meant to, at least!
> >
> > I think you could fix (3) by giving Carol (who does have all the adaptor
> > signatures for the latest state) the ability to steal funds that are
> > meant to have been refunded, provided she gives Bob the option of
> claiming
> > them first.
> >
> > However fixing (1) and (2) aren't really going against Alice or Carol's
> > interests, so maybe you can just ask: Carol loses nothing by allowing
> > Bob to claim funds from Alice; and Alice has already indicated that
> > knowing P is worth more to her than the PTLC's funds -- otherwise she
> > wouldn't have forwarded the PTLC to Bob in the first place.
> >
> > Likewise, everyone's probably incentivised to negotiate cooperative
> > closes instead of going on-chain -- better privacy, less fees, and less
> > delay before the funds can be used elsewhere.
> >
> > FWIW, I think a similar flaw exists even in the original eltoo spec --
> > Alice could simply decline to publish the settlement transaction until
> > the timeout has been reached, preventing Bob from revealing the HTLC
> > preimage before Alice can claim the refund.
> >
> > So I think that adds up to:
> >
> > a) Nodes should share state on reconnection; if you find a node that
> > doesn't do this, close the channel and put the node on your enemies
> > list. If you disagree on what the current state is, share your most
> > recent state, and if the other guy's state is more recent, and all
> > the signatures verify, update your state to match theirs.
> >
> > b) Always negotiate a mutual/cooperative close if possible, to avoid
> > actually using the eltoo protocol on-chain.
> >
> > c) If you want to allow continuing the channel after restoring an old
> > state from backup, set the channel state index based on the real
> time,
> > eg (real_time-start_time)*(max_updates_per_second). That way your
> > first update after a restore from backup will ensure that any old
> > states that your channel partner may not have told you about are
> > invalidated.
> >
> > d) Accept that if you lose connectivity to a channel partner, you will
> > have to pay any PTLCs that were going to them, and won't be able
> > to claim the PTLCs that were funding them. Perhaps limit the total
> > value of inbound PTLCs for forwarding that you're willing to accept
> > at any one itme?
> >
> > Also, layered commitments seem like they make channel factories
> > complicated too. Nobody came up with a way to avoid layered commitments
> > while I wasn't watching did they?
> >
> > Cheers,
> > aj
> > _______________________________________________
> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210715/54d800a3/attachment.html>;

📅 Original date posted:2021-07-12 📝 Original message: Hi ...

2023-06-09T12:40:33Z

In reply to nevent1q…2ve9
_________________________

📅 Original date posted:2021-07-12
📝 Original message:
Hi guys,

happy to see this being discussed again! When I came up with the idea,
it was originally intended for cases when there's an inherently trusted
exchange,
such as trading fiat for sats using an ATM. In this scenario only the push
amount was spendable.
Receiving more on top of that was disabled.

Since then some implementations have made zero-conf channels fully
operational.
While strictly worse security, I'm not against it. I'd just really, really
like to have these
cases distinguished.

So I think we need one more bit to signal whether it's only push being
zeroconf or the
channel is fully zeroconf.

Cheers,
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210712/63b84d91/attachment.html>;

📅 Original date posted:2021-12-06 📝 Original message:I ...

2023-06-07T23:00:51Z

In reply to nevent1q…3ncw
_________________________

📅 Original date posted:2021-12-06
📝 Original message:I recommend you researching RGB: https://rgb-org.github.io/

On Mon, Dec 6, 2021, 11:21 Karl <gmkarl at gmail.com> wrote:

> Hi,
>
> I'm not a bitcoin developer.
>
> On Mon, Dec 6, 2021, 5:05 AM Héctor José Cárdenas Pacheco via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hello all,
>>
>> I’ve been thinking about how OP_RETURN is being used to create and trade
>> NFTs on Bitcoin (think RarePepes, SoG and other new ones) and was wondering
>> if it’s possible to
>>
>
> Do you have a link to any of these protocols?
>
> make transactions with this opcode via Lightning.
>>
>> More specific questions could be:
>>
>> 1. Can opcodes like OP_RETURN be inside a channel’s opening or
>> closing transaction?
>> 2. If so, could that OP_RETURN change hands within that channel or
>> network of channels?
>>
>> OP_RETURNs do not have ownership according to the bitcoin network. It is
> not hard to define a protocol that associates an OP_RETURN with ownership,
> and ownership could then be transferred via lightning by sending associated
> currency via lightning. Robustness improvements seem possible.
>
>
>> 1. If possible, could the OP_RETURN be divisible? Could one person
>> send a piece of a OP_RETURN just like one can do right now on the primary
>> ledger or would it need to maintain the OP_RETURN code intact?
>>
>> OP_RETURNs themselves do not have ownership, but you can define a
> protocol that gives them divisible ownership, including via lightning.
>
> I’m assuming that, if possible, this would need a protocol layer parallel
>> to Bitcoin/Lightning that stores and reads all Bitcoin transactions and the
>> ones which involve the node's channels as well as the ones with the
>> OP_RETURN, just like CounterParty does right now with the primary ledger.
>>
>> Thank in advance.
>> ——
>>
>> *Héctor Cárdenas*@hcarpach
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> 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/bitcoin-dev/attachments/20211206/d86e56cb/attachment.html>;

📅 Original date posted:2017-06-17 📝 Original message:Hello! ...

2023-06-07T18:03:22Z

In reply to nevent1q…xhp6
_________________________

📅 Original date posted:2017-06-17
📝 Original message:Hello!

I'd appreciate if anyone would like to review my proposal on improving
UASFs, here's the link:
https://gist.github.com/Kixunil/a99c45e79d74bf73328d4192100aa6c6

Abstract:

This document proposes a novel way to improve coordination of users who
wish to activate a new soft fork in Bitcoin. The main idea is to use smart
contracts to incentivize users to actually enforce the soft fork with lower
risk of support being too low. At the same time the contract is in effect
only if significant part of economy agrees to it. The contract also signals
the intent to miners and other users in a way that would be otherwise
expensive for sybil attackers. This proposal also suggests an interesting
way to pay developers for the development of the soft fork code.

FYI the document is timestamped in
transaction 05d5eabcf77964a1e5a704175ef2e54f1fe243ed7aad0a80ede47845173bd2e5
in block 0000000000000000002f4b63ee720958da187405bb807466177be8da2c6ad3b6.

Have a nice day!

Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170617/672ec878/attachment.html>;

📅 Original date posted:2015-02-05 📝 Original ...

2023-06-07T15:29:52Z

In reply to nevent1q…rqyq
_________________________

📅 Original date posted:2015-02-05
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Commit protocol provides both better user experience and better security.

Dňa 6. februára 2015 1:49:12 CET používateľ Paul Puey <paul at airbitz.co> napísal:
>The trust can be considered bootstrapped by visual verification of the
>address prefix. If we are really concerned about someone jamming a
>Bluetooth signal in a coffeeshop then the UI can encourage verification
>of the prefix. Much like how regular Bluetooth requires 'pairing' via
>entering a 4-6 digit code.
>
>
>
>Paul Puey CEO / Co-Founder, Airbitz Inc
>619.850.8624 | http://airbitz.co | San Diego
>
>
>
>
>On Feb 5, 2015, at 3:46 PM, Eric Voskuil <eric at voskuil.org> wrote:
>
>On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote:
>>> A BIP-70 signed payment request in the initial broadcast can resolve
>the
>>> integrity issues, but because of the public nature of the broadcast
>>> coupled with strong public identity, the privacy compromise is much
>>> worse. Now transactions are cryptographically tainted.
>>>
>>> This is also the problem with BIP-70 over the web. TLS and other
>>> security precautions aside, an interloper on the communication,
>desktop,
>>> datacenter, etc., can capture payment requests and strongly
>correlate
>>> transactions to identities in an automated manner. The payment
>request
>>> must be kept private between the parties, and that's hard to do.
>>
>> What about using encryption with forward secrecy? Merchant would
>> generate signed request containing public ECDH part, buyer would send
>> back transaction encrypted with ECDH and his public ECDH part. If
>> receiving address/amount is meant to be private, use commit protocol
>> (see ZRTP/RedPhone) and short authentication phrase (which is hard to
>> spoof thanks to commit protocol - see RedPhone)?
>
>Hi Martin,
>
>The problem is that you need to verify the ownership of the public key.
>A MITM can substitute the key. If you don't have verifiable identity
>associated with the public key (PKI/WoT), you need a shared secret
>(such
>as a secret phrase). But the problem is then establishing that secret
>over a public channel.
>
>You can bootstrap a private session over the untrusted network using a
>trusted public key (PKI/WoT). But the presumption is that you are
>already doing this over the web (using TLS). That process is subject to
>attack at the CA. WoT is not subject to a CA attack, because it's
>decentralized. But it's also not sufficiently deployed for some
>scenarios.
>
>e

- --
Odoslané z môjho Android zariadenia pomocou K-9 Mail.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iI8EAREKADcFAlTUD/AwHE1hcnRpbiBIYWJvdmF0aWFrIDxtYXJ0aW4uaGFib3Zz
dGlha0BnbWFpbC5jb20+AAoJED6C3NvqapyUPwgA/0eVlJYeA3fYmVb1zVA8j1l/
kjOhc9CIDYL9ifk8N0t/AP4mC4CwmZoNXqr24le5WdYeBeyHMiDMtJrRfwQkN1LG
dQ==
=pY76
-----END PGP SIGNATURE-----

📅 Original date posted:2015-02-05 📝 Original ...

2023-06-07T15:29:47Z

In reply to nevent1q…4hez
_________________________

📅 Original date posted:2015-02-05
📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

I believe, we are still talking about transactions of physical people in physical world. So yes, it's proximity based - people tell the words by mouth. :)

In case of RedPhone, you read those words verbally over not-yet-verified channel relying on difficulty of spoofing your voice. Also the app remembers the public keys, so you don't need to verify second time.

I suggest you to try RedPhone (called Signal on iPhone) yourself. It's free/open source, Internet-based and end-to-end encrypted. You may find it useful some day. Also I'm willing to help you with trying it after I wake up. (~8 hours: Send me private e-mail if you want to.)

Dňa 6. februára 2015 1:22:23 CET používateľ Eric Voskuil <eric at voskuil.org> napísal:
>
>On 02/05/2015 04:04 PM, MⒶrtin HⒶboⓋštiak wrote:
>> That's exactly what I though when seeing the RedPhone code, but after
>> I studied the commit protocol I realized it's actually secure and
>> convenient way to do it. You should do that too. :)
>
>I was analyzing the model as you described it to me. A formal analysis
>of the security model of a particular implementation, based on
>inference
>from source code, is a bit beyond what I signed up for. But I'm
>perfectly willing to comment on your description of the model if you
>are
>willing to indulge me.
>
>> Shortly, how it works:
>> The initiator of the connection sends commit message containing the
>> hash of his temporary public ECDH part, second party sends back their
>> public ECDH part and then initiator sends his public ECDH part in
>> open. All three messages are hashed together and the first two bytes
>> are used to select two words from a shared dictionary which are
>> displayed on the screen of both the initiator and the second party.
>
>> The parties communicate those two words and verify they match.
>
>How do they compare words if they haven't yet established a secure
>channel?
>
>> If an attacker wants to do MITM, he has a chance of choosing right
>> public parts 1:65536. There is no way to brute-force it, since that
>> would be noticed immediately. If instead of two words based on the
>> first two bytes, four words from BIP39 wordlist were chosen, it would
>> provide entropy of 44 bits which I believe should be enough even for
>> paranoid people.
>>
>> How this would work in Bitcoin payment scenario: user's phone
>> broadcasts his name, merchant inputs amount and selects the name from
>> the list, commit message is sent (and then the remaining two
>> messages), merchant spells four words he sees on the screen and buyer
>> confirms transaction after verifying that words match.
>
>So the assumption is that there exists a secure (as in proximity-based)
>communication channel?
>
>e
>
>> 2015-02-06 0:46 GMT+01:00 Eric Voskuil <eric at voskuil.org>:
>>> On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote:
>>>>> A BIP-70 signed payment request in the initial broadcast can
>resolve the
>>>>> integrity issues, but because of the public nature of the
>broadcast
>>>>> coupled with strong public identity, the privacy compromise is
>much
>>>>> worse. Now transactions are cryptographically tainted.
>>>>>
>>>>> This is also the problem with BIP-70 over the web. TLS and other
>>>>> security precautions aside, an interloper on the communication,
>desktop,
>>>>> datacenter, etc., can capture payment requests and strongly
>correlate
>>>>> transactions to identities in an automated manner. The payment
>request
>>>>> must be kept private between the parties, and that's hard to do.
>>>>
>>>> What about using encryption with forward secrecy? Merchant would
>>>> generate signed request containing public ECDH part, buyer would
>send
>>>> back transaction encrypted with ECDH and his public ECDH part. If
>>>> receiving address/amount is meant to be private, use commit
>protocol
>>>> (see ZRTP/RedPhone) and short authentication phrase (which is hard
>to
>>>> spoof thanks to commit protocol - see RedPhone)?
>>>
>>> Hi Martin,
>>>
>>> The problem is that you need to verify the ownership of the public
>key.
>>> A MITM can substitute the key. If you don't have verifiable identity
>>> associated with the public key (PKI/WoT), you need a shared secret
>(such
>>> as a secret phrase). But the problem is then establishing that
>secret
>>> over a public channel.
>>>
>>> You can bootstrap a private session over the untrusted network using
>a
>>> trusted public key (PKI/WoT). But the presumption is that you are
>>> already doing this over the web (using TLS). That process is subject
>to
>>> attack at the CA. WoT is not subject to a CA attack, because it's
>>> decentralized. But it's also not sufficiently deployed for some
>scenarios.
>>>
>>> e
>>>

- --
Odoslané z môjho Android zariadenia pomocou K-9 Mail.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iI8EAREKADcFAlTUDKEwHE1hcnRpbiBIYWJvdmF0aWFrIDxtYXJ0aW4uaGFib3Zz
dGlha0BnbWFpbC5jb20+AAoJED6C3NvqapyUfUgA/2j6jQELBtSrNsle7ybGq1D8
uWgGwevguCnjPd0pEpWgAP42sS/ekCqs1v9wbART9fLprZTBk4YPllwXifss+9sa
zQ==
=J4w/
-----END PGP SIGNATURE-----

📅 Original date posted:2015-02-01 📝 Original message:Both ...

2023-06-07T15:29:23Z

In reply to nevent1q…jm6q
_________________________

📅 Original date posted:2015-02-01
📝 Original message:Both wallet and server side implementations will be based on existing
code in me-friendly language (C++>Python>anything else). I don't have
a time for it right now but Crypto hackathon in Parallel Polis
(http://cryptohack.org/) seems like good opportunity for it. I will
let you know then.

2015-02-01 14:43 GMT+01:00 Mike Hearn <mike at plan99.net>:
> If you decide to implement this in an existing or new bitcoinj based wallet,
> then I'm happy to give you pointers on how to do it. Making one-off, cross
> platform app specific wallets is pretty easy these days. For 2-of-3 dispute
> mediation transactions they'd start out being kind of specialist so asking
> people to move money from their general spending wallet into dispute
> mediation app isn't unthinkable. Eventually general purpose wallets would
> integrate protocol, UI ideas and maybe code.
>
> At least, that's how I'd do it.
>
> On Sun, Feb 1, 2015 at 12:02 AM, Martin Habovštiak
> <martin.habovstiak at gmail.com> wrote:
>>
>> I didn't consider that, thank you for feedback! I will try to find
>> some time for implementing it. I'll write again then.
>>
>> 2015-01-31 23:50 GMT+02:00 Gavin Andresen <gavinandresen at gmail.com>:
>> > I agree- standards should be descriptive ("here is how this thing I did
>> > works") and NOT proscriptive ("here's what I think will work, lets all
>> > try
>> > to do it this way.").
>> >
>> >
>> > On Sat, Jan 31, 2015 at 2:07 PM, Mike Hearn <mike at plan99.net> wrote:
>> >>>
>> >>> I could look at implementing it someday, but now I'd like to receive
>> >>> feedback from community.
>> >>
>> >>
>> >> IMO it's better to pair a protocol spec with an implementation.
>> >
>> >
>> > --
>> > --
>> > Gavin Andresen
>
>

📅 Original date posted:2015-02-02 📝 Original message:Do you ...

2023-06-07T15:29:17Z

In reply to nevent1q…jzn7
_________________________

📅 Original date posted:2015-02-02
📝 Original message:Do you have anything that is NOT some web application?

2015-02-02 18:59 GMT+01:00 Mike Hearn <mike at plan99.net>:
> We're way ahead of you guys ;)
>
> On Mon, Feb 2, 2015 at 6:54 PM, Martin Habovštiak
> <martin.habovstiak at gmail.com> wrote:
>>
>> Good idea. I think this could be even better:
>>
>> instead of using third party, send partially signed TX from computer
>> to smartphone. In case, you are paranoid, make 3oo5 address made of
>> two cold storage keys, one on desktop/laptop, one on smartphone, one
>> using third party.
>
>
> https://www.bitcoinauthenticator.org/ - does this already, currently in
> alpha
>
>>
>> > It should be possible to use multisig wallets to protect against
>> > malware. For example, a user could generate a wallet with 3 keys and
>> > require a transaction that has been signed by 2 of those keys. One key is
>> > placed in cold storage and anther sent to a third-party.
>
>
> BitGo, CryptoCorp and (slight variant) GreenAddress all offer this model.

📅 Original date posted:2015-02-02 📝 Original message:Good ...

2023-06-07T15:29:16Z

In reply to nevent1q…7xkh
_________________________

📅 Original date posted:2015-02-02
📝 Original message:Good idea. I think this could be even better:

instead of using third party, send partially signed TX from computer
to smartphone. In case, you are paranoid, make 3oo5 address made of
two cold storage keys, one on desktop/laptop, one on smartphone, one
using third party.
If it isn't enough, add requirement of another four keys, so you have
three desktops with different OS (Linux, Windows, Mac) and three
mobile OS (Android, iOS, Windows Phone), third party and some keys in
cold storage. Also, I forgot HW wallets, so at least Trezor and
Ledger. I believe this scheme is unpenetrable by anyone, including
NSA, FBI, CIA, NBU...

Jokes aside, I think leaving out third party is important for privacy reasons.

Stay safe!

2015-02-02 18:40 GMT+01:00 Brian Erdelyi <brian.erdelyi at gmail.com>:
> Another concept...
>
> It should be possible to use multisig wallets to protect against malware. For example, a user could generate a wallet with 3 keys and require a transaction that has been signed by 2 of those keys. One key is placed in cold storage and anther sent to a third-party.
>
> It is now possible to generate and sign transactions on the users computer and send this signed transaction to the third-party for the second signature. This now permits the use of out of band transaction verification techniques before the third party signs the transaction and sends to the blockchain.
>
> If the third-party is malicious or becomes compromised they would not have the ability to complete transactions as they only have one private key. If the third-party disappeared, the user could use the key in cold storage to sign transactions and send funds to a new wallet.
>
> Thoughts?
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2015-02-01 📝 Original message:BIP70 ...

2023-06-07T15:29:15Z

In reply to nevent1q…z27l
_________________________

📅 Original date posted:2015-02-01
📝 Original message:BIP70 is quite safe agains MitB. If user copies URL belonging to other
merchant, he would see the fact after entering it into his wallet
application. The only problem is, attacker can buy from the same
merchant with user's money. (sending him different URL) This can be
mitigated by merchant setting "memo" to the description of the basket
and some user info (e.g. address to which goods are sent).

But if whole computer is compromised, you're already screwed. Trezor
should help, but I'm not sure if it supports BIP70.

2015-02-01 14:49 GMT+02:00 Brian Erdelyi <brian.erdelyi at gmail.com>:
>
> In online banking, the banks generate account numbers. An attacker cannot
> generate their own account number and the likelihood of an attacker having
> the same account number that I am trying to transfer funds to is low and
> this is why OCRA is effective with online banking.
>
> With Bitcoin, the Bitcoin address is comparable to the recipient’s bank
> account number. I now see how an an attacker can brute force the bitcoin
> address with vanitygen. Is there any way to generate an 8 digit number from
> the bitcoin address that can be used to verify transactions in such a way
> (possibly with hashing?) that brute forcing a bitcoin address would take
> longer than a reasonable period of time (say 60 seconds) so a system could
> time out if a transaction was not completed in that time?
>
> I’ve also looked into BIP70 (Payment Protocol) that claims protection
> against man-in-the-middle/man-in-the-browser (MitB) based attacks. A common
> way to protect against this is with out-of-band transaction verification
> (http://en.wikipedia.org/wiki/Man-in-the-browser#Out-of-band_transaction_verification).
> I see how BIP 70 verifies the payment request, however, is there any way to
> verify that the transaction signed by the wallet matches the request before
> it is sent to the blockchain (and how can this support out of band
> verification)? Perhaps this is something that can only be supported when
> sending money with web based wallets.
>
> Brian Erdelyi
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

📅 Original date posted:2015-01-31 📝 Original message:I ...

2023-06-07T15:29:11Z

In reply to nevent1q…d9q9
_________________________

📅 Original date posted:2015-01-31
📝 Original message:I didn't consider that, thank you for feedback! I will try to find
some time for implementing it. I'll write again then.

2015-01-31 23:50 GMT+02:00 Gavin Andresen <gavinandresen at gmail.com>:
> I agree- standards should be descriptive ("here is how this thing I did
> works") and NOT proscriptive ("here's what I think will work, lets all try
> to do it this way.").
>
>
> On Sat, Jan 31, 2015 at 2:07 PM, Mike Hearn <mike at plan99.net> wrote:
>>>
>>> I could look at implementing it someday, but now I'd like to receive
>>> feedback from community.
>>
>>
>> IMO it's better to pair a protocol spec with an implementation.
>
>
> --
> --
> Gavin Andresen

📅 Original date posted:2015-01-31 📝 Original message:I know ...

2023-06-07T15:29:10Z

In reply to nevent1q…u5js
_________________________

📅 Original date posted:2015-01-31
📝 Original message:I know about that wiki page. I just wanted to design protocol which
would make it easier in practice. (now it would be done manually)

I could look at implementing it someday, but now I'd like to receive
feedback from community.

2015-01-31 19:19 GMT+02:00 Mike Hearn <mike at plan99.net>:
> Hi Martin,
>
> You're on the right lines. Your writeup is pretty similar to the high level
> overview given here though:
>
> https://en.bitcoin.it/wiki/Contracts#Example_2:_Escrow_and_dispute_mediation
>
> To make 2-of-3 dispute mediation works requires implementing a wallet that
> supports it, and the tools mediators need to manage incoming tickets, etc.
> The BIP70 extension is probably the smallest part of the project.
>
>
> On Sat, Jan 31, 2015 at 2:30 AM, Martin Habovštiak
> <martin.habovstiak at gmail.com> wrote:
>>
>> Hello,
>>
>> I've been thinking about how to solve security problems of the servers
>> holding huge amounts of bitcoins (exchanges, markets...) and came up
>> with this idea: https://gist.github.com/Kixunil/2ec79cf40a53fb899ac5
>>
>> TL;DR: it's extension of BIP70 (but not fully compatible due to security
>> reasons) which supports making of multisig transactions dynamically.
>> (The most important thing is that the user provides his address.)
>>
>> What do you think? Is it a good way to solve the problem or do you know
>> about something better? I would really like this or something similar
>> implemented by wallets.
>>
>> Thank you for your feedback!
>>
>> Martin
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>

📅 Original date posted:2015-01-30 📝 Original message:Hello, ...

2023-06-07T15:29:09Z

In reply to nevent1q…kjdm
_________________________

📅 Original date posted:2015-01-30
📝 Original message:Hello,

I've been thinking about how to solve security problems of the servers
holding huge amounts of bitcoins (exchanges, markets...) and came up
with this idea: https://gist.github.com/Kixunil/2ec79cf40a53fb899ac5

TL;DR: it's extension of BIP70 (but not fully compatible due to security
reasons) which supports making of multisig transactions dynamically.
(The most important thing is that the user provides his address.)

What do you think? Is it a good way to solve the problem or do you know
about something better? I would really like this or something similar
implemented by wallets.

Thank you for your feedback!

Martin
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150131/de9440d7/attachment.sig>;