deploy: 5d93a9e

advancing-bitcoin/2020/index.xml

@@ -21,7 +21,7 @@ Intro Hi everyone. Some of you were at my Bitcoin dev presentation about Miniscr
 Descriptors It is very nice having this scheduled immediately after Andrew Chow’s talk about output descriptors because there is a good transition here.</description></item><item><title>Signet Integration</title><link>https://btctranscripts.com/advancing-bitcoin/2020/2020-02-06-kalle-alm-signet-integration/</link><pubDate>Thu, 06 Feb 2020 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/advancing-bitcoin/2020/2020-02-06-kalle-alm-signet-integration/</guid><description>Slides: https://www.dropbox.com/s/6fqwhx7ugr3ppsg/Signet%20Integration%20V2.pdf
 BIP 325: https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki
 Signet on Bitcoin Wiki: https://en.bitcoin.it/wiki/Signet
-Bitcoin dev mailing list: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016734.html
+Bitcoin dev mailing list: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016734.html
 Bitcoin Core PR 16411 (closed): https://github.com/bitcoin/bitcoin/pull/16411
 Bitcoin Core PR 18267 (open): https://github.com/bitcoin/bitcoin/pull/18267
 Intro I am going to talk about Signet. Do you guys know what Signet is? A few people know. I will explain it briefly. I have an elevator pitch, I have three actually depending on the height of the elevator. Basically Signet is testnet except all the broken parts are removed.</description></item></channel></rss>

bitcoin-core-dev-tech/2017-09/index.xml

@@ -1,5 +1,5 @@
 <?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Bitcoin Core Dev Tech 2017 on ₿itcoin Transcripts</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2017-09/</link><description>Recent content in Bitcoin Core Dev Tech 2017 on ₿itcoin Transcripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Thu, 07 Sep 2017 00:00:00 +0000</lastBuildDate><atom:link href="https://btctranscripts.com/bitcoin-core-dev-tech/2017-09/index.xml" rel="self" type="application/rss+xml"/><item><title>Merkleized Abstract Syntax Trees</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2017-09/2017-09-07-merkleized-abstract-syntax-trees/</link><pubDate>Thu, 07 Sep 2017 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2017-09/2017-09-07-merkleized-abstract-syntax-trees/</guid><description>https://twitter.com/kanzure/status/907075529534328832
-https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014932.html
+https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014932.html
 I am going to talk about the scheme I posted to the mailing list yesterday which is to implement MAST (merkleized abstract syntax trees) in bitcoin in a minimally invasive way as possible. It&amp;rsquo;s broken into two major consensus features that together gives us MAST. I&amp;rsquo;ll start with the last BIP.
 This is tail-call evaluation. Can we generalize P2SH to give us more general capabilities, than just a single redeem script.</description></item><item><title>Signature Aggregation</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2017-09/2017-09-06-signature-aggregation/</link><pubDate>Wed, 06 Sep 2017 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2017-09/2017-09-06-signature-aggregation/</guid><description>https://twitter.com/kanzure/status/907065194463072258
 Sipa, can you sign and verify ECDSA signatures by hand? No. Over GF(43), maybe. Inverses could take a little bit to compute. Over GF(2).

bitcoin-core-dev-tech/2018-03/index.xml

@@ -8,5 +8,5 @@ You take every single path it has; so instead, it becomes … certain c
 Graftroot The idea of graftroot is that in every contract there is a superset of people that can spend the money. This assumption is not always true but it&amp;rsquo;s almost always true. Say you want to lock up these coins for a year, without any conditionals to it, then it doesn&amp;rsquo;t work. But assume you have&amp;ndash; pubkey recovery? No&amp;hellip; pubkey recovery is inherently incompatible with any form of aggregation, and aggregation is far superior.</description></item><item><title>Bellare-Neven</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/2018-03-05-bellare-neven/</link><pubDate>Mon, 05 Mar 2018 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/2018-03-05-bellare-neven/</guid><description>See also http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2017-09-06-signature-aggregation/
 It&amp;rsquo;s been published, it&amp;rsquo;s been around for a decade, and it&amp;rsquo;s widely cited. In Bellare-Neven, it&amp;rsquo;s itself, it&amp;rsquo;s a multi-signature scheme which means multiple pubkeys and one message. You should treat the individual authorizations to spend inputs, as individual messages. What we need is an interactive aggregate signature scheme. Bellare-Neven&amp;rsquo;s paper suggests a trivial way of building an aggregate signature scheme out of a multisig scheme where interactively everyone signs everyone&amp;rsquo;s message.</description></item><item><title>Cross Curve Atomic Swaps</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/2018-03-05-cross-curve-atomic-swaps/</link><pubDate>Mon, 05 Mar 2018 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/2018-03-05-cross-curve-atomic-swaps/</guid><description>https://twitter.com/kanzure/status/971827042223345664
 Draft of an upcoming scriptless scripts paper. This was at the beginning of 2017. But now an entire year has gone by.
