Brian Lockhart [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2018-02-13 to 2018-06-14
💬 Posted a total of 4 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-09 12:49:16

- reply

📅 Original date posted:2018-02-25
📝 Original message:
“Hear one hear all! Good people, harken and know that on this day the one called Laszlo did buyeth the first Bitcoin Lightning Pizzas, bringing us into this new era of glory and cheesy goodness. And it was good.”
> On Feb 24, 2018, at 5:29 PM, Laszlo Hanyecz <laszlo at heliacal.net> wrote:
>
> I wanted to try out a real trade using lightning network. I don't know of any pizza places near me that accept lightning bitcoin yet but a friend from London agreed to do it and he sub contracted out the pizza delivery to a local shop.
> In short, I paid bitcoin using the lightning network and he arranged for pizza to be delivered to me. In this trade my friend is just a middle man that is taking the risk on accepting lightning payments, but it demonstrates the basic premise of how this works for everyday transactions. It could just as well be the pizza shop accepting the payment directly with their own lightning node.
> I wanted two pizzas and to try to do it as close to atomically as possible. I didn't want to prepay and end up with no pizza. As far as I know we don't yet have pizza/bitcoin atomic swap software but we improvised and decided that I would need to provide the payment hash preimage to the delivery driver in order to claim my pizza. If I can't produce the preimage, proving that I paid, then the pizza would not be handed over and it would be destroyed. This works because I can't get the preimage without paying the invoice. I agreed to open a channel and fund it with a sufficient amount for what we estimated the cost would end up being. After we agreed to these terms my friend was able to verify that I funded a channel on the blockchain, which shows that I at least have the money (bitcoin). He is taking on some entrepreneurial risk and prepaying his sub contractor to prepare and deliver the pizza to me, but at this point I have not risked my bitcoins, they're just committed to a channel. I was given a bolt11 invoice which I decoded with the c-lightning cli to verify everything was as agreed:
>
> $ ./lightning-cli decodepay lnbc6490u1pdfrjhcpp5jyxuuskqw53apgqvtxa7emcrz5vs0qr2sxjayxv7jj70jznnl94sdp5x9vycgzrdpjk2umeypgxj7n6vykzqvfqg3jkcatcv5s9q6t60fssxqyzx2qcqpgaue37x27yp3pn4cr6wuprvwedncz4kavqh83cp3l0vwfrprj0xj8cedkfmjdzea0xpp0jazfcyy77cq37ej6d3xvmujmgu56pe56ktcqa3vcys
> { "currency" : "bc", "timestamp" : 1519504120, "created_at" : 1519504120, "expiry" : 72000, "payee" : "0397b318c5e0d09b16e6229ec50744c8a7a8452b2d7c6d9855c826ff14b8fa8b27", "msatoshi" : 649000000, "description" : "1XL Cheesy Pizza, 1 Deluxe Pizza", "min_final_cltv_expiry" : 8, "payment_hash" : "910dce42c07523d0a00c59bbecef03151907806a81a5d2199e94bcf90a73f96b", "signature" : "3045022100ef331f195e206219d703d3b811b1d96cf02adbac05cf1c063f7b1c91847279a402207c65b64ee4d167af3042f97449c109ef6011f665a6c4ccdf25b4729a0e69ab2f" }
>
> When the pizza delivery arrived, I was asked "What is the preimage?" by the driver. At this point I paid the invoice and instantly received the preimage in return.
>
> $ ./lightning-cli pay lnbc6490u1pdfrjhcpp5jyxuuskqw53apgqvtxa7emcrz5vs0qr2sxjayxv7jj70jznnl94sdp5x9vycgzrdpjk2umeypgxj7n6vykzqvfqg3jkcatcv5s9q6t60fssxqyzx2qcqpgaue37x27yp3pn4cr6wuprvwedncz4kavqh83cp3l0vwfrprj0xj8cedkfmjdzea0xpp0jazfcyy77cq37ej6d3xvmujmgu56pe56ktcqa3vcys
> { "preimage" : "7241e3f185148625894b8887ad459babd26540fc12124c3a7a96c937d89da8c1", "tries" : 1 }
>
> In the interest of keeping it simple we agreed that the preimage would just be the first and last 4 characters of the hex string. So my answer was 7241-a8c1. I wrote this on a notepad and presented it to the driver who compared it to his own notepad, at which point I was given the pizza. It's probably not a good practice to share the preimage. The delivery driver didn't have the full string, only enough to verify that I had it.
> How do you get the preimage for your invoice? In c-lightning you can do it like this:
> $ ./lightning-cli invoice 12345 label description
> { "payment_hash" : "e04dfbd4adc634779b560c8e7072f883d5f17a3e32a33603bfc90a8682873d44", "expiry_time" : 1519523498, "expires_at" : 1519523498, "bolt11" : "lnbc123450p1pdfyzy6pp5upxlh49dcc680x6kpj88quhcs02lz737x23nvqaley9gdq5884zqdqjv3jhxcmjd9c8g6t0dccqpg802ys4s4z3rpm6d8zvdgq397wewh5kaz527hnglz9xsmjxfjrhe3mxq9pp7pqm0pwcwm748tav4am97gqrvnzxnlw5uxxawgw4vcywgphj26nf" }
> $ sqlite3 ~/.lightning/lightningd.sqlite3 "SELECT quote(payment_key) FROM invoices ORDER BY id DESC LIMIT 1"
> X'D3BE7E68D8B38B15A5194AEA131A21429A1987085C95A0631273273546FF5ED8'
> Then you can verify that it's indeed the correct preimage by hashing it again and comparing it to the payment_hash in the invoice above:
> $ echo "D3BE7E68D8B38B15A5194AEA131A21429A1987085C95A0631273273546FF5ED8" | xxd -r -p | sha256sum
> e04dfbd4adc634779b560c8e7072f883d5f17a3e32a33603bfc90a8682873d44 -
> Note that you should not share the preimage with anyone.
>
> So is there any point to doing this instead of an on chain transaction? For what I described here, probably not. The goal was just to play around with c-lightning and do something more than shuffling a few satoshi back and forth. Maybe eventually pizza shops will have their own lightning nodes and I can open channels to them directly.
>
> Some pics of my family enjoying the pizza here: http://eclipse.heliacal.net/~solar/bitcoin/lightning-pizza/
>
> -Laszlo
> _______________________________________________
> 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/20180225/0b4f1ea3/attachment-0001.html>

2023-06-09 12:49:16

- reply

2023-06-07 18:13:01

- reply

📅 Original date posted:2018-06-14
📝 Original message:Resolved -> RTFM
Worked like a champ, first try. Thanks! Wish I had thought to look into that sooner! My c-lightning node’s resource footprint is even smaller now. Unfairly small.
And now that I’ve unexpectedly regained ~180 GB worth of free SSD space from not having that extra full node, I’m feeling wealthy. Accordingly, I’m off to squander my newfound riches over at satoshis’s place. )
> On Jun 13, 2018, at 9:17 AM, Christian Decker <decker.christian at gmail.com> wrote:
>
> Brian Lockhart <brianlockhart at gmail.com> writes:
>> In the interest of avoiding running multiple bitcoind full nodes - is there
>> a method to allow a Lightning node to point to / access a separate
>> already-existing node, vs. requiring it to have its own dedicated local
>> instance of bitcoind running?
>>
>> I.e. if I already have a full bitcoin node running, could I use RPC calls
>> or something to tell my Lightning node to use that node, instead of
>> spinning up *another* full node? I’m currently minimizing the network
>> thrashing by whitelisting my LN bitcoind node to only point to my existing
>> full node for updates, but if I could just point my whole LN node at it,
>> that’s save on disk storage etc. etc. etc.
>
> Certainly, that's supported by all 3 implementations:
>
> - With c-lightning you can either configure `bitcoin-cli` to connect to
> a remote node with the `rpcconnect`, `rpcuser`, and `rpcpassword`
> options in the `bitcoin.conf` file (at which point all calls to
> `bitcoin-cli` will use that node) or you can use the following
> command line options when starting `lightningd`: `--bitcoin-rpcuser`,
> `--bitcoin-rpcpassword` and `--bitcoin-rpcconnect`
> - lnd allows you to specify the node to connect to using the command
> line options `--bitcoind.rpchost`, `--bitcoind.rpcuser`, and
> `--bitcoind.rpcpass`.
> - Eclair requires you to edit the configuration file [1] before
> compiling afaik
>
> Cheers,
> Christian
>
>
> [1] https://github.com/ACINQ/eclair/blob/master/eclair-core/src/main/resources/reference.conf

