Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]
On Mon, Jul 17, 2017 at 02:49:22PM -0400, Alex Morcos via bitcoin-dev wrote: > "it was ACKed by everyone else that I heard from" - I don't think you > should read into that much. > > I felt like this whole conversation was putting the cart before the horse. > You might very well have some good ideas in your roadmap update, to tell > you the truth, I didn't even read it. > But I don't think we should be taking relatively new/untested ideas such as > Drivechain and sticking them on a roadmap. There is a tendency in this > community to hear about the latest and greatest idea and immediately fixate > on it as our salvation. I'm very happy that you are doing this work and > that others are researching a wide variety of ideas. But please, lets be > conservative and flexible with how we evolve Bitcoin. We don't even know > if or when we'll get segwit yet. Agreed! A closely related example is my own Treechains work, which got a bunch of excitement when I first published the idea. But would I have wanted it on a roadmap? Hell no: sure enough, as it got more peer review others (and myself!) found that it was going to be a harder than it initially looked to actually get into production. Drivechains is definitely in that situation right now. Also don't forget that proper security peer review takes a *lot* of work. I myself have a todo list item to respond to Paul's post on Drivechains, but I need to spend a few days to do that and just haven't had the time (not to mention that no-one is paying me to do general Bitcoin dev work right now). -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: Digital signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]
On 7/17/2017 5:47 PM, David A. Harding wrote: > On Mon, Jul 17, 2017 at 01:13:30PM -0400, Paul Sztorc via bitcoin-dev wrote: >> However, without interest from the maintainers of bitcoincore.org >> (specifically these [3, 4] pages and similar) the document will probably >> be unable to gain traction. >> [...] >> [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/ >> [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/ > The BitcoinCore.org maintainers are not psychic. If you want your > document to appear on the website, please open a PR. If you would like > help formatting your document for the website, please feel free to send > me an email off list or open an issue[1] regarding the inadequacy of > the site's readme. I meant only to convey that the document would appear on bitcoincore.org iff the PR were ultimately accepted. In other words, while it is up to "the community of Core Contributors" in a philosophical sense, it is up to the maintainers of BitcoinCore.org in a practical sense, because they are the ones who ultimately decide if the standard has been met. I think it is perfectly reasonable to keep site-updates narrowly organized in the GitHub PR sphere (and to ignore everything else). > [1] https://github.com/bitcoin-core/bitcoincore.org/issues/new > > Speaking as the instigator of [3] and the primary author of [4] (both > originally published on Bitcoin.org), I'll point out that Maxwell's > reply to you was a slightly rewritten version of a reply to me sent on 4 > November 2016 (as noted elsewhere in the thread and confirmed in my > mailbox). I include below my signature a complete copy of my reply to > him (and CC'd to others). > > If I had followed through on my earlier plan to post a copy of Maxwell's > reply on BitcoinCore.org (assuming Bitcoin Core contributors supported > publishing it), you probably would've known that some Bitcoin Core > contributors were resistant to roadmaps prior to you writing your > proposed roadmap. For that failure, and the time you may have wasted > because of it, I offer you my apologies. I appreciate you saying that. Thank you. -Paul > I will make opening a PR to BitcoinCore.org with his statement a priority > so that hopefully future confusion can be avoided. > > Sincerely, > > -Dave > > On Fri, Nov 04, 2016 at 07:17:11PM +, Gregory Maxwell wrote: >> [...] > I just wanted to say that I thought this was an amazing reply. I was > hoping that if I waited long enough to respond I might find something > meaningful to add, but nothing has come to mind and I didn't want to > leave the impression that your reply didn't merit a response. > > Maybe we can find a place on the website to post something like this so > that we can link to it when other people ask for roadmaps and other > commitments to future plans. > > Thanks!, > > -Dave ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]
"it was ACKed by everyone else that I heard from" - I don't think you
should read into that much.
I felt like this whole conversation was putting the cart before the horse.
You might very well have some good ideas in your roadmap update, to tell
you the truth, I didn't even read it.
But I don't think we should be taking relatively new/untested ideas such as
Drivechain and sticking them on a roadmap. There is a tendency in this
community to hear about the latest and greatest idea and immediately fixate
on it as our salvation. I'm very happy that you are doing this work and
that others are researching a wide variety of ideas. But please, lets be
conservative and flexible with how we evolve Bitcoin. We don't even know
if or when we'll get segwit yet.
On Mon, Jul 17, 2017 at 1:13 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hello,
>
> Last week I posted about updating the Core Scalability Roadmap.
>
> I'm not sure what the future of it is, given that it was concept NACK'ed
> by Greg Maxwell the author of the original roadmap, who said that he
> regretted writing the first one.
>
> Nonetheless, it was ACKed by everyone else that I heard from, except for
> Tom Zander (who objected that it should be a specific project document,
> not a "Bitcoin" document -- I sortof agree and decided to label it a
> "Core" document -- whether or not anything happens with that label is up
> to the community).
>
> I therefore decided to:
> 1. Put the draft on GitHub [1]
> 2. Update it based on all of the week 1 feedback [2]
> 3. Add some spaces at the bottom for comments / expressions of interest [2]
>
> However, without interest from the maintainers of bitcoincore.org
> (specifically these [3, 4] pages and similar) the document will probably
> be unable to gain traction.
>
> Cheers,
> Paul
>
> [1] https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt
> [2]
> https://github.com/psztorc/btc-core-capacity-2/commit/
> 2b4f0ecc9015ee398ce0486ca5c3613e3b929c00
> [3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
> [4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
>
>
> On 7/10/2017 12:50 PM, Paul Sztorc wrote:
> > Summary
> > =
> >
> > In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
> > crucial ways. One success was that it synchronized the entire Bitcoin
> > community, helping to bring finality to the (endless) conversations of
> > that time, and get everyone back to work. However, I feel that the Dec
> > 7, 2015 roadmap is simply too old to serve this function any longer. We
> > should revise it: remove what has been accomplished, introduce new
> > innovations and approaches, and update deadlines and projections.
> >
> >
> > Why We Should Update the Roadmap
> > =
> >
> > In a P2P system like Bitcoin, we lack authoritative info-sources (for
> > example, a "textbook" or academic journal), and as a result
> > conversations tend to have a problematic lack of progress. They do not
> > "accumulate", as everyone must start over. Ironically, the scaling
> > conversation _itself_ has a fatal O(n^2) scaling problem.
> >
> > The roadmap helped solve these problems by being constant in size, and
> > subjecting itself to publication, endorsement, criticism, and so forth.
> > Despite the (unavoidable) nuance and complexity of each individual
> > opinion, it was at least globally known that X participants endorsed Y
> > set of claims.
> >
> > Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
> > obsolete and replacing it is long overdue. For example, it highlights
> > older items (CSV, compact blocks, versionbits) as being _future_
> > improvements, and makes no mention of new high-likelihood improvements
> > (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
> > fraud proofs). To read the old roadmap properly, one must already be a
> > technical expert. For me, this defeats the entire point of having one in
> > the first place.
> >
> > A new roadmap would be worth your attention, even if you didn't sign it,
> > because a refusal to sign would still be informative (and, therefore,
> > helpful)!
> >
> > So, with that in mind, let me present a first draft. Obviously, I am
> > strongly open to edits and feedback, because I have no way of knowing
> > everyone's opinions. I admit that I am partially campaigning for my
> > Drivechain project, and also for this "scalability"/"capacity"
> > distinction...that's because I believe in both and think they are
> > helpful. But please feel free to suggest edits.
> >
> > I emphasized concrete numbers, and concrete dates.
> >
> > And I did NOT necessarily write it from my own point of view, I tried
> > earnestly to capture a (useful) community view. So, let me know how I
> did.
> >
> > Beginning of New ("July 2017") Roadmap Draft
> >
> > This document updates the previous roadmap [1] of Dec 2015. The older
> >
Re: [bitcoin-dev] Updating the Scaling Roadmap [Update]
Hello,
Last week I posted about updating the Core Scalability Roadmap.
I'm not sure what the future of it is, given that it was concept NACK'ed
by Greg Maxwell the author of the original roadmap, who said that he
regretted writing the first one.
Nonetheless, it was ACKed by everyone else that I heard from, except for
Tom Zander (who objected that it should be a specific project document,
not a "Bitcoin" document -- I sortof agree and decided to label it a
"Core" document -- whether or not anything happens with that label is up
to the community).
I therefore decided to:
1. Put the draft on GitHub [1]
2. Update it based on all of the week 1 feedback [2]
3. Add some spaces at the bottom for comments / expressions of interest [2]
However, without interest from the maintainers of bitcoincore.org
(specifically these [3, 4] pages and similar) the document will probably
be unable to gain traction.
Cheers,
Paul
[1] https://github.com/psztorc/btc-core-capacity-2/blob/master/draft.txt
[2]
https://github.com/psztorc/btc-core-capacity-2/commit/2b4f0ecc9015ee398ce0486ca5c3613e3b929c00
[3] https://bitcoincore.org/en/2015/12/21/capacity-increase/
[4] https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/
On 7/10/2017 12:50 PM, Paul Sztorc wrote:
> Summary
> =
>
> In my opinion, Greg Maxwell's scaling roadmap [1] succeeded in a few
> crucial ways. One success was that it synchronized the entire Bitcoin
> community, helping to bring finality to the (endless) conversations of
> that time, and get everyone back to work. However, I feel that the Dec
> 7, 2015 roadmap is simply too old to serve this function any longer. We
> should revise it: remove what has been accomplished, introduce new
> innovations and approaches, and update deadlines and projections.
>
>
> Why We Should Update the Roadmap
> =
>
> In a P2P system like Bitcoin, we lack authoritative info-sources (for
> example, a "textbook" or academic journal), and as a result
> conversations tend to have a problematic lack of progress. They do not
> "accumulate", as everyone must start over. Ironically, the scaling
> conversation _itself_ has a fatal O(n^2) scaling problem.
>
> The roadmap helped solve these problems by being constant in size, and
> subjecting itself to publication, endorsement, criticism, and so forth.
> Despite the (unavoidable) nuance and complexity of each individual
> opinion, it was at least globally known that X participants endorsed Y
> set of claims.
>
> Unfortunately, the Dec 2015 roadmap is now 19 months old -- it is quite
> obsolete and replacing it is long overdue. For example, it highlights
> older items (CSV, compact blocks, versionbits) as being _future_
> improvements, and makes no mention of new high-likelihood improvements
> (Schnorr) or mis-emphasizes them (LN). It even contains mistakes (SegWit
> fraud proofs). To read the old roadmap properly, one must already be a
> technical expert. For me, this defeats the entire point of having one in
> the first place.
>
> A new roadmap would be worth your attention, even if you didn't sign it,
> because a refusal to sign would still be informative (and, therefore,
> helpful)!
>
> So, with that in mind, let me present a first draft. Obviously, I am
> strongly open to edits and feedback, because I have no way of knowing
> everyone's opinions. I admit that I am partially campaigning for my
> Drivechain project, and also for this "scalability"/"capacity"
> distinction...that's because I believe in both and think they are
> helpful. But please feel free to suggest edits.
>
> I emphasized concrete numbers, and concrete dates.
>
> And I did NOT necessarily write it from my own point of view, I tried
> earnestly to capture a (useful) community view. So, let me know how I did.
>
> Beginning of New ("July 2017") Roadmap Draft
>
> This document updates the previous roadmap [1] of Dec 2015. The older
> statement endorsed a belief that "the community is ready to deliver on
> its shared vision that addresses the needs of the system while upholding
> its values".
>
> That belief has not changed, but the shared vision has certainly grown
> sharper over the last 18 months. Below is a list of technologies which
> either increase Bitcoin's maximum tps rate ("capacity"), or which make
> it easier to process a higher volume of transactions ("scalability").
>
> First, over the past 18 months, the technical community has completed a
> number of items [2] on the Dec 2015 roadmap. VersonBits (BIP 9) enables
> Bitcoin to handle multiple soft fork upgrades at once. Compact Blocks
> (BIP 152) allows for much faster block propagation, as does the FIBRE
> Network [3]. Check Sequence Verify (BIP 112) allows trading partners to
> mutually update an active transaction without writing it to the
> blockchain (this helps to enable the Lightning Network).
>
> Second, Segregated Witness (BIP 141), which reorganizes data in blocks
> to handle signatures separately,
Re: [bitcoin-dev] A BIP proposal for conveniently referring to confirmed transactions
On Friday, 14 July 2017 20:43:37 CEST Clark Moody via bitcoin-dev wrote: > I can understand the desire to keep all reference strings to the nice > 14-character version by keeping the data payload to 40 bits I’m not so clear on this, to be honest. What is the point of having a user-readable tx-reference? In the actual blockchain you will still be using txid, and if you want to change that then a less readable but more compact format is useful because we want to optimize for space, not for human comprehention. Another usecase I can come up with is you wanting to spend a specific output, or you reporting a specific tx as proof to a merchant (or tax office). For any such usecases you sill need to actually provide a proof of holding the private keys and using a human-readable format just doesn’t seem to make much sense because a cryptographic proof of ownership is not going to be readable however hard you try. Apologies for missing the point, can you list one or two usecases that you can see this being used for? -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