-post-schnorr lightning transactions https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001031.html
+post-schnorr lightning transactions https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001031.html
 An adaptor signature.. if you have different generators, then the two secrets to reveal, you just give someone both of them, plus a proof of a discrete log, and then you say learn the secret to one that gets the reveal to be the same.</description></item></channel></rss>

bitcoin-core-dev-tech/2019-06/index.xml

@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Bitcoin Core Dev Tech 2019 on ₿itcoin Transcripts</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/</link><description>Recent content in Bitcoin Core Dev Tech 2019 on ₿itcoin Transcripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Fri, 07 Jun 2019 00:00:00 +0000</lastBuildDate><atom:link href="https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/index.xml" rel="self" type="application/rss+xml"/><item><title>AssumeUTXO</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-07-assumeutxo/</link><pubDate>Fri, 07 Jun 2019 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-07-assumeutxo/</guid><description>https://twitter.com/kanzure/status/1137008648620838912
 Why assumeutxo assumeutxo is a spiritual continuation of assumevalid. Why do we want to do this in the first place? At the moment, it takes hours and days to do initial block download. Various projects in the community have been implementing meassures to speed this up. Casa I think bundles datadir with their nodes. Other projects like btcpay have various ways of bundling this up and signing things with gpg keys and these solutions are not quite half-baked but they are probably not desirable either.</description></item><item><title>Blind statechains: UTXO transfer with a blind signing server</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-07-statechains/</link><pubDate>Fri, 07 Jun 2019 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-07-statechains/</guid><description>https://twitter.com/kanzure/status/1136992734953299970
-&amp;ldquo;Formalizing Blind Statechains as a minimalistic blind signing server&amp;rdquo; https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017005.html
+&amp;ldquo;Formalizing Blind Statechains as a minimalistic blind signing server&amp;rdquo; https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017005.html
 overview: https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39
 statechains paper: https://github.com/RubenSomsen/rubensomsen.github.io/blob/master/img/statechains.pdf
 previous transcript: http://diyhpl.us/wiki/transcripts/scalingbitcoin/tokyo-2018/statechains/
@@ -10,18 +10,18 @@ https://github.com/bitcoin-core/bitcoin-devwiki/wiki/P2P-Design-Philosophy
 &amp;ldquo;Elligator Squared: Uniform Points on Elliptic Curves of Prime Order as Uniform Random Strings&amp;rdquo; https://eprint.iacr.org/2014/043
 Previous talks https://btctranscripts.com/scalingbitcoin/milan-2016/bip151-peer-encryption/
 https://btctranscripts.com/sf-bitcoin-meetup/2017-09-04-jonas-schnelli-bip150-bip151/
-Introduction This proposal has been in progress for years. Many ideas from sipa and gmaxwell went into bip151. Years ago I decided to try to move this forward. There is bip151 that again most of the ideas are not from myself but come from sipa and gmaxwell. The original proposal was withdrawn because we figured out ways to do it better.</description></item><item><title>Signet</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-07-signet/</link><pubDate>Fri, 07 Jun 2019 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-07-signet/</guid><description>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016734.html
+Introduction This proposal has been in progress for years. Many ideas from sipa and gmaxwell went into bip151. Years ago I decided to try to move this forward. There is bip151 that again most of the ideas are not from myself but come from sipa and gmaxwell. The original proposal was withdrawn because we figured out ways to do it better.</description></item><item><title>Signet</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-07-signet/</link><pubDate>Fri, 07 Jun 2019 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-07-signet/</guid><description>https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016734.html
 https://twitter.com/kanzure/status/1136980462524608512
 Introduction I am going to talk a little bit about signet. Does anyone not know what signet is? The idea is to have a signature of the block or the previous block. The idea is that testnet is horribly broken for testing things, especially testing things for long-term. You have large reorgs on testnet. What about testnet with a less broken difficulty adjustment? Testnet is for miner testing really.</description></item><item><title>General discussion on SIGHASH_NOINPUT, OP_CHECKSIGFROMSTACK, and OP_SECURETHEBAG</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-06-noinput-etc/</link><pubDate>Thu, 06 Jun 2019 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-06-noinput-etc/</guid><description>SIGHASH_NOINPUT, ANYPREVOUT, OP_CHECKSIGFROMSTACK, OP_CHECKOUTPUTSHASHVERIFY, and OP_SECURETHEBAG
 https://twitter.com/kanzure/status/1136636856093876225
 There&amp;rsquo;s apparently some political messaging around OP_SECURETHEBAG and &amp;ldquo;secure the bag&amp;rdquo; might be an Andrew Yang thing.