2023-06-07 18:13:01

- reply

2023-06-07 18:13:00

- reply

📅 Original date posted:2018-06-13
📝 Original message:Somewhat related question -
In the interest of avoiding running multiple bitcoind full nodes - is there
a method to allow a Lightning node to point to / access a separate
already-existing node, vs. requiring it to have its own dedicated local
instance of bitcoind running?
I.e. if I already have a full bitcoin node running, could I use RPC calls
or something to tell my Lightning node to use that node, instead of
spinning up *another* full node? I’m currently minimizing the network
thrashing by whitelisting my LN bitcoind node to only point to my existing
full node for updates, but if I could just point my whole LN node at it,
that’s save on disk storage etc. etc. etc.
Apologies if this is already in there (or has been added) and I missed it
because I haven’t kept up with release notes…
On June 13, 2018 at 6:35:49 AM, Christian Decker via bitcoin-dev (
bitcoin-dev at lists.linuxfoundation.org) wrote:
Kulpreet Singh via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org>
writes:
> But if I understand correctly, lightning nodes need to check if a
> counterparty is broadcasting an old channel state and in response
> broadcast a penalty/justice transaction. Does that mean lightning
> nodes only need to watch for transactions that come after the funding
> transaction? Is that the only reason lightning needs to run bitcoind
> with txindex?
Yes, Lightning nodes need to monitor the network for transactions that
they need to react to. This is basically tailing the blockchain and
looking for anything suspicious. The `bitcoind` sitting next to the
lightning node however does not need to keep an index of the
transactions, at least for c-lightning, because we just ask for the full
block that then gets scanned for transactions of interest and then we
discard the rest of the block. We never ask for a specific transaction
from `bitcoind` and therefore we don't need to run with `-txindex`.
> If that is the case, and a lightning node only needs to query
> transactions broadcast after the funding transaction, then a pruned
> bitcoind instance with txindex might be a bit handy.
Pruned nodes should work, as long as the current blockchain head that
the lightning node has seen does not fall into the pruned range, since
in that case it won't be able to fetch and process the blocks anymore.
> Also from [1] it seems that indexing pruned nodes is not supported
> because it doesn't make sense, not that it was infeasible. Now with
> the lightning requirements, does an indexed pruned node start to make
> sense?
I don't think we should ever require `-txindex` to run a lightning node
(I know some implementations did in the past), since that'd be a very
onerous requirement to run a lightning node. Tailing the blockchain is
more than sufficient to get the necessary data, and hopefully we can get
our reliance on `bitcoind` down to a minimum in the future.
> Once again, please forgive my naive understanding of some of the issues
> involved and thanks for your patience.
Absolutely no problem, it is a common misconception that `-txindex` is
required to run a lightning node in all cases :-)
Cheers,
Christian
_______________________________________________
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/20180613/3b904f54/attachment-0001.html>

