diff options
8 files changed, 9 insertions, 9 deletions
diff --git a/transcripts/adam3us-bitcoin-scaling-tradeoffs.mdwn b/transcripts/adam3us-bitcoin-scaling-tradeoffs.mdwn index 46eaed5..080c8b3 100644 --- a/transcripts/adam3us-bitcoin-scaling-tradeoffs.mdwn +++ b/transcripts/adam3us-bitcoin-scaling-tradeoffs.mdwn @@ -66,7 +66,7 @@ Next I wanted to talk about upgrade methods. There are a number of different tec <https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki> -But let's have that discussion now anyway. People are probably familiar with soft-forks and hard-forks. There are [some different bitcoin upgrade method variants](http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012173.html) and some have had more recent analysis to talk about. People are still learning new things about bitcoin. There are people who understand code, but the implications of the protocol and the ways that you can extend it and upgrade it, are still new realizations and understandings are being found. That's the topic of ongoing learning even amongst Bitcoin developers and so on. +But let's have that discussion now anyway. People are probably familiar with soft-forks and hard-forks. There are [some different bitcoin upgrade method variants](https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012173.html) and some have had more recent analysis to talk about. People are still learning new things about bitcoin. There are people who understand code, but the implications of the protocol and the ways that you can extend it and upgrade it, are still new realizations and understandings are being found. That's the topic of ongoing learning even amongst Bitcoin developers and so on. An example of that is a "firm fork" or "soft hard-fork", which has been talked about recently. It was quite obscure or not widely understood or known before. Let's talk about the tradeoffs. Backwards compatibility meaning that the existing bitcoin wallets that are in use today will they be able to still send transactions after the upgrade? One of the texts is wrong, this is should be a tic not a cross. A soft-fork is backwards compatible because existing wallets can pay to new wallets and new wallets can pay to old wallets. Full hard-forks are not backwards compatible, by design they change the formats to improve something fundamental. All clients, even smartphone clients, even full node clients, have to upgrade after a full hard-fork. A simple hard-fork is a restricted hard-fork that smartphone clients don't have to upgrade with. The firm hard-fork is a kind of hybrid between the two, which we will talk about in a moment. diff --git a/transcripts/mit-bitcoin-expo-2017/scaling-and-utxos.mdwn b/transcripts/mit-bitcoin-expo-2017/scaling-and-utxos.mdwn index 8f956d1..20c5f3d 100644 --- a/transcripts/mit-bitcoin-expo-2017/scaling-and-utxos.mdwn +++ b/transcripts/mit-bitcoin-expo-2017/scaling-and-utxos.mdwn @@ -46,6 +46,6 @@ I setup some nodes on scaleway and it took about 5 days for them to get started. <https://s3.amazonaws.com/peter.todd/bitcoin-wizards-13-10-17.log> -<http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003714.html> +<https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2013-November/003714.html> <http://gnusha.org/bitcoin-wizards/2015-09-18.log> diff --git a/transcripts/scalingbitcoin/blockchain-testbed.mdwn b/transcripts/scalingbitcoin/blockchain-testbed.mdwn index e73512a..11bfd1a 100644 --- a/transcripts/scalingbitcoin/blockchain-testbed.mdwn +++ b/transcripts/scalingbitcoin/blockchain-testbed.mdwn @@ -50,6 +50,6 @@ You need clear metrics, you need to run the actual code, you need to emulate the Adem Efe Gencer, Emin Gun Sirer, Robbert Van Renesse, Ittay Eyal. -bitcoin-ng criticism <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011528.html> +bitcoin-ng criticism <https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011528.html> see also <http://gnusha.org/bitcoin-wizards/2015-10-14.log> and <http://gnusha.org/bitcoin-wizards/2015-09-19.log> diff --git a/transcripts/scalingbitcoin/hong-kong/invertible-bloom-lookup-tables-and-weak-block-propagation-performance.mdwn b/transcripts/scalingbitcoin/hong-kong/invertible-bloom-lookup-tables-and-weak-block-propagation-performance.mdwn index 3b98a1d..f170ba1 100644 --- a/transcripts/scalingbitcoin/hong-kong/invertible-bloom-lookup-tables-and-weak-block-propagation-performance.mdwn +++ b/transcripts/scalingbitcoin/hong-kong/invertible-bloom-lookup-tables-and-weak-block-propagation-performance.mdwn @@ -90,6 +90,6 @@ gavinandresen IBLT proposal <https://gist.github.com/gavinandresen/e20c3b5a1d4b9 IBLT stuff from montreal workshop <http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/> -weak blocks proposal <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011707.html> and some minor follow-up at <http://gnusha.org/bitcoin-wizards/2015-12-02.log> +weak blocks proposal <https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011707.html> and some minor follow-up at <http://gnusha.org/bitcoin-wizards/2015-12-02.log> -various links about weak blocks <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011158.html> +various links about weak blocks <https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/011158.html> diff --git a/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning.mdwn b/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning.mdwn index e5c17a5..9288094 100644 --- a/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning.mdwn +++ b/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning.mdwn @@ -12,7 +12,7 @@ I think that's a good tradeoff. But how much can this get us? What do we need in order to get this? Can Lightning work today? Well, check back nextweek. [bip65](https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki) is going to be active pretty soon. bip65 is not sufficient, but it's necessary. We need relative timelocks, and the ability to reliably spend from an unconfirmed transaction, which segregated witness allows. OP\_CLTV is almost active. OP\_CSV ([bip112](https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki)) is maybe soon. -There are levels of lightning that we are prepared to accept. If we never get segregated witness, if we never get checksequenceverify, we can still use lightning, it just wont be as good. Channels can work with only OP\_CLTV (checklocktimeverify), but it's much less efficient ((see [here](http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000310.html) for why segregated witness is useful for lightning)). This could be ready to go next week. +There are levels of lightning that we are prepared to accept. If we never get segregated witness, if we never get checksequenceverify, we can still use lightning, it just wont be as good. Channels can work with only OP\_CLTV (checklocktimeverify), but it's much less efficient ((see [here](https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000310.html) for why segregated witness is useful for lightning)). This could be ready to go next week. With Lightning Network level 1, you need 1.25 MB/user/year. With Lightning Network level 3, you need 3 KB/user/year. diff --git a/transcripts/scalingbitcoin/milan/jute-braiding.mdwn b/transcripts/scalingbitcoin/milan/jute-braiding.mdwn index e27b8ea..f5db04c 100644 --- a/transcripts/scalingbitcoin/milan/jute-braiding.mdwn +++ b/transcripts/scalingbitcoin/milan/jute-braiding.mdwn @@ -102,7 +102,7 @@ A: ... miners can randomly select transactions and not have conflicts. Your tran jute <https://gist.github.com/Taek42/3e4f029261b5719e4587fe4972fb904a> -weak blocks <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011707.html> +weak blocks <https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011707.html> <http://blog.sia.tech/2016/05/14/towards-a-sub-second-block-size/> diff --git a/transcripts/scalingbitcoin/transaction-fee-estimation.mdwn b/transcripts/scalingbitcoin/transaction-fee-estimation.mdwn index 006fd44..0ae1212 100644 --- a/transcripts/scalingbitcoin/transaction-fee-estimation.mdwn +++ b/transcripts/scalingbitcoin/transaction-fee-estimation.mdwn @@ -33,7 +33,7 @@ That's the basics of how I think wallets should handle transaction fees. --- -<http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011685.html> +<https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011685.html> <https://medium.com/@bramcohen/how-wallets-can-handle-transaction-fees-ff5d020d14fb> diff --git a/transcripts/sf-bitcoin-meetup/2016-11-21-mimblewimble.mdwn b/transcripts/sf-bitcoin-meetup/2016-11-21-mimblewimble.mdwn index ca6715f..abc43b6 100644 --- a/transcripts/sf-bitcoin-meetup/2016-11-21-mimblewimble.mdwn +++ b/transcripts/sf-bitcoin-meetup/2016-11-21-mimblewimble.mdwn @@ -22,7 +22,7 @@ Over the next couple weeks, this project continued. There were even more Harry P # What is mimblewimble? -So in all this history, maybe I should explain what I'm talking about. Mimblewimble is a design for a blockchain-based ledger. It's basically a replacement for the bitcoin blockchain. It's a proposal for a bitcoin-like blockchain which could be implemented as a sidechain where you have a completely separate chain and you could move bitcoins into it and bitcoins out of it, it's separate. Or potentially in the far future where we have tested and proven this technology, we could potentially soft-fork this into bitcoin itself as some sort of <a href="http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012173.html">extension block scheme</a>, which would basically be like a sidechain that is integrated into the system. +So in all this history, maybe I should explain what I'm talking about. Mimblewimble is a design for a blockchain-based ledger. It's basically a replacement for the bitcoin blockchain. It's a proposal for a bitcoin-like blockchain which could be implemented as a sidechain where you have a completely separate chain and you could move bitcoins into it and bitcoins out of it, it's separate. Or potentially in the far future where we have tested and proven this technology, we could potentially soft-fork this into bitcoin itself as some sort of <a href="https://gnusha.org/url/https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012173.html">extension block scheme</a>, which would basically be like a sidechain that is integrated into the system. Where mimblewimble diffles from bitcoin is that rather than having inputs sign the entire transaction, like in bitcoin where you have a pile of inputs and a pile of outputs and every input has a key associated with it and it has to have a signature for a transaction with that key. In mimblewimble, this model is changed. Rather than having each input sign the transaction, you sort of create a multisig across all inputs and all outputs. If you take the sum of all the keys on all the outputs, minus the sum of all the input keys, you get an elliptic curve point which you can treat as a public key and what that public key represents is a multisignature public key for all the transacting parties, the owner of every input and the owner of every output. And so a signature on this represents that the transaction was authorized by everybody involved, roughly. |