-SIGHASH_NOINPUT A bunch of us are familiar with NOINPUT. Does anyone need an explainer? What&amp;rsquo;s the difference from the original NOINPUT and the new one? NOINPUT is kind of scary to at least some people. If we just do NOINPUT, does that start causing problems in bitcoin?</description></item><item><title>Great Consensus Cleanup</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-06-great-consensus-cleanup/</link><pubDate>Thu, 06 Jun 2019 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-06-great-consensus-cleanup/</guid><description>https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016714.html
+SIGHASH_NOINPUT A bunch of us are familiar with NOINPUT. Does anyone need an explainer? What&amp;rsquo;s the difference from the original NOINPUT and the new one? NOINPUT is kind of scary to at least some people. If we just do NOINPUT, does that start causing problems in bitcoin?</description></item><item><title>Great Consensus Cleanup</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-06-great-consensus-cleanup/</link><pubDate>Thu, 06 Jun 2019 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-06-great-consensus-cleanup/</guid><description>https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-March/016714.html
 https://twitter.com/kanzure/status/1136591286012698626
 Introduction There&amp;rsquo;s not much new to talk about. Unclear about CODESEPARATOR. You want to make it a consensus rule that transactions can&amp;rsquo;t be larger than 100 kb. No reactions to that? Alright. Fine, we&amp;rsquo;re doing it. Let&amp;rsquo;s do it. Does everyone know what this proposal is?
 Validation time for any block&amp;ndash; we were lazy about fixing this. Segwit was a first step to fixing this, by giving people a way to do this in a more efficient way.</description></item><item><title>Maintainers view of the Bitcoin Core project</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-06-maintainers/</link><pubDate>Thu, 06 Jun 2019 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-06-maintainers/</guid><description>https://twitter.com/kanzure/status/1136568307992158208
 How do the maintainers think or feel everything is going? Are there any frustrations? Could contributors help eliminate these frustrations? That&amp;rsquo;s all I have.
 It would be good to have better oversight or overview about who is working in what direction, to be more efficient. Sometimes I have seen people working on the same thing, and both make a similar pull request with a lot of overlap. This is more of a coordination issue.</description></item><item><title>Taproot</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-06-taproot/</link><pubDate>Thu, 06 Jun 2019 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2019-06/2019-06-06-taproot/</guid><description>https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki
-https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html
+https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html
 https://bitcoinmagazine.com/articles/taproot-coming-what-it-and-how-it-will-benefit-bitcoin/
 previously: http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2018-03-06-taproot-graftroot-etc/
 https://twitter.com/kanzure/status/1136616356827283456

bitcoinplusplus/2022/index.xml

@@ -1,6 +1,6 @@
 <?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Bitcoin++ 2022 on ₿itcoin Transcripts</title><link>https://btctranscripts.com/bitcoinplusplus/2022/</link><description>Recent content in Bitcoin++ 2022 on ₿itcoin Transcripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Tue, 07 Jun 2022 00:00:00 +0000</lastBuildDate><atom:link href="https://btctranscripts.com/bitcoinplusplus/2022/index.xml" rel="self" type="application/rss+xml"/><item><title>Minisketch and Lightning gossip</title><link>https://btctranscripts.com/bitcoinplusplus/2022/2022-06-07-alex-myers-minisketch-lightning-gossip/</link><pubDate>Tue, 07 Jun 2022 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoinplusplus/2022/2022-06-07-alex-myers-minisketch-lightning-gossip/</guid><description>Location: Bitcoin++
 Slides: https://endothermic.dev/presentations/magical-minisketch
-Rusty Russell on using Minisketch for Lightning gossip: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001741.html
+Rusty Russell on using Minisketch for Lightning gossip: https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-December/001741.html
 Minisketch library: https://github.com/sipa/minisketch
 Bitcoin Core PR review club on Minisketch (3 sessions):
 https://bitcoincore.reviews/minisketch-26

c-lightning/index.xml

@@ -44,7 +44,7 @@ Topic: Various topics
 Location: Jitsi online
 Video: No video posted online
 The conversation has been anonymized by default to protect the identities of the participants. Those who have expressed a preference for their comments to be attributed are attributed. If you were a participant and would like your comments to be attributed please get in touch.
-Dust HTLC exposure (Lisa Neigut) Antoine Riard email to the Lightning dev mailing list: https://lists.</description></item><item><title>c-lightning developer call</title><link>https://btctranscripts.com/c-lightning/2021-09-20-developer-call/</link><pubDate>Mon, 20 Sep 2021 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/c-lightning/2021-09-20-developer-call/</guid><description>Topic: Various topics
+Dust HTLC exposure (Lisa Neigut) Antoine Riard email to the Lightning dev mailing list: https://gnusha.</description></item><item><title>c-lightning developer call</title><link>https://btctranscripts.com/c-lightning/2021-09-20-developer-call/</link><pubDate>Mon, 20 Sep 2021 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/c-lightning/2021-09-20-developer-call/</guid><description>Topic: Various topics
 Location: Jitsi online
 Video: No video posted online
 Agenda: https://hackmd.io/@cdecker/Sy-9vZIQt