-
Notifications
You must be signed in to change notification settings - Fork 13
Commit
- Loading branch information
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,7 @@ | ||
<?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 2015 on ₿itcoin Transcripts</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2015-02/</link><description>Recent content in Bitcoin Core Dev Tech 2015 on ₿itcoin Transcripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><atom:link href="https://btctranscripts.com/bitcoin-core-dev-tech/2015-02/index.xml" rel="self" type="application/rss+xml"/><item><title>Bitcoin Law For Developers</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2015-02/james-gatto-marco-santori-bitcoin-law-for-developers/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2015-02/james-gatto-marco-santori-bitcoin-law-for-developers/</guid><description>We are going to be taking a 15 minute coffee break after our next two speakers. I want to introduce you to James Gatto and Marco Santori with Pilsbury. They will be spending some time talking about Bitcoin law. They have a room this afternoon and they are offering to talk with you one on one. So Marco and James. | ||
You missed the introduction. Was it any good? (laughter) | ||
We are here to talk about legal issues.</description></item><item><title>Circle</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2015-02/jeremy-allaire-circle/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2015-02/jeremy-allaire-circle/</guid><description>We are excited to be here and sponsoring this event. We have backgrounds in working on developer tools that goes back to the early days of something. | ||
How do we mature the development of Bitcoin Core itself? One of the things that is useful is suss out the key components of it. In a standard you have a spec, it could be a whitepaper, and then you have a reference implementation, and then a test suite that enforces interoperability.</description></item><item><title>Gavinandresen</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2015-02/gavinandresen/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2015-02/gavinandresen/</guid><description>http://blog.circle.com/2015/02/10/devcore-livestream/ | ||
The instant transaction time.. you know I walk up to a cash register, I put my phone there, and in a second or two the transaction is confirmed and I walk away with my coffee. Anything beyond that, 10 minutes versus 1 minute doesn&rsquo;t matter. So the problem you want to solve is how do we get instant confirmation.. there&rsquo;s a bunch of ideas about this, like a trusted third party that promises to not double spend, have some coins locked up in a multisig wallet like Green Address.</description></item><item><title>Research And Development Goals</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2015-02/research-and-development-goals/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2015-02/research-and-development-goals/</guid><description>R&amp;D Goals &amp; Challenges | ||
We often see people saying they are testing the waters, they fixed a typo, they made a tiny little fix that doesn&rsquo;t impact much, they are getting used to the process. They are finding that it&rsquo;s really easy to contribut to Bitcoin Core. You code your changes, you submit your changes, there&rsquo;s not much to it. | ||
There&rsquo;s a difference, and the lines are fuzzy and undefined, and you cna make a change to Core that changes a spelling error or a change to policy or consensus rules, for those high-level things, for ecosystem-level things, there&rsquo;s several mailing lists, the dev list gets the most traffic.</description></item></channel></rss> |
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
<!doctype html><html lang=es><head><title>https://btctranscripts.com/es/bitcoin-core-dev-tech/2017-09/2017-09-07-merkleized-abstract-syntax-trees/</title><link rel=canonical href=https://btctranscripts.com/es/bitcoin-core-dev-tech/2017-09/2017-09-07-merkleized-abstract-syntax-trees/><meta name=robots content="noindex"><meta charset=utf-8><meta http-equiv=refresh content="0; url=https://btctranscripts.com/es/bitcoin-core-dev-tech/2017-09/2017-09-07-merkleized-abstract-syntax-trees/"></head></html> |
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
<?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 | ||
Merkleized abstract syntax trees (MAST) 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&rsquo;s broken into two major consensus features that together gives us MAST. I&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 | ||
Signature aggregation 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). | ||
I think the first thing we should talk about is some definitions. I&rsquo;d like to start by distinguishing between three things: Key aggregation, signature aggregation, and batch validation. Multi-signature later. | ||
There are three different problems. Key aggregation is where there are a number of people with each their own key, they want to produce a combined key that can only sign when they come together.</description></item><item><title>Meeting Notes</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2017-09/2017-09-05-meeting-notes/</link><pubDate>Tue, 05 Sep 2017 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2017-09/2017-09-05-meeting-notes/</guid><description>coredev.tech september 2017 | ||
https://twitter.com/kanzure/status/907233490919464960 | ||
((As always, any errors are most likely my own. etc.)) | ||
# Introduction There is significant concern regarding whether BlueMatt has become a misnomer. | ||
Monday night presentation: https://btctranscripts.com/sf-bitcoin-meetup/2017-09-04-jonas-schnelli-bip150-bip151/ | ||
I think we should continue to use #bitcoin-core-dev for anything about changing Bitcoin Core and try to keep things open even though we&rsquo;re together here today and tomorrow and the next. | ||
# Wallets and block pruning and rescans Nobody produces P2SH change when they have a native output.</description></item></channel></rss> |
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1 @@ | ||
<!doctype html><html lang=es><head><title>https://btctranscripts.com/es/bitcoin-core-dev-tech/2018-03/2018-03-07-priorities/</title><link rel=canonical href=https://btctranscripts.com/es/bitcoin-core-dev-tech/2018-03/2018-03-07-priorities/><meta name=robots content="noindex"><meta charset=utf-8><meta http-equiv=refresh content="0; url=https://btctranscripts.com/es/bitcoin-core-dev-tech/2018-03/2018-03-07-priorities/"></head></html> |
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
<?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 2018 (Mar) on ₿itcoin Transcripts</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/</link><description>Recent content in Bitcoin Core Dev Tech 2018 (Mar) on ₿itcoin Transcripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Wed, 07 Mar 2018 00:00:00 +0000</lastBuildDate><atom:link href="https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/index.xml" rel="self" type="application/rss+xml"/><item><title>Priorities</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/2018-03-07-priorities/</link><pubDate>Wed, 07 Mar 2018 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/2018-03-07-priorities/</guid><description>https://twitter.com/kanzure/status/972863994489901056 | ||
Priorities We&rsquo;re going to wait until BlueMatt is here. Nobody knows what his priorities are. He says he might be in around noon. | ||
There&rsquo;s an ex-Google product director interested in helping with Bitcoin Core. He was asking about how to get involved. I told him to get involved by just diving in. He will be spending some time at Chaincode at the end of March. We&rsquo;ll get a sense for what his skills are.</description></item><item><title>Merkleized Abstract Syntax Trees - MAST</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/2018-03-06-merkleized-abstract-syntax-trees-mast/</link><pubDate>Tue, 06 Mar 2018 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/2018-03-06-merkleized-abstract-syntax-trees-mast/</guid><description>https://twitter.com/kanzure/status/972120890279432192 | ||
See also http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2017-09-07-merkleized-abstract-syntax-trees/ | ||
MAST stuff You could directly merkleize scripts if you switch from IF, IFNOT, ELSE with IFJUMP that has the number of bytes. | ||
With graftroot and taproot, you never to do any scripts (which were a hack to get things started). But we&rsquo;re doing validation and computation. | ||
You take every single path it has; so instead, it becomes &hellip; certain condition, or certain not conditions&hellip; You take every possible ifs, you use this, you say it&rsquo;s one of these, then you specify which one, and you show it and everyone else can validate this.</description></item><item><title>Taproot, Graftroot, Etc</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/2018-03-06-taproot-graftroot-etc/</link><pubDate>Tue, 06 Mar 2018 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2018-03/2018-03-06-taproot-graftroot-etc/</guid><description>https://twitter.com/kanzure/status/972468121046061056 | ||
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&rsquo;s almost always true. Say you want to lock up these coins for a year, without any conditionals to it, then it doesn&rsquo;t work. But assume you have&ndash; pubkey recovery? No&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/ | ||
Bellare-Neven It&rsquo;s been published, it&rsquo;s been around for a decade, and it&rsquo;s widely cited. In Bellare-Neven, it&rsquo;s itself, it&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&rsquo;s paper suggests a trivial way of building an aggregate signature scheme out of a multisig scheme where interactively everyone signs everyone&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 | ||
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> |
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Large diffs are not rendered by default.
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,13 @@ | ||
<?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 2018 (Oct) on ₿itcoin Transcripts</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/</link><description>Recent content in Bitcoin Core Dev Tech 2018 (Oct) on ₿itcoin Transcripts</description><generator>Hugo -- gohugo.io</generator><language>en</language><lastBuildDate>Wed, 10 Oct 2018 00:00:00 +0000</lastBuildDate><atom:link href="https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/index.xml" rel="self" type="application/rss+xml"/><item><title>Signmessage</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/2018-10-10-signmessage/</link><pubDate>Wed, 10 Oct 2018 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/2018-10-10-signmessage/</guid><description>https://twitter.com/kanzure/status/1049834659306061829 | ||
signmessage kallewoof and others | ||
I am trying to make a new signmessage to do other things. Just use the signature system inside bitcoin to sign a message. Sign a message that someone wants. You can use proof-of-funds or whatever. | ||
You could just have a signature and it&rsquo;s a signature inside of a package and it&rsquo;s small and easy. Another option is to have a .. that is invalid somehow. You do a transaction with some input, where the txid is the message hash or something.</description></item><item><title>Bitcoin Optech</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/2018-10-09-bitcoin-optech/</link><pubDate>Tue, 09 Oct 2018 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/2018-10-09-bitcoin-optech/</guid><description>https://twitter.com/kanzure/status/1049527415767101440 | ||
Bitcoin Optech https://bitcoinops.org/ | ||
Bitcoin Optech is trying to encourage bitcoin businesses to adopt better scaling techniques and technologies, things like batching, segwit, down the line maybe Schnorr signatures, aggregatable signatures, maybe lightning. Right now we&rsquo;re focusing on things that businesses could be doing right now. Exchanges could be batching, and some aren&rsquo;t. We&rsquo;re talking to those companies and listening to their concerns and what they&rsquo;re doing, and just trying to nudge them in the right direction.</description></item><item><title>Wallet Stuff</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/2018-10-09-wallet-stuff/</link><pubDate>Tue, 09 Oct 2018 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/2018-10-09-wallet-stuff/</guid><description>https://twitter.com/kanzure/status/1049526667079643136 | ||
Wallet stuff Maybe we can have the wallet PRs have a different review process so that there can be some specialization, even if the wallet is not ready to be split out. In the future, if the wallet was a separate project or repository, then that would be better. We need to be able to subdivide the work better than we already do, and the wallet is a good place to start doing it.</description></item><item><title>Efficient P2P Transaction Relay</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/2018-10-08-efficient-p2p-transaction-relay/</link><pubDate>Mon, 08 Oct 2018 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/2018-10-08-efficient-p2p-transaction-relay/</guid><description>p2p transaction relay protocol improvements with set reconciliation gleb | ||
I don&rsquo;t know if I need to motivate this problem. I presented a work in progress session at Scaling. The cost of relaying transactions or announcing a transaction in a network&ndash; how many announcements do you have? Every link has an announcement in either direction right now, and then there&rsquo;s the number of nodes multiplied by the number of connections per node.</description></item><item><title>Script Descriptors</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/2018-10-08-script-descriptors/</link><pubDate>Mon, 08 Oct 2018 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/2018-10-08-script-descriptors/</guid><description>https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md | ||
I would like to talk about script descriptors. There&rsquo;s a number of projects we&rsquo;re working on and they are all kind of related. I&rsquo;d like to clarify how things fit together. | ||
Note: there is an earlier transcript that has not been published (needs review) about script descriptors. | ||
Agenda History of script descriptors and how we came to this. What&rsquo;s currently in Bitcoin Core v0.17 Wallet integration DESCRIPT About script descriptors The problem that I wanted to tackle was that currently in Bitcoin Core wallet we have a blob of public keys and private keys and HD chains and scripts and a bunch of other metadata and keypools.</description></item><item><title>Utxo Accumulators And Utreexo</title><link>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/2018-10-08-utxo-accumulators-and-utreexo/</link><pubDate>Mon, 08 Oct 2018 00:00:00 +0000</pubDate><guid>https://btctranscripts.com/bitcoin-core-dev-tech/2018-10/2018-10-08-utxo-accumulators-and-utreexo/</guid><description>UTXO accumulators, UTXO commitments, and utreexo | ||
https://twitter.com/kanzure/status/1049112390413897728 | ||
If people saw Benedikt&rsquo;s talk, two days ago, it&rsquo;s related. It&rsquo;s a different construction but same goal. The basic idea is, and I think Cory kind of started to talk about this a few months ago on the mailing list&hellip; instead of storing all UTXOs in leveldb, store the hash of each UTXO, and then it&rsquo;s half the size, and then you could almost create it from the hash of the input, it&rsquo;s like 10 bytes more.</description></item></channel></rss> |