2023-06-07 18:13:00

- reply

2023-06-07 18:10:46

- reply

📅 Original date posted:2018-02-13
📝 Original message:> I don't think that Bitcoin should be reliant upon courts or governments
to defend itself against attacks of any form.
Agree 100%. Plus yeah, lotsa luck getting any success via those channels...
But assuming the answer to the perceived problem is to “fight fire with
fire” (using social / marketing based efforts) who “should” pick up the
mantle here? Without inciting riots by asking the question, wouldn’t that
ostensibly be something the Bitcoin Foundation would lead on here? <ducks
and runs for cover>
In any case, it’s frustrating to watch the ongoing FUD and scammery going
unanswered in any “official” capacity.
On February 13, 2018 at 7:25:35 AM, Jameson Lopp via bitcoin-dev (
bitcoin-dev at lists.linuxfoundation.org) wrote:
If I'm understanding the problem being stated correctly:
"Bitcoin is under a branding attack by fork coins."
The proposed solution is to disincentivize fork coins from using the word
Bitcoin by altering the license terms. I'm not a lawyer, but it seems to me
that the words of the license are basically useless unless there is an
entity that intends to make use of court systems to threaten noncompliant
projects into submission.
In my opinion, the perceived attack on Bitcoin here is social /
marketing-based, thus it makes sense that any defense against said attack
should also be social / marketing-based. I don't think that Bitcoin should
be reliant upon courts or governments to defend itself against attacks of
any form.
On Tue, Feb 13, 2018 at 9:25 AM, Natanael via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> Den 13 feb. 2018 15:07 skrev "JOSE FEMENIAS CAÑUELO via bitcoin-dev" <
> bitcoin-dev at lists.linuxfoundation.org>:
>
> ***
> NO PART OF THIS SOFTWARE CAN BE INCLUDED IN ANY OTHER PROJECT THAT USES
> THE NAME BITCOIN AS PART OF ITS NAME AND/OR ITS MARKETING MATERIAL UNLESS
> THE SOFTWARE PRODUCED BY THAT PROJECT IS FULLY COMPATIBLE WITH THE BITCOIN
> (CORE) BLOCKCHAIN
> ***
>
>
> That's better solved with trademarks. (whoever would be the trademark
> holder - Satoshi?)
>
> This would also prohibit any reimplementation that's not formally verified
> to be perfectly compatible from using the name.
>
> It also adds legal uncertainty.
>
> Another major problem is that it neither affects anybody forking older
> versions of Bitcoin, not people using existing independent blockchain
> implementations and renaming them Bitcoin-Whatsoever.
>
> And what happens when an old version is technically incompatible with a
> future version by the Core team due to not understanding various new
> softforks? Which version wins the right to the name?
>
> Also, being unable to even mention Bitcoin is overkill.
>
> The software license also don't affect the blockchain data.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
_______________________________________________
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/20180213/645a487a/attachment.html>

2023-06-07 18:10:46

- reply