<unnamed>

Public Key

npub1j0cee8lvw7v75c0vfsgfpt5xv8qmr3xzhlwpg9lestngmzwu0u9s6u0kje

Profile Code

nprofile1qqsf8uvunlk80x02v8kycyys46rxrsd3cnptlhq5zluc9e5d38w87zcpzpmhxue69uhkummnw3ezuamfdejszrthwden5te0dehhxtnvdakq8lhqg3

Publishing to

nostr.wine

nos.lol

Last Notes

2023-06-09 12:46:49 UTC

- 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 12:45:22 UTC

- 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 18:07:31 UTC

- 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:46:12 UTC

- reply

📅 Original date posted:2015-12-12
📝 Original message:The general concept has merit and the basic outline here seems sound
enough. I have harboured a notion for having "archived UTXO" for some
time, this is essentially it. The retrieval from archive cost is on the
UTXO holder not the entire storage network, which is then only bearing
full 'instant' retrieval costs for N blocks.
On Sat, 2015-12-12 at 15:09 -0500, jl2012--- via bitcoin-dev wrote:
> It is a common practice in commercial banks that a dormant account might
> be confiscated. Confiscating or deleting dormant UTXOs might be too
> controversial, but allowing the UTXOs set growing without any limit
> might not be a sustainable option. People lose their private keys.
> People do stupid things like sending bitcoin to 1BitcoinEater. We
> shouldn’t be obliged to store everything permanently. This is my
> proposal:
>
> Dormant UTXOs are those UTXOs with 420000 confirmations. In every block
> X after 420000, it will commit to a hash for all UTXOs generated in
> block X-420000. The UTXOs are first serialized into the form:
> txid|index|value|scriptPubKey, then a sorted Merkle hash is calculated.
> After some confirmations, nodes may safely delete the UTXO records of
> block X permanently.
>
> If a user is trying to redeem a dormant UTXO, in addition the signature,
> they have to provide the scriptPubKey, height (X), and UTXO value as
> part of the witness. They also need to provide the Merkle path to the
> dormant UTXO commitment.
>
> To confirm this tx, the miner will calculate a new Merkle hash for the
> block X, with the hash of the spent UTXO replaced by 1, and commit the
> hash to the current block. All full nodes will keep an index of latest
> dormant UTXO commitments so double spending is not possible. (a
> "meta-UTXO set")
>
> If all dormant UTXOs under a Merkle branch are spent, hash of the branch
> will become 1. If all dormant UTXOs in a block are spent, the record for
> this block could be forgotten. Full nodes do not need to remember which
> particular UTXO is spent or not, since any person trying to redeem a
> dormant UTXO has to provide such information.
>
> It becomes the responsibility of dormant coin holders to scan the
> blockchain for the current status of the UTXO commitment for their coin.
> They may also need to pay extra fee for the increased tx size.
>
> This is a softfork if there is no hash collision but this is a
> fundamental assumption in Bitcoin anyway. The proposal also works
> without segregated witness, just by replacing "witness" with "scriptSig"
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 15:42:45 UTC

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

2023-06-07 15:36:01 UTC

- reply

📅 Original date posted:2015-05-31
📝 Original message:Aren't you calculating bandwidth for a singly-connected node? A "highly
connected" miner could have 30-100 node connections so you probably need
to increase your traffic estimates by that factor.
I.e. For 100MB blocks, 30-100 Mbps and $60-$100 per day data costs.
> You should be able to handle 20MB blocks no problem; if I round up to
> 100MB per block that works out to 1.3Mbps.
>
>
> We also use Aliyun and Linode cloud services for block
> propagation. As of May 2015, the price is 0.13 U.S. dollars
> per GB for
> 100Mbps connectivity at Aliyun.
>
>
> That speed will handle 20MB blocks no problem.
>
>
> If each 20MB block is 100MB of data up/down the wire (I'm vastly
> over-estimating, after optimization it should be 40MB) then you'll be
> paying...uhhh:
>
>
> 0.1 GB / block-data-on-wire * 144 blocks/day * 30.5 days/month * 0.13
> $ / GB = $57
>
>
> Less than $2 per day in bandwidth.
>
> For a single cross-border TCP
> connection, it would be certainly far slower than 12.5 MB/s.
>
>
> That's OK, you'll 1.3Mbps or less
> --
> --
> Gavin Andresen
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development