<unnamed>

Public Key

npub1j0cee8lvw7v75c0vfsgfpt5xv8qmr3xzhlwpg9lestngmzwu0u9s6u0kje

Profile Code

nprofile1qqsf8uvunlk80x02v8kycyys46rxrsd3cnptlhq5zluc9e5d38w87zcpzpmhxue69uhkummnw3ezuamfdejszrthwden5te0dehhxtnvdakqz9rhwden5te0wfjkccte9ejxzmt4wvhxjmc4gnuqk

Publishing to

nostr.wine

nos.lol

relay.damus.io

Last Notes

2023-06-09 14:46:49 CEST

- reply

📅 Original date posted:2016-10-05
📝 Original message:
Hi
Thanks for the demo Christian.
Randy, you might like to know that I noticed that lightningd is using
port 8334 and that namecoind has used port 8334 since it was launched in
May 2011.
On Wed, 2016-10-05 at 16:00 +0000, Christian Decker wrote:
> Hi everybody
>
>
> The following blog post describes our recent use of an v0.5 C
> lightning prototype, showcasing a completed transaction that included
> invoicing, multi-hop payment, and item delivery. The included links
> provide additional content and supporting code, as well as a short
> video. This will be going live on Blockstream’s blog shortly.
>
>
> Regards,
> Rusty Russell
> Dr. Christian Decker
>
>
>
>
>
>
> Lightning First Strike: Christian Bought a Cat
> Rusty Russell, October 5, 2016
> https://blockstream.com/blog/
>
>
> This story of feline acquisition begins with the demonstration of v0.5
> of the C lightning prototype, a lightning-fast micropayment system
> we've been working on here at Blockstream (see
> https://github.com/ElementsProject/lightning). To test the impending
> prototype, we set up a web server to create invoices for test bitcoin
> payments over the lightning network, and in return to offer a cat, or
> at least an ASCII cat picture.
>
>
> Dr. Christian Decker, another Blockstream developer working with me,
> purchased the feline picture using 0.01 test bitcoin to open a
> lightning channel with the server (see
> http://tbtc.blockr.io/tx/info/c909f1fb5e971e32ae20e34cf6cf766f7237bfadf75aa6646a42063b9acba82b), which was mined in test block 928335 (see http://tbtc.blockr.io/block/info/928335). After a single confirmation, he paid the invoice with a 100 satoshi transfer. Afterward, he accessed the link to find his cat picture (see http://128.199.80.48/?43744e221d794dcc0e61f8a757fa0346). He discovered it was an ASCII picture, with a nice bonus. Two cats! Christian promptly opened another node, connected to the first node, and bought a second copy of the cat picture by routing through the previous node.
>
>
> What Happened Behind The Scenes?
>
>
> A Digital Ocean server runs Apache, bitcoind, and lightningd. When
> accessed, a CGI script calls 'lightning-cli invoice 100000' to create
> an invoice, which is presented to the user (see
> https://github.com/rustyrussell/lightning-cat/blob/cc206788c552e2f7feb616170178c7ec38ccedb5/catsearch.sh). The user clicks through a unique link, and if 'lightning-cli listinvoice' indicates that the invoice was paid, the script presents the picture.
>
> This is the first end-to-end test of a lightning micropayment network,
> including invoicing, multi-hop payment, and item delivery. It is very
> different from Acinq's recent simulation (see
> http://www.coindesk.com/bitcoins-lightning-network-milestone-acinq-routing/) of a lightning routing algorithm called Flare (See http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf). Their work shows how, by way of simple analogy, one can create a streetmap to get from A to B in an efficient way, while the test we've demonstrated here with v0.5 of the C lightning prototype has us actually walking that path on the street.
>
> What's Next?
>
>
> We found a few bugs in corner cases and hit some known FIXMEs, but
> also made lightningd more robust against misconfiguration. There are a
> few rough edges that we'd still like to smooth and some documentation
> that we'd like to write before the 0.5 release. Then, we want to
> create libraries to allow web developers to play with constructing
> their own cat picture stores!
>
> In the meantime, here's a short video that shows this working (see
> https://asciinema.org/a/ergldrzd43j08klix08hf9yl3). The low production
> value fits with the ASCII art.
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-09 14:45:22 CEST

- reply

📅 Original date posted:2015-12-12
📝 Original message:
On Sun, 2015-12-13 at 01:03 +0000, Denis Gorbachev wrote:
> Hi everybody,
>
>
> Do you think it's a good idea to write a GUI for LN node management?
>
Yes.
>
> Which features would you like to see there?
> --
All of them.
>
> @DenGorbachev
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

2023-06-07 20:07:31 CEST

- reply

📅 Original date posted:2017-11-02
📝 Original message:You launched the political football by coming here with a verbose
'recommendation'. Without a code submission in form of pull request to
the core repo on github this was never a technical discussion.
On Thu, 2017-11-02 at 19:53 -0400, Scott Roberts via bitcoin-dev wrote:
> Whatever their failings from their previous code or their adversarial
> nature, they got this code right and I'm only presenting it as a real
> and excellent solution for the impending threat to bitcoin. As a big
> core fan, I really wanted to delete the word Cash from my post because
> I was afraid someone would turn this technical discussion into a
> political football.
>
> On Nov 2, 2017 7:37 PM, "Gregory Maxwell" <greg at xiph.org> wrote:
> On Thu, Nov 2, 2017 at 11:31 PM, Scott Roberts via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Bitcoin cash will hard fork on Nov 13 to implement a new
> difficulty
> > algorithm. Bitcoin itself might need to hard fork to employ
> a similar
> > algorithm. It's about as good as they come because it
> followed the
>
>
> This is the bitcoin development mailing list, not the "give
> free
> review to the obviously defective proposals of adversarial
> competing
> systems" mailing list. Your posting is off-topic.
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 17:42:45 CEST

- reply

📅 Original date posted:2015-07-22
📝 Original message:Why RSA?
>
> Here is an idea, inspired by TOR, on which I would like to have some
> feedback: We create an anonymous routing layer between Electrum servers
> and clients.
>
> * Each server S publishes a RSA public key, KS
> * Each client receives a list of available servers and their pubkeys
> * For each wallet address, addr_i, a client chooses a server S_i, and a
> RSA keypair (K_addr_i, k_addr_i)
> * The client creates a list of encrypted requests. Each request contains
> addr_i and K_addr_i, and is encrypted with the pubkey KS_i of S_i
> * The client chooses a main server M, and sends the list of encrypted
> requests to M
> * M dispatches the client's requests to the corresponding servers S_i
> (without the client's IP address.)
> * Each server decrypts the requests it receives, performs the request,
> and encrypts the result with K_addr_i
> * M receives encrypted responses, and forwards them to the client.
> * The client decrypts the encrypted response with k_addr_i
>