Nostr notes by

📅 Original date posted:2021-02-19 📝 Original ...

2023-06-07T20:28:54+02:00

In reply to nevent1q…vcq5
_________________________

📅 Original date posted:2021-02-19
📝 Original message:Personally I don't really have much of a view and think either
LOT=true or false is better in the context, they both seem safe given
the current context, where basically everyone is saying "are we there
yet", including pools (88.7% going out of their way to say YES
https://taprootactivation.com). Not that pools are deciding of
anything, being service providers to miners, who can and will switch
pool fast, and miners in-turn being service providers to the market
and as the various forks showed will follow the market.

I think it's a very good idea for safety, if there is a tested and
reviewed code with an option to force LOT=true, even if the
bitcoin-core implementation ends up defaulting to LOT=false.

Part of the danger is rushed versions of things like BIP 91 to avoid a
chain split where miners left brinkmanship just a bit too late, to
avert BIP 148 forking, and BIP 91 was used to expedite activation to
avoid that. The rushed proposal, code, review, ship cycle on that was
dangerously fast - less time and eyes for review was the danger.

> would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?

given there are clearly people of both views, or for now don't care
but might later, it would minimally be friendly and useful if
bitcoin-core has a LOT=true option - and that IMO goes some way to
avoid the assumptive control via defaults.

Otherwise it could be read as saying "developers on average
disapprove, but if you, the market disagree, go figure it out for
yourself" which is not a good message for being defensive and avoiding
mis-interpretation of code repositories or shipped defaults as
"control".

Adam

On Fri, 19 Feb 2021 at 11:30, ZmnSCPxj via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Good morning list,
>
> > This is absolutely the case, however note that the activation method itself is consensus code which executes as a part
> > of a fork, and one which deserves as much scrutiny as anything else. While taproot is a model of how a soft-fork should
> > be designed, this doesn't imply anything about the consensus code which represents the activation thereof.
> >
> > Hence all the debate around activation - ultimately its also defining a fork, and given the politics around it, one
> > which almost certainly carries significantly more risk than Taproot.
> >
> > Note that I don't believe anyone is advocating for "try to activate, and if it fails, move on". Various people have
> > various views on how conservative and timelines for what to do at that point, but I believe most in this discussion are
> > OK with flag-day-based activation (given some level of care) if it becomes clear Taproot is supported by a vast majority
> > of Bitcoin users and is only not activating due to lagging miner upgrades.
>
>
> Okay, I am backing off this proposal to force the LOT=false/true decision on users, it was not particularly serious anyway (and was more a reaction to the request of Samson Mow to just release both versions, which to my mind is no different from such a thing).
>
>
> Nonetheless, as a thought experiment: the main issue is that some number of people run LOT=true when miners do not activate Taproot early for some reason and we decide to leave LOT=false for this particular bit until it times out.
> The issue is that those people will get forked off the network at the end of this particular deployment attempt.
>
> I suspect those people will still exist whether or not Bitcoin Core supports any kind of LOT=true mode.
> ("Never again" for some people)
>
> How do we convince them to go run LOT=false instead of getting themselves forked off?
> Or do we simply let them?
>
> (and how is that different from asking each user to decide on LOT=false/true right now?)
> ("reasonable default"?)
> (fundamentally speaking you still have to educate the users on the ramifications of accepting the default and changing it.)
>
>
> Another thought experiment: From the point of view of a user who strongly supports LOT=true, would dev consensus around releasing LOT=false be considered as "developers forcing their views on users"?
> Why or why not?
>
>
> Regards,
> ZmnSCPxj
>
> > Matt
> >
> > On 2/18/21 10:04, Keagan McClelland wrote:
> >
> > > Hi all,
> > > I think it's important for us to consider what is actually being considered for activation here.
> > > The designation of "soft fork" is accurate but I don't think it adequately conveys how non-intrusive a change like this
> > > is. All that taproot does (unless I'm completely missing something) is imbue a previously undefined script version with
> > > actual semantics. In order for a chain reorg to take place it would mean that someone would have to have a use case for
> > > that script version today. This is something I think that we can easily check by digging through the UTXO set or
> > > history. If anyone is using that script version, we absolutely should not be using it, but that doesn't mean that we
> > > can't switch to a script version that no one is actually using.
> > > If no one is even attempting to use the script version, then the change has no effect on whether a chain split occurs
> > > because there is simply no block that contains a transaction that only some of the network will accept.
> > > Furthermore, I don't know how Bitcoin can stand the test of time if we allow developers who rely on "undefined behavior"
> > > (which the taproot script version presently is) to exert tremendous influence over what code does or does not get run.
> > > This isn't a soft fork that makes some particular UTXO's unspendable. It isn't one that bans miners from collecting
> > > fees. It is a change that means that certain "always accept" transactions actually have real conditions you have to
> > > meet. I can't imagine a less intrusive change.
> > > On the other hand, choosing to let L=F be a somewhat final call sets a very real precedent that 10% of what I estimate
> > > to be 1% of bitcoin users can effectively block any change from here on forward. At that point we are saying that miners
> > > are in control of network consensus in ways they have not been up until now. I don't think this is a more desirable
> > > outcome to let ~0.1% of the network get to block /non-intrusive/ changes that the rest of the network wants.
> > > I can certainly live with an L=F attempt as a way to punt on the discussion, maybe the activation happens and this will
> > > all be fine. But if it doesn't, I hardly think that users of Bitcoin are just going to be like "well, guess that's it
> > > for Taproot". I have no idea what ensues at that point, but probably another community led UASF movement.
> > > I wasn't super well educated on this stuff back in '17 when Segwit went down, as I was new at that time, so if I'm
> > > missing something please say so. But from my point of view, we can't treat all soft forks as equal.
> > > Keagan
> > > On Thu, Feb 18, 2021 at 7:43 AM Matt Corallo via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> > > mailto:bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >
> > > We've had several softforks in Bitcoin which, through the course of their activation, had a several-block reorg. That
> > > should be indication enough that we need to very carefully consider activation to ensure we reduce the risk of that as
> > > much as absolutely possible. Again, while I think Taproot is a huge improvement and am looking forward to being able to
> > > use it, getting unlucky and hitting a 4-block reorg that happens to include a double-spend and some PR around an
> > > exchange losing millions would be worse than having Taproot is good.
> > >
> > > Matt
> > >
> > > On 2/18/21 09:26, Michael Folkson wrote:
> > > > Thanks for your response Matt. It is a fair challenge. There is always going to be an element of risk with soft
> > > forks,
> > > > all we can do is attempt to minimize that risk. I would argue that risk has been minimized for Taproot.
> > > >
> > > > You know (better than I do in fact) that Bitcoin (and layers built on top of it) greatly benefit from upgrades
> > > such as
> > > > Taproot. To say we shouldn't do Taproot or any future soft forks because there is a small but real risk of chain
> > > splits
> > > > I think is shortsighted. Indeed I think even if we collectively decided not to do any future soft fork upgrades ever
> > > > again on this mailing list that wouldn't stop soft fork attempts from other people in future.
> > > >
> > > > I don't think there is anything else we can do to minimize that risk for the Taproot soft fork at this point
> > > though I'm
> > > > open to ideas. To reiterate that risk will never be zero. I don't think I see Bitcoin as fragile as you seem to
> > > (though
> > > > admittedly you have a much better understanding than me of what happened in 2017).
> > > >
> > > > The likely scenario for the Taproot soft fork is LOT turns out to be entirely irrelevant and miners activate Taproot
> > > > before it becomes relevant. And even the unlikely worst case scenario would only cause short term disruption and
> > > > wouldn't kill Bitcoin long term.
> > > >
> > > > On Thu, Feb 18, 2021 at 2:01 PM Matt Corallo <lf-lists at mattcorallo.com <mailto:lf-lists at mattcorallo.com>
> > > <mailto:lf-lists at mattcorallo.com <mailto:lf-lists at mattcorallo.com>>> wrote:
> > > >
> > > > If the eventual outcome is that different implementations (that have material *transaction processing* userbases,
> > > > and I’m not sure to what extent that’s true with Knots) ship different consensus rules, we should stop here
> > > and not
> > > > activate Taproot. Seriously.
> > > >
> > > > Bitcoin is a consensus system. The absolute worst outcome at all possible is to have it fall out of consensus.
> > > >
> > > > Matt
> > > >
> > > >> On Feb 18, 2021, at 08:11, Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> > > <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>> wrote:
> > > >>
> > > >>
> > > >> Right, that is one option. Personally I would prefer a Bitcoin Core release sets LOT=false (based on what I have
> > > >> heard from Bitcoin Core contributors) and a community effort releases a version with LOT=true. I don't think
> > > users
> > > >> should be forced to choose something they may have no context on before they are allowed to use Bitcoin Core.
> > > >>
> > > >> My current understanding is that roasbeef is planning to set LOT=false on btcd (an alternative protocol
> > > >> implementation to Bitcoin Core) and Luke Dashjr hasn't yet decided on Bitcoin Knots.
> > > >>
> > > >>
> > > >>
> > > >> On Thu, Feb 18, 2021 at 11:52 AM ZmnSCPxj <ZmnSCPxj at protonmail.com <mailto:ZmnSCPxj at protonmail.com>
> > > <mailto:ZmnSCPxj at protonmail.com <mailto:ZmnSCPxj at protonmail.com>>> wrote:
> > > >>
> > > >> Good morning all,
> > > >>
> > > >> > "An activation mechanism is a consensus change like any other change, can be contentious like any other
> > > >> change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline."
> > > >> >
> > > >> > Who's we here?
> > > >> >
> > > >> > Release both and let the network decide.
> > > >>
> > > >> A thing that could be done, without mandating either LOT=true or LOT=false, would be to have a release that
> > > >> requires a `taprootlot=1` or `taprootlot=0` and refuses to start if the parameter is not set.
> > > >>
> > > >> This assures everyone that neither choice is being forced on users, and instead what is being forced on
> > > users,
> > > >> is for users to make that choice themselves.
> > > >>
> > > >> Regards,
> > > >> ZmnSCPxj
> > > >>
> > > >> >
> > > >> > On Thu, Feb 18, 2021 at 3:08 AM Michael Folkson via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org
> > > <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>> wrote:
> > > >> >
> > > >> > > Thanks for your response Ariel. It would be useful if you responded to specific points I have made
> > > in the
> > > >> mailing list post or at least quote these ephemeral "people" you speak of. I don't know if you're responding
> > > >> to conversation on the IRC channel or on social media etc.
> > > >> > >
> > > >> > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
> > > into
> > > >> code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
> > > >> must or must not run.
> > > >> > >
> > > >> > > I personally have never made this assumption. Of course users aren't forced to run any particular
> > > software
> > > >> version, quite the opposite. Defaults set in software versions matter though as many users won't change
> > > them.
> > > >> > >
> > > >> > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
> > > only a
> > > >> handful of people that begin running it while everyone else delays their upgrade (with the very good
> > > reason of
> > > >> not getting involved in politics) and a year later those handful of people just become stuck at the
> > > moment of
> > > >> MUST_SIGNAL, unable to mine new blocks?
> > > >> > >
> > > >> > > It is a possible outcome but the likely outcome is that miners activate Taproot before LOT is even
> > > >> relevant. I think it is prudent to prepare for the unlikely but possible outcome that miners fail to
> > > activate
> > > >> and hence have this discussion now rather than be unprepared for that eventuality. If LOT is set to
> > > false in a
> > > >> software release there is the possibility (T2 in
> > > >> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>;
> > > >> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>;) of individuals or a
> > > >> proportion of the community changing LOT to true. In that sense setting LOT=false in a software release
> > > >> appears to be no more safe than LOT=true.
> > > >> > >
> > > >> > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
> > > miners
> > > >> by default.
> > > >> > >
> > > >> > > There is the (unlikely but possible) possibility of a wasted year if LOT is set to false and miners fail
> > > >> to activate. I'm not convinced by this perception that LOT=true is antagonistic to miners. I actually
> > > think it
> > > >> offers them clarity on what will happen over a year time period and removes the need for coordinated or
> > > >> uncoordinated community UASF efforts on top of LOT=false.
> > > >> > >
> > > >> > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
> > > >> change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
> > > >> > >
> > > >> > > I don't know what you are recommending here to avoid "this darkest timeline". Open discussions have
> > > >> occurred and are continuing and in my mailing list post that you responded to **I recommended we propose
> > > >> LOT=false be set in protocol implementations such as Bitcoin Core**. I do think this apocalyptic language
> > > >> isn't particularly helpful. In an open consensus system discussion is healthy, we should prepare for bad or
> > > >> worst case scenarios in advance and doing so is not antagonistic or destructive. Mining pools have pledged
> > > >> support for Taproot but we don't build secure systems based on pledges of support, we build them to minimize
> > > >> trust in any human actors. We can be grateful that people like Alejandro have worked hard on
> > > >> taprootactivation.com <http://taprootactivation.com>; <http://taprootactivation.com
> > > <http://taprootactivation.com>>; (and this effort has informed the discussion) without
> > > >> taking pledges of support as cast iron guarantees.
> > > >> > >
> > > >> > > TL;DR It sounds like you agree with my recommendation to set LOT=false in protocol implementations in my
> > > >> email :)
> > > >> > >
> > > >> > > On Thu, Feb 18, 2021 at 5:43 AM Ariel Lorenzo-Luaces <arielluaces at gmail.com
> > > <mailto:arielluaces at gmail.com>
> > > >> <mailto:arielluaces at gmail.com <mailto:arielluaces at gmail.com>>> wrote:
> > > >> > >
> > > >> > > > Something what strikes me about the conversation is the emotion surrounding the letters UASF.
> > > >> > > > It appears as if people discuss UASF as if it's a massive tidal wave of support that is
> > > inevitable, like
> > > >> we saw during segwit activation. But the actual definition is "any activation that is not a MASF".
> > > >> > > > A UASF can consist of a single node, ten nodes, a thousand, half of all nodes, all business' nodes, or
> > > >> even all the non mining nodes. On another dimension it can have zero mining support, 51% support, 49%
> > > support,
> > > >> or any support right up against a miner activation threshold.
> > > >> > > > Hell a UASF doesn't even need code or even a single node running as long as it exists as a possibility
> > > >> in people's minds.
> > > >> > > > The only thing a UASF doesn't have is miner support above an agreed activation threshold (some number
> > > >> above %51).
> > > >> > > > I say this because it strikes me when people say that they are for LOT=true with the logic that
> > > since a
> > > >> UASF is guaranteed to happen then it's better to just make it default from the beginning. Words like
> > > >> coordination and safety are sometimes sprinkled into the argument.
> > > >> > > > The argument comes from a naive assumption that users MUST upgrade to the choice that is submitted
> > > into
> > > >> code. But in fact this isn't true and some voices in this discussion need to be more humble about what users
> > > >> must or must not run.
> > > >> > > > Does no one realize that it is a very possible outcome that if LOT=true is released there may be
> > > only a
> > > >> handful of people that begin running it while everyone else delays their upgrade (with the very good
> > > reason of
> > > >> not getting involved in politics) and a year later those handful of people just become stuck at the
> > > moment of
> > > >> MUST_SIGNAL, unable to mine new blocks? Or attracting a minority of miners, activating, and forking off
> > > into a
> > > >> minority fork. Then a lot=false could be started that ends up activating the feature now that the stubborn
> > > >> option has ran its course.
> > > >> > > > The result: a wasted year of waiting and a minority of people who didn't want to be lenient with
> > > miners
> > > >> by default. The chains could be called BitcoinLenient and BitcoinStubborn.
> > > >> > > > How is that strictly safer or more coordinated?
> > > >> > > > I may be in the minority, or maybe a silent majority, or maybe a majority that just hasn't considered
> > > >> this as a choice but honestly if there is contention about whether we're going to be stubborn or lenient
> > > with
> > > >> miners for Taproot and in the future then I prefer to just not activate anything at all. I'm fine for
> > > calling
> > > >> bitcoin ossified, accepting that segwit is Bitcoin's last network upgrade. Taproot is amazing but no new
> > > >> feature is worth a network split down the middle.
> > > >> > > > Maybe in 10 or 20 years, when other blockchains implement features like Taproot and many more, we will
> > > >> become envious enough to put aside our differences on how to behave towards miners and finally activate
> > > Taproot.
> > > >> > > > An activation mechanism is a consensus change like any other change, can be contentious like any other
> > > >> change, and we must resolve it like any other change. Otherwise we risk arriving at the darkest timeline.
> > > >> > > > Cheers
> > > >> > > > Ariel Lorenzo-Luaces
> > > >> > > > On Feb 17, 2021, at 7:05 AM, Michael Folkson via bitcoin-dev
> > > <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > >> <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>> wrote:
> > > >> > > >
> > > >> > > > > Yesterday (February 16th) we held a second meeting on Taproot
> > > >> > > > > activation on IRC which again was open to all. Despite what appeared
> > > >> > > > > to be majority support for LOT=false over LOT=true in the first
> > > >> > > > > meeting I (and others) thought the arguments had not been explored in
> > > >> > > > > depth and that we should have a follow up meeting almost entirely
> > > >> > > > > focused on whether LOT (lockinontimeout) should be set to true or
> > > >> > > > > false.
> > > >> > > > >
> > > >> > > > > The meeting was announced here:
> > > >> > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>;
> > > >> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html
> > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018380.html>>;
> > > >> > > > >
> > > >> > > > > In that mailing list post I outlined the arguments for LOT=true (T1 to
> > > >> > > > > T6) and arguments for LOT=false (F1 to F6) in their strongest form I
> > > >> > > > > could. David Harding responded with an additional argument for
> > > >> > > > > LOT=false (F7) here:
> > > >> > > > > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
> > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>;
> > > >> <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html
> > > <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/018415.html>>;
> > > >> > > > >
> > > >> > > > > These meetings are very challenging given they are open to all, you
> > > >> > > > > don’t know who will attend and you don’t know most people’s views in
> > > >> > > > > advance. I tried to give time for both the LOT=true arguments and the
> > > >> > > > > LOT=false arguments to be discussed as I knew there was support for
> > > >> > > > > both. We only tried evaluating which had more support and which had
> > > >> > > > > more strong opposition towards the end of the meeting.
> > > >> > > > >
> > > >> > > > > The conversation log is here:
> > > >> > > > > http://gnusha.org/taproot-activation/2021-02-16.log
> > > <http://gnusha.org/taproot-activation/2021-02-16.log>; <http://gnusha.org/taproot-activation/2021-02-16.log
> > > <http://gnusha.org/taproot-activation/2021-02-16.log>>;
> > > >> > > > >
> > > >> > > > > (If you are so inclined you can watch a video of the meeting here.
> > > >> > > > > Thanks to the YouTube account “Bitcoin” for setting up the livestream:
> > > >> > > > > https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>;
> > > <https://www.youtube.com/watch?v=vpl5q1ovMLM <https://www.youtube.com/watch?v=vpl5q1ovMLM>>;)
> > > >> > > > >
> > > >> > > > > A summary of the meeting was provided by Luke Dashjr on Mastodon here:
> > > >> > > > > https://bitcoinhackers.org/@lukedashjr/105742918779234566
> > > <https://bitcoinhackers.org/@lukedashjr/105742918779234566>;
> > > >> <https://bitcoinhackers.org/@lukedashjr/105742918779234566
> > > <https://bitcoinhackers.org/@lukedashjr/105742918779234566>>;
> > > >> > > > >
> > > >> > > > > Today's #Bitcoin #Taproot meeting was IMO largely unproductive, but we
> > > >> > > > > did manage to come to consensus on everything but LockinOnTimeout.
> > > >> > > > >
> > > >> > > > > Activation height range: 693504-745920
> > > >> > > > >
> > > >> > > > > MASF threshold: 1815/2016 blocks (90%)
> > > >> > > > >
> > > >> > > > > Keep in mind only ~100 people showed for the meetings, hardly
> > > >> > > > > representative of the entire community.
> > > >> > > > >
> > > >> > > > > So, these details remain JUST a proposal for now.
> > > >> > > > >
> > > >> > > > > It seems inevitable that there won't be consensus on LOT.
> > > >> > > > >
> > > >> > > > > Everyone will have to choose for himself. :/
> > > >> > > > >
> > > >> > > > > Personally I agree with most of this. I agree that there wasn’t
> > > >> > > > > overwhelming consensus for either LOT=true or LOT=false. However, from
> > > >> > > > > my perspective there was clearly more strong opposition (what would
> > > >> > > > > usually be deemed a NACK in Bitcoin Core review terminology) from
> > > >> > > > > Bitcoin Core contributors, Lightning developers and other community
> > > >> > > > > members against LOT=true than there was for LOT=false. Andrew Chow
> > > >> > > > > tried to summarize views from the meeting in this analysis:
> > > >> > > > > https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
> > > <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>;
> > > >> <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c
> > > <https://gist.github.com/achow101/3e179501290abb7049de198d46894c7c>>;
> > > >> > > > >
> > > >> > > > > I am also aware of other current and previous Bitcoin Core
> > > >> > > > > contributors and Lightning developers who didn’t attend the meeting in
> > > >> > > > > person who are opposed to LOT=true. I don’t want to put them in the
> > > >> > > > > spotlight for no reason but if you go through the conversation logs of
> > > >> > > > > not only the meeting but the weeks of discussion prior to this meeting
> > > >> > > > > you will see their views evaluated on the ##taproot-activation
> > > >> > > > > channel. In addition, on taprootactivation.com <http://taprootactivation.com>;
> > > <http://taprootactivation.com <http://taprootactivation.com>>; some mining pools
> > > >> > > > > expressed a preference for lot=false though I don’t know how strong
> > > >> > > > > that preference was.
> > > >> > > > >
> > > >> > > > > I am only one voice but it is my current assessment that if we are to
> > > >> > > > > attempt to finalize Taproot activation parameters and propose them to
> > > >> > > > > the community at this time our only option is to propose LOT=false.
> > > >> > > > > Any further delay appears to me counterproductive in our collective
> > > >> > > > > aim to get the Taproot soft fork activated as early as possible.
> > > >> > > > >
> > > >> > > > > Obviously others are free to disagree with that assessment and
> > > >> > > > > continue discussions but personally I will be attempting to avoid
> > > >> > > > > those discussions unless prominent new information comes to light or
> > > >> > > > > various specific individuals change their minds.
> > > >> > > > >
> > > >> > > > > Next week we are planning a code review of the Bitcoin Core PR #19573
> > > >> > > > > which was initially delayed because of this LOT discussion. As I’ve
> > > >> > > > > said previously that will be loosely following the format of the
> > > >> > > > > Bitcoin Core PR review club and will be lower level and more
> > > >> > > > > technical. That is planned for Tuesday February 23rd at 19:00 UTC on
> > > >> > > > > the IRC channel ##taproot-activation.
> > > >> > > > >
> > > >> > > > > Thanks to the meeting participants (and those who joined the
> > > >> > > > > discussion on the channel prior and post the meeting) for engaging
> > > >> > > > > productively and in good faith.
> > > >> > >
> > > >> > > --
> > > >> > > Michael Folkson
> > > >> > > Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> > > <mailto:michaelfolkson at gmail.com>>
> > > >> > > Keybase: michaelfolkson
> > > >> > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> > > >> > > _______________________________________________
> > > >> > > bitcoin-dev mailing list
> > > >> > > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> > > >> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
> > > >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>;
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Michael Folkson
> > > >> Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> > > <mailto:michaelfolkson at gmail.com>>
> > > >> Keybase: michaelfolkson
> > > >> PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> > > >> _______________________________________________
> > > >> bitcoin-dev mailing list
> > > >> bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > <mailto:bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>>
> > > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
> > > >> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>>;
> > > >
> > > >
> > > >
> > > > --
> > > > Michael Folkson
> > > > Email: michaelfolkson at gmail.com <mailto:michaelfolkson at gmail.com> <mailto:michaelfolkson at gmail.com
> > > <mailto:michaelfolkson at gmail.com>>
> > > > Keybase: michaelfolkson
> > > > PGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3
> > > _______________________________________________
> > > bitcoin-dev mailing list
> > > bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> > > <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>;
> > >
> >
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2017-09-06 📝 Original message:The ...

2023-06-07T20:05:25+02:00

In reply to nevent1q…hj72
_________________________

📅 Original date posted:2017-09-06
📝 Original message:The pattern used by Felix Weiss' BIP for Confidential Transactions
depends on or is tidier with 0-value outputs.

Adam

On 7 September 2017 at 00:54, CryptAxe via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> As long as an unspendable outputs (OP_RETURN outputs for example) with
> amount=0 are still allowed I don't see it being an issue for anything.
>
> On Sep 5, 2017 2:52 PM, "Jorge Timón via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> This is not a priority, not very important either.
>> Right now it is possible to create 0-value outputs that are spendable
>> and thus stay in the utxo (potentially forever). Requiring at least 1
>> satoshi per output doesn't really do much against a spam attack to the
>> utxo, but I think it would be slightly better than the current
>> situation.
>>
>> Is there any reason or use case to keep allowing spendable outputs
>> with null amounts in them?
>>
>> If not, I'm happy to create a BIP with its code, this should be simple.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2017-07-11 📝 Original ...

2023-06-07T20:04:12+02:00

In reply to nevent1q…l4hx
_________________________

📅 Original date posted:2017-07-11
📝 Original message:Separate from scale, there is utility to a hard-fork to fix wish-list
bugs that cant be reasonably fixed via soft-fork. The spoonnet
proposal fixes a good number of interesting bugs. Spoonnet and
several other HF research proposals can be found here
https://bitcoinhardforkresearch.github.io/ Part of the research on HF
is about safe deployment methods which is obviously the other main
consideration. It seems to me likely that if the HF were to focus on
bug fixes, and not mix in new tradeoffs of security vs scale, it would
more easily reach consensus.

Adam

On 11 July 2017 at 17:03, Chris Stewart via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Concept ACK.
>
> I think you are overstating the readiness of drivechains though. I think the
> optimistic estimate for drivechains to be ready for bitcoin core is a year
> out from today. More likely the date should be early 2018. Still a lot of
> work to be done! :-)
>
> Also I don't know if I would put a hard fork suggestion in the scaling map.
> If drivechains are successful they should be viewed as the way we scale --
> not hard forking the protocol. Do you still have capacity concerns if
> drivechains are successful?
>
> -Chris
>
> On Mon, Jul 10, 2017 at 11:50 AM, Paul Sztorc via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> 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, has been completed and awaits
>> activation (multiple BIPS). It is estimated to increase capacity by a
>> factor of 2.2. It also improves scalability in many ways. First, SW
>> includes a fee-policy which encourages users to minimize their impact on
>> the UTXO set. Second, SW achieves linear scaling of sighash operations,
>> which prevents the network from crashing when large transactions are
>> broadcast. Third, SW provides an efficiency gain for everyone who is not
>> verifying signatures, as these no longer need to be downloaded or
>> stored. SegWit is an enabling technology for the Lightning Network,
>> script versioning (specifically Schnorr signatures), and has a number of
>> benefits which
>> are unrelated to capacity [4].
>>
>> Third, the Lightning Network, which allows users to transact without
>> broadcasting to the network, is complete [5, 6] and awaits the
>> activation of SegWit. For those users who are able to make a single
>> on-chain transaction, it is estimated to increase both capacity and
>> scalability by a factor of ~1000 (although these capacity increases will
>> vary with usage patterns). LN also greatly improves transaction speed
>> and transaction privacy.
>>
>> Fourth, Transaction Compression [7], observes that Bitcoin transaction
>> serialization is not optimized for storage or network communication. If
>> transactions were optimally compressed (as is possible today), this
>> would improve scalability, but not capacity, by roughly 20%, and in some
>> cases over 30%.
>>
>> Fifth, Schnorr Signature Aggregation, which shrinks transactions by
>> allowing many transactions to have a single shared signature, has been
>> implemented [8] in draft form in libsecp256k1, and will likely be ready
>> by Q4 of 2016. One analysis [9] suggests that signature aggregation
>> would result in storage and bandwidth savings of at least 25%, which
>> would therefore increase scalability and capacity by a factor of 1.33.
>> The relative savings are even greater for multisignature transactions.
>>
>> Sixth, drivechain [10], which allows bitcoins to be temporarily
>> offloaded to 'alternative' blockchain networks ("sidechains"), is
>> currently under peer review and may be usable by end of 2017. Although
>> it has no impact on scalability, it does allow users to opt-in to
>> greater capacity, by moving their BTC to a new network (although, they
>> will achieve less decentralization as a result). Individual drivechains
>> may have different security tradeoffs (for example, a greater reliance
>> on UTXO commitments, or MimbleWimble's shrinking block history) which
>> may give them individually greater scalability than mainchain Bitcoin.
>>
>> Finally, the capacity improvements outlined above may not be sufficient.
>> If so, it may be necessary to use a hard fork to increase the blocksize
>> (and blockweight, sigops, etc) by a moderate amount. Such an increase
>> should take advantage of the existing research on hard forks, which is
>> substantial [11]. Specifically, there is some consensus that Spoonnet
>> [12] is the most attractive option for such a hardfork. There is
>> currently no consensus on a hard fork date, but there is a rough
>> consensus that one would require at least 6 months to coordinate
>> effectively, which would place it in the year 2018 at earliest.
>>
>> The above are only a small sample of current scaling technologies. And
>> even an exhaustive list of scaling technologies, would itself only be a
>> small sample of total Bitcoin innovation (which is proceeding at
>> breakneck speed).
>>
>> Signed,
>> <Names Here>
>>
>> [1]
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
>> [2] https://bitcoincore.org/en/2017/03/13/performance-optimizations-1/
>> [3] http://bluematt.bitcoin.ninja/2016/07/07/relay-networks/
>> [4] https://bitcoincore.org/en/2016/01/26/segwit-benefits/
>> [5]
>>
>> http://lightning.community/release/software/lnd/lightning/2017/05/03/litening/
>> [6] https://github.com/ACINQ/eclair
>> [7] https://people.xiph.org/~greg/compacted_txn.txt
>> [8]
>>
>> https://github.com/ElementsProject/secp256k1-zkp/blob/d78f12b04ec3d9f5744cd4c51f20951106b9c41a/src/secp256k1.c#L592-L594
>> [9] https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
>> [10] http://www.drivechain.info/
>> [11] https://bitcoinhardforkresearch.github.io/
>> [12]
>>
>> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
>>
>> ==== End of Roadmap Draft ====
>>
>> In short, please let me know:
>>
>> 1. If you agree that it would be helpful if the roadmap were updated.
>> 2. To what extent, if any, you like this draft.
>> 3. Edits you would make (specifically, I wonder about Drivechain
>> thoughts and Hard Fork thoughts, particularly how to phrase the Hard
>> Fork date).
>>
>> Google Doc (if you're into that kind of thing):
>>
>> https://docs.google.com/document/d/1gxcUnmYl7yM0oKR9NY9zCPbBbPNocmCq-jjBOQSVH-A/edit?usp=sharing
>>
>> Cheers,
>> Paul
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2017-01-04 📝 Original message:I ...

2023-06-07T19:55:08+02:00

In reply to nevent1q…mpwr
_________________________

📅 Original date posted:2017-01-04
📝 Original message:I think this discussion started from the block bloom filter where
there is a bloom filter commitment in the block which can be
downloaded and is much smaller than the block. An SPV node based on
that model would download headers and bloom filters, verify the bloom
filter is committed to, and test locally if any addresses managed by
the wallet are in the filter (or false positives for being in it), and
then download blocks with hits. Apparently there are maybe 50% more
compact alternatives to bloom filters but people have been using bloom
filter as a short-hand for that. The block bloom filter does seem to
have higher overhead than the query model, but it offers much better
privacy. I think there was previous discussion about maybe doing
something with portions of blocks so you can know which half or
quarter of the block etc.

Adam

On 4 January 2017 at 10:13, Jorge Timón via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> There were talks about implementing spv mode for bitcoin core without using
> bloom filters. Less efficient because it downloads full blocks, but better
> for privacy. Perhaps other spv implementations should consider doing the
> same instead of committing the filters in the block?
>
> Now I feel I was missing something. I guess you can download the whole block
> you're interested in instead of only your txs and that gives you privacy.
> But how do you get to know which blocks are you interested in?
>
> If the questions are too basic or offtopic for the thread, I'm happy getting
> answers privately (but then maybe I get them more than once).
>
>
> On 4 Jan 2017 09:57, "Aaron Voisine via bitcoin-dev"
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> It's easy enough to mark a transaction as "pending". People with bank
> accounts are familiar with the concept.
>
> Although the risk of accepting gossip information from multiple random
> peers, in the case where the sender does not control the receivers network
> is still minimal. Random node operators have no incentive to send fake
> transactions, and would need to control all the nodes a client connects to,
> and find a non-false-positive address belonging to the victims wallet.
>
> It's not impossible, but it's non trivial, would only temporarily show a
> pending transaction, and provide no benefit to the node operator. There are
> much juicier targets for an attacker with the ability to sybil attack the
> entire bitcoin p2p network.
>
> Aaron
>
> On Tue, Jan 3, 2017 at 11:47 PM Jonas Schnelli <dev at jonasschnelli.ch> wrote:
>>
>> Hi
>>
>>
>>
>> > Unconfirmed transactions are incredibly important for real world use.
>>
>> > Merchants for instance are willing to accept credit card payments of
>>
>> > thousands of dollars and ship the goods despite the fact that the
>>
>> > transaction can be reversed up to 60 days later. There is a very large
>>
>> > cost to losing the ability to have instant transactions in many or
>>
>> > even most situations. This cost is typically well above the fraud risk.
>>
>> >
>>
>> > It's important to recognize that bitcoin serves a wide variety of use
>>
>> > cases with different profiles for time sensitivity and fraud risk.
>>
>> >
>>
>> I agree that unconfirmed transactions are incredibly important, but not
>>
>> over SPV against random peers.
>>
>>
>>
>> If you offer users/merchants a feature (SPV 0-conf against random
>>
>> peers), that is fundamentally insecure, it will – sooner or later – lead
>>
>> to some large scale fiasco, hurting Bitcoins reputation and trust from
>>
>> merchants.
>>
>>
>>
>> Merchants using and trusting 0-conf SPV transactions (retrieved from
>>
>> random peers) is something we should **really eliminate** through
>>
>> education and by offering different solution.
>>
>>
>>
>> There are plenty, more sane options. If you can't run your own full-node
>>
>> as a merchant (trivial), maybe co-use a wallet-service with centralized
>>
>> verification (maybe use two of them), I guess Copay would be one of
>>
>> those wallets (as an example). Use them in watch-only mode.
>>
>>
>>
>> For end-users SPV software, I think it would be recommended to...
>>
>> ... disable unconfirmed transactions during SPV against random peers
>>
>> ... enable unconfirmed transactions when using SPV against a trusted
>>
>> peer with preshared keys after BIP150
>>
>> ... if unconfirmed transactions are disabled, show how it can be enabled
>>
>> (how to run a full-node [in a box, etc.])
>>
>> ... educate, inform users that a transaction with no confirmation can be
>>
>> "stopped" or "redirected" any time, also inform about the risks during
>>
>> low-conf phase (1-5).
>>
>>
>>
>> I though see the point that it's nice to make use of the "incoming
>>
>> funds..." feature in SPV wallets. But – for the sake of stability and
>>
>> (risk-)scaling – we may want to recommend to scarify this feature and –
>>
>> in the same turn – to use privacy-preserving BFD's.
>>
>>
>>
>> </jonas>
>>
>>
>>
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2016-02-06 📝 Original message:Hi ...

2023-06-07T19:48:38+02:00

In reply to nevent1q…czap
_________________________

📅 Original date posted:2016-02-06
📝 Original message:Hi Gavin

It would probably be a good idea to have a security considerations
section, also, is there a list of which exchange, library, wallet,
pool, stats server, hardware etc you have tested this change against?

Do you have a rollback plan in the event the hard-fork triggers via
false voting as seemed to be prevalent during XT? (Or rollback just
as contingency if something unforseen goes wrong).

How do you plan to monitor and manage security through the hard-fork?

Adam

On 6 February 2016 at 16:37, Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Responding to "28 days is not long enough" :
>
> I keep seeing this claim made with no evidence to back it up. As I said, I
> surveyed several of the biggest infrastructure providers and the btcd lead
> developer and they all agree "28 days is plenty of time."
>
> For individuals... why would it take somebody longer than 28 days to either
> download and restart their bitcoind, or to patch and then re-run (the patch
> can be a one-line change MAX_BLOCK_SIZE from 1000000 to 2000000)?
>
> For the Bitcoin Core project: I'm well aware of how long it takes to roll
> out new binaries, and 28 days is plenty of time.
>
> I suspect there ARE a significant percentage of un-maintained full nodes--
> probably 30 to 40%. Losing those nodes will not be a problem, for three
> reasons:
> 1) The network could shrink by 60% and it would still have plenty of open
> connection slots
> 2) People are committing to spinning up thousands of supports-2mb-nodes
> during the grace period.
> 3) We could wait a year and pick up maybe 10 or 20% more.
>
> I strongly disagree with the statement that there is no cost to a longer
> grace period. There is broad agreement that a capacity increase is needed
> NOW.
>
> To bring it back to bitcoin-dev territory: are there any TECHNICAL
> arguments why an upgrade would take a business or individual longer than 28
> days?
>
>
> Responding to Luke's message:
>
>> On Sat, Feb 6, 2016 at 1:12 AM, Luke Dashjr via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > On Friday, February 05, 2016 8:51:08 PM Gavin Andresen via bitcoin-dev
>> > wrote:
>> >> Blog post on a couple of the constants chosen:
>> >> http://gavinandresen.ninja/seventyfive-twentyeight
>> >
>> > Can you put this in the BIP's Rationale section (which appears to be
>> > mis-named
>> > "Discussion" in the current draft)?
>
>
> I'll rename the section and expand it a little. I think standards documents
> like BIPs should be concise, though (written for implementors), so I'm not
> going to recreate the entire blog post there.
>
>>
>> >
>> >> Signature operations in un-executed branches of a Script are not
>> >> counted
>> >> OP_CHECKMULTISIG evaluations are counted accurately; if the signature
>> >> for a
>> >> 1-of-20 OP_CHECKMULTISIG is satisified by the public key nearest the
>> >> top
>> >> of the execution stack, it is counted as one signature operation. If it
>> >> is
>> >> satisfied by the public key nearest the bottom of the execution stack,
>> >> it
>> >> is counted as twenty signature operations. Signature operations
>> >> involving
>> >> invalidly encoded signatures or public keys are not counted towards the
>> >> limit
>> >
>> > These seem like they will break static analysis entirely. That was a
>> > noted
>> > reason for creating BIP 16 to replace BIP 12. Is it no longer a concern?
>> > Would
>> > it make sense to require scripts to commit to the total accurate-sigop
>> > count
>> > to fix this?
>
>
> After implementing static counting and accurate counting... I was wrong.
> Accurate/dynamic counting/limiting is quick and simple and can be completely
> safe (the counting code can be told the limit and can "early-out"
> validation).
>
> I think making scripts commit to a total accurate sigop count is a bad
> idea-- it would make multisignature signing more complicated for zero
> benefit. E.g. if you're circulating a partially signed transaction to that
> must be signed by 2 of 5 people, you can end up with a transaction that
> requires 2, 3, 4, or 5 signature operations to validate (depending on which
> public keys are used to do the signing). The first signer might have no
> idea who else would sign and wouldn't know the accurate sigop count.
>
>>
>> >
>> >> The amount of data hashed to compute signature hashes is limited to
>> >> 1,300,000,000 bytes per block.
>> >
>> > The rationale for this wasn't in your blog post. I assume it's based on
>> > the
>> > current theoretical max at 1 MB blocks? Even a high-end PC would
>> > probably take
>> > 40-80 seconds just for the hashing, however - maybe a lower limit would
>> > be
>> > best?
>
>
> It is slightly more hashing than was required to validate block number
> 364,422.
>
> There are a couple of advantages to a very high limit:
>
> 1) When the fork is over, special-case code for dealing with old blocks can
> be eliminated, because all old blocks satisfy the new limit.
>
> 2) More importantly, if the limit is small enough it might get hit by
> standard transactions, then block creation code (CreateNewBlock() /
> getblocktemplate / or some external transaction-assembling software) will
> have to solve an even more complicated bin-packing problem to optimize for
> fees paid.
>
> In practice, the 20,000 sigop limit will always be reached before
> MAX_BLOCK_SIGHASH.
>
>
>>
>> >
>> >> Miners express their support for this BIP by ...
>> >
>> > But miners don't get to decide hardforks. How does the economy express
>> > their
>> > support for it? What happens if miners trigger it without consent from
>> > the
>> > economy?
>
>
> "The economy" does support this.
>
>
>>
>> >
>> > If you are intent on using the version bits to trigger the hardfork, I
>> > suggest
>> > rephrasing this such that miners should only enable the bit when they
>> > have
>> > independently confirmed economic support (this means implementations
>> > need a
>> > config option that defaults to off).
>
>
> Happy to add words about economic majority.
>
> Classic will not implement a command-line option (the act of running Classic
> is "I opt in"), but happy to add one for a pull request to Core, assuming
> Core would not see such a pull request as having any hostile intent.
>
>
>> >
>> >> SPV (simple payment validation) wallets are compatible with this
>> >> change.
>> >
>> > Would prefer if this is corrected to "Light clients" or something.
>> > Actual SPV
>> > wallets do not exist at this time, and would not be compatible with a
>> > hardfork.
>
>
> Is there an explanation of SPV versus "Light Client" written somewhere more
> permanent than a reddit comment or forum post that I can point to?
>
>>
>> >
>> >> In the short term, an increase is needed to continue the current
>> >> economic
>> >> policies with regards to fees and block space, matching market
>> >> expectations
>> >> and preventing market disruption.
>> >
>> > IMO this sentence is the most controversial part of your draft, and it
>> > wouldn't suffer a loss to remove it (or at least make it subjective).
>
>
> Happy to remove.
>
>>
>> > I would also prefer to see any hardfork:
>> >
>> > 1. Address at least the simple tasks on the hardfork wishlist (eg,
>> > enable some
>> > disabled opcodes; fix P2SH for N-of->15 multisig; etc).
>
>
> Those would be separate BIPs. (according to BIP 1, smaller is better)
>
> After this 2MB bump, I agree we need to agree on a process for the next hard
> fork to avoid all of the unnecessary drama.
>
>> > 2. Be deployed as a soft-hardfork so as not to leave old nodes entirely
>> > insecure.
>
>
> I haven't been paying attention to all of the
> "soft-hardfork/hard-softfork/etc" terminology so have no idea what you mean.
> Is THAT written up somewhere?
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2016-01-08 📝 Original message:Tricky ...

2023-06-07T19:47:44+02:00

In reply to nevent1q…thcy
_________________________

📅 Original date posted:2016-01-08
📝 Original message:Tricky choice. On the one hand I had spotted this too before and maybe
one or two more exceptions to bitcoin's 128-bit security target and
been vaguely tut-tutting about them in the background. It's kind of a
violation of crypto rule of thumb that you want to balance things and
not have odd weak points as Watson was implying, it puts you closer to
the margin if there is a slip or other problem so you have an
imbalanced crypto format.

On the other hand it's not currently a problem as such and it's less
change and slightly more compact.

RIPEMD probably is less well reviewed than SHA2. However SHA1 has
problems, and SHA2 is a bigger SHA1 basically so, hence the NIST
motivation for SHA3 designed to fix the design flaw in SHA1 (and SHA2
in principle).

So then if we agree with this rule of thumb (and not doing so would
fly against best practices which we probably shouldnt look to do in
such a security focussed domain) then what this discussion is more
about is when is a good time to write down tech debt.

I think that comes to segregated-witness itself which writes down a
tidily organised by lines of code robust fix to a bunch of long
standing problems.

Doing a 2MB hard-fork in comparison fixes nothing really. Leaving
known issues to bake in for another N years eventually builds up on
you (not even in security just in software engineering) as another
rule of thumb. I mean if we dont fix it now that we are making a
change that connects, when will we?

In software projects I ran we always disguised the cost of tech-debt
as non-negotiable baked into our estimates without a line item to
escape the PHB syndrome of haggling for features instead of tech debt
(which is _never_ a good idea:)

Pragmatism vs refactoring as you go.

But for scale I think segregated-witness does offer the intriguing
next step of being able to do 2 of 2, 3 of 3 and N of N which give
size of one sig multisig (indistinguishable even for privacy) as well
as K of N key tree sigs, which are also significantly more compact.

There was also the other thing I mentioned further up the thread that
if we want to take an approach of living with little bit of bloat from
getting back to a universal 128-bit target, there are still some
fixable bloat things going on:
a) sending pubKey in the signature vs recovery (modulo interference
with Schnorr batch verify compatibility*);
b) using the PubKey instead of PKH in the ScriptPubKey, though that
loses the nice property of of not having the key to do DL attacks on
until the signed transaction is broadcast;
c) I think there might be a way to combine hash & PubKey to keep the
delayed PubKey publication property and yet still save the bloat of
having both.

* I did suggest to Pieter that you could let the miner decide to forgo
Schnorr batch verifiability to get compaction from recovery - the pub
key could be optionally elided from the scriptSig serialisation by the
miner.

The other thing we could consider is variable sized hashes (& a few
pubkey size choices) that is software complexity however. We might be
better of focussing on the bigger picture like IBLT/weak-blocks and
bigger wins like MAST, multiSig Schnorr & key tree sigs.

Didnt get time to muse on c) but a nice crypto question for someone :)

Another thing to note is combining has been known to be fragile to bad
interactions or unexpected behaviours. This paper talks about things
tradeoffs and weaknesses in hash combiners.
http://tuprints.ulb.tu-darmstadt.de/2094/1/thesis.lehmann.pdf

Weak concept NACK I think for losing a cleanup opportunity to store it
up for the future when there is a reasonable opportunity to fix it?

Adam

On 8 January 2016 at 15:34, Watson Ladd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Fri, Jan 8, 2016 at 4:38 AM, Gavin Andresen via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> On Fri, Jan 8, 2016 at 7:02 AM, Rusty Russell <rusty at rustcorp.com.au> wrote:
>>>
>>> Matt Corallo <lf-lists at mattcorallo.com> writes:
>>> > Indeed, anything which uses P2SH is obviously vulnerable if there is
>>> > an attack on RIPEMD160 which reduces it's security only marginally.
>>>
>>> I don't think this is true? Even if you can generate a collision in
>>> RIPEMD160, that doesn't help you since you need to create a specific
>>> SHA256 hash for the RIPEMD160 preimage.
>>>
>>> Even a preimage attack only helps if it leads to more than one preimage
>>> fairly cheaply; that would make grinding out the SHA256 preimage easier.
>>> AFAICT even MD4 isn't this broken.
>>
>>
>> It feels like we've gone over that before, but I can never remember where or
>> when. I believe consensus was that if we were using the broken MD5 in all
>> the places we use RIPEMD160 we'd still be secure today because of Satoshi's
>> use of nested hash functions everywhere.
>>
>>>
>>> But just with Moore's law (doubling every 18 months), we'll worry about
>>> economically viable attacks in 20 years.[1]
>>>
>>>
>>> That's far enough away that I would choose simplicity, and have all SW
>>> scriptPubKeys simply be "<0> RIPEMD(SHA256(WP))" for now, but it's
>>> not a no-brainer.
>>
>>
>> Lets see if I've followed the specifics of the collision attack correctly,
>> Ethan (or somebody) please let me know if I'm missing something:
>>
>> So attacker is in the middle of establishing a payment channel with
>> somebody. Victim gives their public key, attacker creates the innocent
>> fund-locking script '2 V A 2 CHECKMULTISIG' (V is victim's public key, A is
>> attacker's) but doesn't give it to the victim yet.
>>
>> Instead they then generate about 2^81scripts that are some form of
>> pay-to-attacker ....
>> ... wait, no that doesn't work, because SHA256 is used as the inner hash
>> function. They'd have to generate 2^129 to find a cycle in SHA256.
>
> For 2^80 they simply generate 2^80 scripts that look innocent, and
> 2^80 that are not. With high probability there is a collision. I agree
> that most cryptanalysis won't work because of the nesting, but 2^80 is
> not good.
>>
>> Instead, they .. what? I don't see a viable attack unless RIPEMD160 and
>> SHA256 (or the combination) suffers a cryptographic break.
>>
>>
>> --
>> --
>> Gavin Andresen
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> --
> "Man is born free, but everywhere he is in chains".
> --Rousseau.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2016-01-07 📝 Original message:You ...

2023-06-07T19:47:38+02:00

In reply to nevent1q…a05r
_________________________

📅 Original date posted:2016-01-07
📝 Original message:You could say 256 bit ECDSA is overkill lets go to 160 equivalently.
Saves even more bytes.

The problem with arguing down is where to stop.

As Matt said these things dont degrade gracefully so a best practice
is to aim for a bit of extra margin.

256-bit is quite common at this point since AES, SHA256 etc even in
things with much less at stake than Bitcoin.

You could send the compressed (unhashed) pubkey then there's no hash
(and omit it from the sig). Greg had mentioned that in the past.

I think it might be possible to do both (reclaim the hash bits in the
serialisation of the pub key).

Adam

On 7 January 2016 at 20:02, Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm hoisting this from some private feedback I sent on the segregated
> witness BIP:
>
> I said:
>
> "I'd also use RIPEMD160(SHA256()) as the hash function and save the 12
> bytes-- a successful preimage attack against that ain't gonna happen before
> we're all dead. I'm probably being dense, but I just don't see how a
> collision attack is relevant here."
>
> Pieter responded:
>
> "The problem case is where someone in a contract setup shows you a script,
> which you accept as being a payment to yourself. An attacker could use a
> collision attack to construct scripts with identical hashes, only one of
> which does have the property you want, and steal coins.
>
> So you really want collision security, and I don't think 80 bits is
> something we should encourage for that. Normal pubkey hashes don't have that
> problem, as they can't be constructed to pay to you."
>
> ... but I'm unconvinced:
>
> "But it is trivial for contract wallets to protect against collision
> attacks-- if you give me a script that is "gavin_pubkey CHECKSIG
> arbitrary_data OP_DROP" with "I promise I'm not trying to rip you off, just
> ignore that arbitrary data" a wallet can just refuse. Even more likely, a
> contract wallet won't even recognize that as a pay-to-gavin transaction.
>
> I suppose it could be looking for some form of "gavin_pubkey
> somebody_else_pubkey CHECKMULTISIG ... with the attacker using
> somebody_else_pubkey to force the collision, but, again, trivial contract
> protocol tweaks ("send along a proof you have the private key corresponding
> to the public key" or "everybody pre-commits pubkeys they'll use at protocol
> start") would protect against that.
>
> Adding an extra 12 bytes to every segwit to prevent an attack that takes
> 2^80 computation and 2^80 storage, is unlikely to be a problem in practice,
> and is trivial to protect against is the wrong tradeoff to make."
>
> 20 bytes instead of 32 bytes is a savings of almost 40%, which is
> significant.
>
> The general question I'd like to raise on this list is:
>
> Should we be worried, today, about collision attacks against RIPEMD160 (our
> 160-bit hash)?
>
> Mounting a successful brute-force collision attack would require at least
> O(2^80) CPU, which is kinda-sorta feasible (Pieter pointed out that Bitcoin
> POW has computed more SHA256 hashes than that). But it also requires O(2^80)
> storage, which is utterly infeasible (there is something on the order of
> 2^35 bytes of storage in the entire world). Even assuming doubling every
> single year (faster than Moore's Law), we're four decades away from an
> attacker with THE ENTIRE WORLD's storage capacity being able to mount a
> collision attack.
>
>
> References:
>
> https://en.wikipedia.org/wiki/Collision_attack
>
> https://vsatglobalseriesblog.wordpress.com/2013/06/21/in-2013-the-amount-of-data-generated-worldwide-will-reach-four-zettabytes/
>
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-12-17 📝 Original message:There ...

2023-06-07T19:46:33+02:00

In reply to nevent1q…78ym
_________________________

📅 Original date posted:2015-12-17
📝 Original message:There are a range of opinions about input assumptions by different
people. In each case, short of misunderstanding, if we have the same
input assumptions we're going to reach the same conclusions. This is
the way of the world in a meritocracy. The interesting point is to
compare the input assumptions and try to figure out which are more
realistic, pragmatic and achieve the best outcome.

It might be instructive to re-read Greg's roadmap and others to
re-read Jeff's original post (I will).

There is a proposed roadmap and soft-fork block-size increase and code
that Pieter is working on. There has been rationale described for
this approach, and it achieves many useful things both short, mid and
long term for scale and other issues.

There seem to be a range of opinions on the fee market, and one
question is when do we deem it safe to aim to be prepared to support a
fee market.

How elastic is block-size demand? (I think there is evidence of some
elasticity which indicates a partly working fee market already). What
I mean by elasticity of block-size demand is there are off-chain
transactions and people make an economic choice of whether to go on
chain or not, and the vast majority of transactions, all told, are
off-chain. Clearly it is ideal if they all go on chain, scale
permitting.

If we look at the roadmap at high-level:

1) bump (seg-wit or ...)
2) network improvements (IBLT/weak-block/other)
3) longer term dynamic block-size (flexcap)
4) write-cache (lightning)

It would probably be good to see some work on preparing for fee
markets. That has happened somewhat recently in response to the
stress tests. We do have an observed problem that if there is no
incentive to prepare, the improvements dont happen, and so we can
never be ready for a fee market. That's kind of how we got here,
people were talking about fee-estimation and dynamic fees several
years ago before the block-size went from 250kB to 750kB, and then
lost interest as there was another 500kB to play with. There could be
a best practice doc written asking people to prepare. That might
help.

Presumably it's good if we do see the fee market more, for it to come
in gradually. Flexcap probably helps there because the block-size
itself becomes elastic to demand (pay for bigger blocks).

If we want to avoid a fee market for the immediate term, are we more
worried about period 1, or period 2 or 3. Probably 2 is more of a
worry as we're scaling in 1 where in period 2 we're preparing for
scaling and more time has passed for demand to grow. That might for
example argue for seg-wit because it brings us closer to 4) and if we
spread things out we might delay the possibility to do lightning as
there is only so many cycles for forks (hard or soft) in testing,
deployment planning etc so it can be good to have a holistic view.

Also the question of time-frame that is safe for soft-forks or
hard-forks is another input where views seem to vary. I think some
people are more optimistic about being able to avoid people losing
money in fast hard-forks. One lesson on users, is users find failure
modes that testing cant, or do things you would expect them not to do.

Also we're calling hard-forks things that are really soft-forks to SPV
clients, and hard-forks only to full-nodes. If we wanted to make a
real economic choice, we could artificially make an SPV hard-fork,
however that would make upgrade harder.

As I said in an earlier email I think everyone is empathetic to user
requirements, including economic desires - but Bitcoin has inherent
constraints that are complex to improve. Each proposal is trying to
best meet those holistic user requirements. There are no free lunches
and we dont want to economically hurt anyone in total or as a group or
type of use. Not all requirements can be met, they are in a trade
off, so that calls for balance, planning and transparency.

This is also a market, we can discuss protocol tradeoffs without being
melodramatic - would be kind of undesirable if a dramatic or emotive
way to express something as easily or more clearly expressed in
technical constructive words is moving the price around.

Adam

On 17 December 2015 at 03:58, Jeff Garzik via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Dec 16, 2015 at 9:44 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>
>> At least SW *is* a scaling solution (albeit most of the important benefits
>> are long term). The issue of fee events has nothing to do with scaling - it
>> has to do with economics...specifically whether we should be subsidizing
>> transactions, who should pay the bill for it, etc. My own personal opinion
>> is that increasing validation costs works against adoption, not for
>> it...even if it artificially keeps fees low - and we'll have to deal with a
>> fee event sooner or later anyhow. You may disagree with my opinion, but
>> please, let's stop confounding the economic issues with actual scaling.
>
>
> At least on my part, the title of the 1st email was "It's economics & ..."
> and focused on (a) economics and (b) transition issues. There was no
> confounding. There was a list of real problems and risks taken when 1M is
> not lifted in the short term.
>
> Thus "SW is orthogonal" in these emails, because these problems remain
> regardless of SW or no, as the 1st email outlined.
>
> The 2nd email addresses the specific assertion of "no 1M hard fork needed,
> because SW."
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-12-14 📝 Original message:I ...

2023-06-07T19:45:46+02:00

In reply to nevent1q…jkl2
_________________________

📅 Original date posted:2015-12-14
📝 Original message:I think someone, maybe Pieter, commented on this relay issue that it
would be likely very transitory, as a lot of stuff would be fairly
quickly upgraded in practice from previous deployment experience, and
I think anyway there is a huge excess connectivity and capacity in the
p2p network vs having a connected network of various versions, and
supporting SPV client load (SPV load is quite low relative to
capacity, even one respectable node can support a large number of SPV
clients).

(Ie so two classes of network node and connectivity wouldnt be a
problem in practice even if it did persist; also the higher capacity
better run nodes are more likely to upgrade due to having more clued
in power user, miner, pool or company operators).

Maybe someone more detailed knowledge could clarify further.

Adam

On 14 December 2015 at 19:21, Jonathan Toomim via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> This means that a server supporting SW might only hear of the tx data and
> not get the signature data for some transactions, depending on how the relay
> rules worked (e.g. if the SW peers had higher minrelaytxfee settings than
> the legacy peers). This would complicate fast block relay code like IBLTs,
> since we now have to check to see that the recipient has both the tx data
> and the witness/sig data.
>
> The same issue might happen with block relay if we do SW as a soft fork. A
> SW node might see a block inv from a legacy node first, and might start
> downloading the block from that node. This block would then be marked as
> in-flight, and the witness data might not get downloaded. This shouldn't be
> too hard to fix by creating an inv for the witness data as a separate
> object, so that a node could download the block from e.g. Peer 1 and the
> segwit data from Peer 2.
>
> Of course, the code would be simpler if we did this as a hard fork and we
> could rely on everyone on the segwit fork supporting the segwit data.
> Although maybe we want to write the interfaces in a way that supports some
> nodes not downloading the segwit data anyway, just because not every node
> will want that data.
>
> I haven't had time to read sipa's code yet. I apologize for talking out of a
> position of ignorance. For anyone who has, do you feel like sharing how it
> deals with these network relay issues?
>
> By the way, since this thread is really about SegWit and not about any other
> mechanism for increasing Bitcoin capacity, perhaps we should rename it
> accordingly?
>
>
> On Dec 12, 2015, at 11:18 PM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> A segwit supporting server would be required to support relaying segwit
> transactions, although a non-segwit server could at least inform a wallet of
> segwit txns observed, even if it doesn't relay all information necessary to
> validate.
>
> Non segwit servers and wallets would continue operations as if nothing had
> occurred.
>
> If this means essentially that a soft fork deployment of SegWit will require
> SPV wallet servers to change their logic (or risk not being able to send
> payments) then it does seem to me that a hard fork to deploy this non
> controversial change is not only cleaner (on the data structure side) but
> safer in terms of the potential to affect the user experience.
>
>
> — Regards,
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-11-14 📝 Original message:There ...

2023-06-07T19:44:38+02:00

In reply to nevent1q…z8en
_________________________

📅 Original date posted:2015-11-14
📝 Original message:There is a difference between miners signalling intent (as they have
been for various BIPs, which is mostly informational only - they are
mostly not running the code, and in some cases it is not implemented,
so they cant be) there is a difference between that and a 95% miner
majority consensus rule. Former can be useful information as you
said, latter implies as Luke described something that is not really
accurate, it is not strictly only a miner upgrade needed for basic
safety as with soft-forks. If you look at BIP 103 for example it is
flag day based, and I think this is a more accurate approach. Also
with miner votes they can be misleading - vote for one thing, but run
something else; what they are running is not generally
detectable/enforceable - see for example what happened with the BIP66
accidental fork due to "SPV mining" (ie validationless mining).

A hard-fork is for everyone to upgrade and talk with each other to see
that the vast majority is on the same plan which includes users,
ecosystem companies & miners.

Adam

On 14 November 2015 at 01:02, digitsu412 via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Well I'd like to think that with an economy all parts of it interact with
> each other in ways more complex than simplistic imperative logic.
>
> I agree that the economic majority is essentially what matters in a hard
> fork but everyone (miners,devs,public thought leaders,businesses) is part of
> that economy. Additionally what miners signal as their intention affects the
> decision of that economic majority (and vice versa). You can see the
> effects of this in traditional political processes in how preliminary vote
> polling results affect (reinforce) the final vote.
> We also can see the results of this in (dare I mention) the whole XT affair
> which had the signed intent of many of the economy (payment processors and
> wallets and one miner pool) and the rest of the miners did not go along with
> it. This experiment either means that the rest of the miners couldn't be
> bothered to signal at all (because they didn't know how) or they were
> affected by the influence of core devs or the opinions of others on the
> matter and rejected the economic majority. (Which would imply core devs
> have some power by way of indirect influence) I would be inclined to believe
> the latter was more likely.
>
> The conclusion which this would seem to imply is that at the very least,
> miners matter (to what exact extent is debatable). And although there is no
> direct control of any party over the other in the strict sense, the public
> vocal opinions of any part of the Bitcoin economy does have an effect in its
> ability to sway the opinions of the other parts.
>
> Digitsu
>
> — Regards,
>
>
> On Sat, Nov 14, 2015 at 7:29 AM, Luke Dashjr <luke at dashjr.org> wrote:
>>
>> On Friday, November 13, 2015 4:01:09 PM digitsu at gmail.com wrote:
>> > Forgive the frankness but I don't see why signaling your intent to
>> > support
>> > an upgrade to one side of a hard fork can be seen as a bad thing. If for
>> > nothing else doesn't this make for a smoother flag day? (Because once
>> > you
>> > signal your intention, it makes it hard to back out on the commitment.)
>>
>> It isn't a commitment in any sense, nor does it make it smoother, because
>> for
>> a hardfork to be successful, it is the *economy* that must switch
>> entirely.
>> The miners are unimportant.
>>
>> > If miners don't have any choice in hard forks, who does? Just the core
>> > devs?
>>
>> Devs have even less of a choice in the matter. What is relevant is the
>> economy: who do people want to spend their bitcoins with? There is no
>> programmatic way to determine this, especially not in advance, so the best
>> we
>> can do is a flag day that gets called off if there isn't clear consensus.
>>
>> Luke
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-09-28 📝 Original message:I ...

2023-06-07T19:41:27+02:00

In reply to nevent1q…a0l8
_________________________

📅 Original date posted:2015-09-28
📝 Original message:I wonder what Gavin's views are, he's usually constructive, and see if
he'll include it in XT - I think he may have said he was supportive.

The rationale for soft vs hard-forks is well known, so I wont go over them.

Adam

On 28 September 2015 at 06:48, Mike Hearn via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> There is no consensus on using a soft fork to deploy this feature. It will
> result in the same problems as all the other soft forks - SPV wallets will
> become less reliable during the rollout period. I am against that, as it's
> entirely avoidable.
>
> Make it a hard fork and my objection will be dropped.
>
> Until then, as there is no consensus, you need to do one of two things:
>
> 1) Drop the "everyone must agree to make changes" idea that people here like
> to peddle, and do it loudly, so everyone in the community is correctly
> informed
>
> 2) Do nothing
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-08-17 📝 Original message:Thank ...

2023-06-07T19:36:07+02:00

In reply to nevent1q…ny9m
_________________________

📅 Original date posted:2015-08-17
📝 Original message:Thank you Eric for saying what needs to be said.

Starting a fork war is just not constructive and there are multiple
proposals being evaluated here.

I think that one thing that is not being so much focussed on is
Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on
Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core
SPV nodes that did not opt-in. It exposes those SPV nodes to loss in
the likely event that Bitcoin-XT results in a network-split.

The recent proposal here to run noXT (patch to falsely claim to mine
on XT while actually rejecting it's blocks) could add enough
uncertainty about the activation that Bitcoin-XT would probably have
to be aborted.

Adam

On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> NxtChg,
>
> In the entire history of Bitcoin we’ve never attempted anything even closely resembling a hard fork like what’s being proposed here.
>
> Many of us have wanted to push our own hard-forking changes to the protocol…and have been frustrated because of the inability to do so.
>
> This inability is not due to any malice on anyone’s part…it is a feature of Satoshi’s protocol. For better or worse, it is *very hard* to change the rules…and this is exactly what imbues Bitcoin with one of its most powerful attributes: very well-defined settlement guarantees that cannot be suddenly altered nor reversed by anyone.
>
> We’ve managed to have a few soft forks in the past…and for the most part these changes have been pretty uncontroversial…or at least, they have not had nearly the level of political divisiveness that this block size issue is having. And even then, we’ve encountered a number of problems with these deployments that have at times required goodwill cooperation between developers and mining pool operators to fix.
>
> Again, we have NEVER attempted anything even remotely like what’s being proposed - we’ve never done any sort of hard fork before like this. If even fairly uncontroversial soft forks have caused problems, can you imagine the kinds of potential problems that a hard fork over some highly polarizing issue might raise? Do you really think people are going to want to cooperate?!?
>
> I can understand that some people would like bigger blocks. Other people might want feature X, others feature Y…and we can argue the merits of this or that to death…but the fact remains that we have NEVER attempted any hard forking change…not even with a simple, totally uncontroversial no-brainer improvement that would not risk any sort of ill-will that could hamper remedies were it not to go as smoothly as we like. *THIS* is the fundamental problem - the whole bigger block thing is a minor issue by comparison…it could be any controversial change, really.
>
> Would you want to send your test pilots on their first flight…the first time an aircraft is ever flown…directly into combat without having tested the plane? This is what attempting a hard fork mechanism that’s NEVER been done before in such a politically divisive environment basically amounts to…but it’s even worse. We’re basically risking the entire air force (not just one plane) over an argument regarding how many seats a plane should have that we’ve never flown before.
>
> We’re talking billlions of dollars’ worth of other people’s money that is on the line here. Don’t we owe it to them to at least test out the system on a far less controversial, far less divisive change first to make sure we can even deploy it without things breaking? I don’t even care about the merits regarding bigger blocks vs. smaller blocks at this point, to be quite honest - that’s such a petty thing compared to what I’m talking about here. If we attempt a novel hard-forking mechanism that’s NEVER been attempted before (and which as many have pointed out is potentially fraught with serious problems) on such a politically divisive, polarizing issue, the result is each side will refuse to cooperate with the other out of spite…and can easily lead to a war, tanking the value of everyone’s assets on both chains. All so we can process 8 times the number of transactions we currently do? Even if it were 100 times, we wouldn’t even come close to touching big payment processors like Visa. It’s hard to imagine a protocol improvement that’s worth the risk.
>
> I urge you to at least try to see the bigger picture here…and to understand that nobody is trying to stop anyone from doing anything out of some desire for maintaining control - NONE of us are able to deploy hard forks right now without facing these problems. And different people obviously have different priorities and preferences as to which of these changes would be best to do first. This whole XT thing is essentially giving *one* proposal special treatment above those that others have proposed. Many of us have only held back from doing this out of our belief that goodwill amongst network participants is more important than trying to push some pet feature some of us want.
>
> Please stop this negativity - we ALL want the best for Bitcoin and are doing our best, given what we understand and know, to do what’s right.

📅 Original date posted:2015-08-19 📝 Original message:It ...

2023-06-07T19:35:48+02:00

In reply to nevent1q…wf0z
_________________________

📅 Original date posted:2015-08-19
📝 Original message:It seems to be a recurring meme that BIP 101 is somehow "a solution
put forward" where BIP 100, 102, 103, flexcap, extension blocks etc
etc are not.

That is not at ALL the case, and is insulting (present company excluded).

It is just that no one else is reckless enough to bypass the review
process and risk a controversial hard fork deployment war. Myself and
many other people warned Gavin a network fork "war" would start (ie
someone would think of some way to sabotage or attack the deployment
of Bitcoin-XT via protocol, code, policy, consensus soft-fork etc. He
ignored the warnings. Many also warned that 75% was an optimally BAD
trigger ratio (and that in a hard fork it is not a miner vote really
as in soft-forks). Gavin & Mike ignored that warning to. I know they
heard those warnings because I told them 1:1 in person or via email
and had on going conversations. Others did too.

People can not blame bitcoin core or me, that this then predictably
happened exactly as we said it would - it was completely obvious and
predictable.

In fact noBitcoinXT is even more dangerous and therefore amplified in
effect in creating mutual assured destruction kind of risk profile
than the loose spectrum of technical counters imagined. I did not
personally put much effort into thinking about counters because I
though it counter productive and hoped that Gavin & Mike would have
the maturity to not start down such a path.

Again any of the other proposals can easily be implemented. They
*could* also spin up a web page and put up binaries, however no one
else was crazy enough to try to start a deployment in that way.

It is also puzzling timing - with all these BIPs and ongoing
discussion and workshops coming imminently to then release ahead of
that process where as far as I know Gavin said he was equally happy
with BIP 100 or other proposal which ever is best, and on basically
the eve of workshops planned to progress this collaboratively.
Bitcoin-XT is also under tested, people are finding privacy bugs and
other issues. (Not even mentioning the above 75% optimally bad
parameter, and the damage to community reputation and collaborative
environment that this all causes.)

Very disappointing Gavin and Mike.

I find it quite notable that Gavin and Mike have been radio silent on
the bitcoin-dev list and yet we see a stream of media articles, blog
posts, pod casts, and from what I can tell ongoing backroom lobbying
of companies to run bitcoin-XT without trying AT ALL to offer a
neutral or balanced or multi proposal information package so that
companies technical people can make a balanced informed decision.
That is what the workshops are trying to provide.

Gavin, Mike - anything to say here?

Adam

On 18 August 2015 at 19:59, Angel Leon via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> "How then to end this XT madness?"
>
> Instead of bashing on someone that has actually put a solution forward, make
> your own fork and see if your ideas on how to solve the issue are any
> better.
>
> As of now, 1Mb blocks are pure madness, and people are voting over an 8mb
> block increase every day that passes, even with a "useless project" like you
> call it.
>
> Go out there and see how bitcoin is actually used.
>
> http://twitter.com/gubatron
>
> On Tue, Aug 18, 2015 at 10:54 PM, odinn via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> The "XT Fork" (better said, a POS alt*) and those behind it make not
>> even a pretense to work through process involved with bitcoin developmen
>> t.
>>
>> (*This is not intended as a slight toward any other alts, as here in
>> this post I am focusing solely on XT.)
>>
>> Instead of abandoning their useless project, or at least conceding
>> that their alt is operating essentially outside of the development
>> funnel (by this I mean BIP process), the developers of XT, via their
>> latest presentation of XT give nothing more than an attack on bitcoin
>> (albeit one that, more than anything, is designed to sidetrack real
>> discussion necessary to resolve the issues so as to achieve some level
>> of consensus in block size debates). Curiously, XT is not even truly
>> the implementation of BIP 101; the actual proposed implementation of
>> BIP 101 as proposed at
>> https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#implement
>> ation
>> is found here: https://github.com/bitcoin/bitcoin/pull/6341
>> (It is currently a closed issue.)
>>
>> It's probably valid to call into question why Mike Hearn in particular
>> persists with this project at all, as he has been its biggest
>> cheerleader. Some reasons may be:
>> 1) His interest in attacking bitcoin in the past (seems to be a
>> recurring pattern)
>> https://bitcointalk.org/index.php?topic=333824.0
>>
>> 2) His employment (has come up before) - QinetiQ, Google, etc
>> https://plus.google.com/+MikeHearn/about - it's simply not
>> unreasonable to ask why he's pushing it so hard when nobody wants it.
>>
>> 3) Various reasons mentioned here:
>> https://www.reddit.com/r/Bitcoin/comments/39yaug/the_history_of_mike_hea
>> rn_and_why_you_should_not/
>>
>>
>> 4) His disinterest in following what is actually happening with votes
>> on legitimate proposals (e.g. Garzik's BIP 100) in the blocks. (Caveat
>> ~ one doesn't see the BIP 100 yet in bitcoin/bips because it won't
>> appear for another couple weeks, supposedly. The miners' voting is
>> already happening however.) Even according to http://xtnodes.com/ we
>> see that XT runs minimal nodes in comparison to the rest of nodes
>> being run across the network.
>>
>> BIP 100 itself is anticipated to be submitted w/ implementation in the
>> next 2 weeks and many miners are already voting on BIP 100 (as per
>> Jeff Garzik, from a post 08/12/2015 12:46 PM -0400 to this mailing list)
>> .
>>
>> It is an insult to see Hearn fling the XT turd into the community
>> repeatedly.
>>
>> How then to end this XT madness?
>>
>> "The ring was made in the fires of Mount Doom. Only there can it be
>> unmade. The ring must be taken deep into Mordor and cast back into the
>> fiery chasm from whence it came. One of you must do this."
>> - - Lord Elrond
>>
>> Do not download this loathsome XT thing. Cast it back into the fires
>> from whence it came.
>>
>> - -Odinn
>>
>>
>> On 08/15/2015 10:43 AM, Satoshi Nakamoto via bitcoin-dev wrote:
>> > I have been following the recent block size debates through the
>> > mailing list. I had hoped the debate would resolve and that a fork
>> > proposal would achieve widespread consensus. However with the
>> > formal release of Bitcoin XT 0.11A, this looks unlikely to happen,
>> > and so I am forced to share my concerns about this very dangerous
>> > fork.
>> >
>> > The developers of this pretender-Bitcoin claim to be following my
>> > original vision, but nothing could be further from the truth. When
>> > I designed Bitcoin, I designed it in such a way as to make future
>> > modifications to the consensus rules difficult without near
>> > unanimous agreement. Bitcoin was designed to be protected from the
>> > influence of charismatic leaders, even if their name is Gavin
>> > Andresen, Barack Obama, or Satoshi Nakamoto. Nearly everyone has
>> > to agree on a change, and they have to do it without being forced
>> > or pressured into it. By doing a fork in this way, these
>> > developers are violating the "original vision" they claim to
>> > honour.
>> >
>> > They use my old writings to make claims about what Bitcoin was
>> > supposed to be. However I acknowledge that a lot has changed since
>> > that time, and new knowledge has been gained that contradicts some
>> > of my early opinions. For example I didn't anticipate pooled
>> > mining and its effects on the security of the network. Making
>> > Bitcoin a competitive monetary system while also preserving its
>> > security properties is not a trivial problem, and we should take
>> > more time to come up with a robust solution. I suspect we need a
>> > better incentive for users to run nodes instead of relying solely
>> > on altruism.
>> >
>> > If two developers can fork Bitcoin and succeed in redefining what
>> > "Bitcoin" is, in the face of widespread technical criticism and
>> > through the use of populist tactics, then I will have no choice but
>> > to declare Bitcoin a failed project. Bitcoin was meant to be both
>> > technically and socially robust. This present situation has been
>> > very disappointing to watch unfold.
>> >
>> > Satoshi Nakamoto
>> >
>> > _______________________________________________ bitcoin-dev mailing
>> > list bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>> - --
>> http://abis.io ~
>> "a protocol concept to enable decentralization
>> and expansion of a giving economy, and a new social good"
>> https://keybase.io/odinn
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJV0+/fAAoJEGxwq/inSG8C4ZAIAKm1pEne0FlOW1O4zLe6mZOz
>> YTcnpSHFiVw4AfUPgbzR813ODphnJqcwnoT1q/sojjqgIDtwZY+AqdjA3VAbe15D
>> bAPlvQGmXMlaXq8OteDYPKxPzQMUlRtxEd9+sxO5IGFx0kvmKQLzdk6cmgawcRhN
>> PrDyXIqLlx6Yp0REQ03v3poLTGojUkPLeqdMrJAjwpuAyv9F8iVUn7SeHemEi8cm
>> fW4wOJogA8j9P//3a7+Cr8bjnOz6+QwpHsdlZlKM4VUTxt3Vgx4vu+SQjQxWgZEK
>> I+HGvgQW1buoDxleBbFq6SJc55lhF41IB17tewuDuPzT2nL4zOkbis1tUk3ASxY=
>> =Rm7w
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-08-19 📝 Original ...

2023-06-07T19:35:33+02:00

In reply to nevent1q…l6cr
_________________________

📅 Original date posted:2015-08-19
📝 Original message:Wouldnt the experience for SPV nodes be chaotic? If the full nodes
are 50:50 XT and bitcoin core, then SPV clients would connect at
random and because XT and core will diverge immediately after
activation.

Adam

On 19 August 2015 at 15:28, Jorge Timón
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 19, 2015 at 5:41 PM, s7r <s7r at sky-ip.org> wrote:
>> Hello Jorge, Eric,
>>
>> With all this noise on the -dev mail list I had to implement application
>> level filters so I can treat with priority posts from certain people,
>> you are on that list. While I agree with your arguments, I think it is
>> _very_ important to highlight some things. I am neither for the
>> blocksize increase neither against it, because plain and simple I don't
>> have enough arguments to take some definitive decision on this topic.
>
> I think everyone is in that position (we just don't have enough data
> about the proposed sizes) or it's just too optimistic.
>
>> What I am angry about is spreading FUD that a fork could kill Bitcoin
>> and what we are experiencing now is somehow terrible.
>>
>> 1. Bitcoin XT is not necessarily an attack over Bitcoin and will not
>> split it into 2 different coins. It is the result of an open source free
>> system which lacks centralization. It is just at early stage, it could
>> have thousands for forks (or fork attempts) during its life.
>
> Bitcoin XT is just a software fork and nobody seem to have a problem
> with that (as repeated in other threads), people are worried about the
> way bip101 is going to be attempted to be deployed using Bitcoin XT.
> We already have more than 5000 software forks and that's totally fine.
>
> A Schism fork may not kill Bitcoin but it will certainly create 2
> different coins.
> The claim that "there will be a winner and everybody will just move
> there" is incredibly naive and uninformative.
> Many people will sell their xtbtc and reject the hardfork
> independently of its support by miners.
> Nobody knows what the result will be, but both currencies' prices
> dropping near zero is certainly a possibility that Gavin and Mike are
> not aware about or are not informing their followers about.
> Here's something a little bit longer about this topic:
> https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR137
> Note the last part:
>
> "
> +This is very disruptive and hopefully will never be needed. But if
> +it's needed the best deployment path is just to activate the rule
> +changes after certain block height in the future. On the other hand,
> +it is healthy decentralization-wise that many independent software
> +projects are ready to deploy a schism hardfork.
> "
>
>> 2. We have no proof that Mike Hearn and Gavin Andresen are trying to do
>> something bad to Bitcoin. So far everything they have done is (or should
>> be) allowed. They have forked an open source software and implemented a
>> voting system for a consensus rule change - doesn't sound like they are
>> committing a crime here (either legally or morally). If they are
>> qualified enough to maintain the software, or if the decision is
>> technically correct or not is another story, and it should only matter
>> to whoever uses / wants to use -XT.
>
> Again, no problem with the code fork, but the Schism hardfork is very
> risky regardless of their intentions.
>
>> 3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
>> just by 2 people forking the software and submitting a consensus rule to
>> a vote, it means Bitcoin is dead already and it should be worthless! We
>> can't go around and panic every time somebody forks Bitcoin and tries to
>> change something - this should be allowed by the nature of its license.
>> If tomorrow 5 more people fork 5 different software implementing the
>> bitcoin protocol and submit 5 different new consensus rules to a vote,
>> then what? We should all sell so the price will drop to 1 cent, because
>> it is somehow not good enough, not stable enough?
>
> If they don't extensively lobby Bitcoin companies, they don't start a
> massive PR campaign labbeling other developers as "obstructionists"
> and don't misinform a big part of the Bitcoin users (often using
> logical fallacies, intentionally or not), probably those 5 new
> currencies will be ignored and nothing bad will happen.
> Unfortunately in this case a great division between users is being created.
>
>> I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
>> block in the future spends all the longest dusted coins to me, out of
>> which I give away 50% to the miners (so the hashing power will have
>> incentive to use my fork).
>>
>> Can they do it? YES
>> Will they do it? NO
>> Should the world care about this? NO
>>
>> It's as simple as that. We cannot continue to panic that "Bitcoin as a
>> project" is at threat because somebody forked it.
>
> Can you please stop conflating "Bitcoin Core as a project" and
> "Bitcoin consensus rules".
> They are different things and nobody is or can be "in charge" of the
> later, face it.
>
> Can you please also stop conflating software fork and
> "Schism/controversial/contentious hardfork"? Nobody has anything
> against the former and as you point out it is allowed by its free
> software license.
>
>> 4. By having a software fork and consensus rule submitted to vote we
>> actually prove how open Bitcoin is, and how there is lack of control
>> over it from all parties (developers, miners, engineers on the mail
>> list). This is reason to increase Bitcoin's value! It is a feature, not
>> a flaw!
>
> Why should miners have a voting power that the rest of the users lack?
>
>> It's very important for everyone in the ecosystem to understand:
>>
>> - yes, Bitcoin is open source, even you can fork it tomorrow if you want
>> and you think enough users might follow you.
>>
>> - no, it's not a requirement for 100% of the nodes in the network to be
>> running Core, or -XT or other implementation. The more we have, the better.
>>
>> - yes, there is absolutely no authority in Bitcoin - this is what lead
>> to this dispute in the first place. This is the truly decentralized
>> nature of the software, not important if we have 10.000 full nodes or
>> 1000 full nodes.
>
> All this sounds reasonable.
>
>> - no, Bitcoin won't split / die or whatever because of this fork.
>> Regardless what it happens, if XT will reach the threshold or not,
>> Bitcoin will go on just because it has some unique advantages and has no
>> competitor from some points of view.
>
> But you cannot know this will happen this way!
> If the threshold is reached (let's forget about noXT for now), the
> remaining miners cannot be forced to adopt bip101.
> And users can never be forced to adopt hardforks.
> It is possible that 75% of the hashrate moves to the bip101 chain
> while 99% of the users remain in the old Bitcoin chain. Or 50/50,
> 40/60...nobody knows.
>
>> - Bitcoin by its design has many many advantages, but also the
>> limitation that it relies on majority being honest / doing the right
>> thing! This is just the way it is, and the benefits it is offering
>> heavily win over this fundamental limitation.
>
> No, it doesn't rely on that. It just relies on the majority of the
> miners not attacking the network for too long (ie the number of
> confirmations people are waiting).
> If I'm running a full node, I'm not isolated from the network and the
> majority of the hashrate is not reorging the chain I am safe no matter
> how dishonest the "majority" (whatever that means in this context) is.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2015-08-16 📝 Original message:Hi ...

2023-06-07T19:35:26+02:00

In reply to nevent1q…rr72
_________________________

📅 Original date posted:2015-08-16
📝 Original message:Hi Tamas

Do you find BIP 101, BIP 102, BIP 103 and the flexcap proposal
deserving of equal consideration? Just curious because of your post.

Will you be interested to participate in the BIP review process and
perhaps attend the workshop on Bitcoin scaling announced here
recently?

Adam

On 16 August 2015 at 17:07, Tamas Blummer via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Being a bitcoin software developer an entrepreneur for years I learned that success is not a direct consequence of technology and is not inevitable.
> BitcoinXT manifesto (https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) should resonate with many fellow entrepreneurs.
> I applaud Mike and Gavin for creating that choice for us.
>
> Tamas Blummer
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-08-11 📝 Original message:I ...

2023-06-07T19:34:05+02:00

In reply to nevent1q…znz5
_________________________

📅 Original date posted:2015-08-11
📝 Original message:I think everyone is expending huge effort on design, analysis and
implementation of the lowest cost technology for Bitcoin.

Changing parameters doesnt create progress on scalability fundamentals -
there really is an inherent cost and security / throughput tradeoff to
blockchains. Security is quite central to this discussion. It is
unrealistic in my opinion to suppose that everything can fit directly
on-chain in the fullest Bitcoin adoption across cash-payments, internet of
things, QoS, micropayments, share-trading, derivates etc. Hence the
interest in protocols like lightning (encourage you and others to read the
paper, blog posts and implementation progress on the lightning-dev mailing
list).

Mid-term different tradeoffs can happen that are all connected to and
building on Bitcoin. But whatever technologies win out for scale, they all
depend on Bitcoin security - anything built on Bitcoin requires a secure
base. So I think it is logical that we strive to maintain and improve
Bitcoin security. Long-term tradeoffs that significantly weaken security
for throughput or other considerations should be built on top of Bitcoin,
and avoiding creating a one-size fits all unfortunate compromise that
weakens Bitcoin to the lowest common denominator of centralisation,
insecurity and throughput tradeoffs. This pattern (secure base, other
protocols built on top) is already the status quo - probably > 99% of
Bitcoin transactions are off-chain already (in exchanges, web wallets
etc). And there are various things that can and are being done to improve
the security of those solutions, with provable reserves, periodic on-chain
settlement, netting, lightning like protocols and other things probably
still to be invented.

Some of the longer term things we probably dont know yet, but the future is
NOT bleak. Lots of scope for technology improvement.

Adam

On 11 August 2015 at 20:26, Michael Naber via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> All things considered, if people want to participate in a global consensus
> network, and the technology exist to do it at a lower cost, then is it
> sensible or even possible to somehow arbitrarily set the price of
> participating in a global consensus network to be expensive? Can someone
> please walk me through how that's expected to play out because I'm really
> having a hard time understanding how it could work.
>
>
>
> On Tue, Aug 11, 2015 at 2:00 PM, Mark Friedenbach via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> More people using Bitcoin does not necessarily mean more transactions
>> being processed by the block chain. Satoshi was forward-thinking enough to
>> include a powerful script-signature system, something which has never
>> really existed before. Though suffering from some limitations to be sure,
>> this smart contract execution framework is expressive enough to enable a
>> wide variety of new features without changing bitcoin itself.
>>
>> One of these invented features is micropayment channels -- the ability
>> for two parties to rapidly exchange funds while only settling the final
>> balance to the block chain, and to do so in an entirely trustless way.
>> Right now people don't use scripts to do interesting things like this, but
>> there is absolutely no reason why they can't. Lightning network is a vision
>> of a future where everyone uses a higher-layer protocol for their
>> transactions which only periodically settle on the block chain. It is
>> entirely possible that you may be able to do all your day-to-day
>> transactions in bitcoin yet only settle accounts every other week, totaling
>> 13kB per year. A 1MB block could support that level of usage by 4 million
>> people, which is many orders of magnitude more than the number of people
>> presently using bitcoin on a day to day basis.
>>
>> And that, by the way, is without considering as-yet uninvented
>> applications of existing or future script which will provide even further
>> improvements to scale. This is very fertile ground being explored by very
>> few people. One thing I hope to come out of this block size debate is a lot
>> more people (like Joseph Poon) looking at how bitcoin script can be used to
>> enable new and innovative resource-efficient and privacy-enhancing payment
>> protocols.
>>
>> The network has room to grow. It just requires wallet developers and
>> other infrastructure folk to step up to the plate and do their part in
>> deploying this technology.
>>
>> On Tue, Aug 11, 2015 at 2:14 AM, Angel Leon <gubatron at gmail.com> wrote:
>>
>>> - policy neutrality.
>>> - It can't be censored.
>>> - it can't be shut down
>>> - and the rules cannot change from underneath you.
>>>
>>> except it can be shutdown the minute it actually gets used by its
>>> inability to scale.
>>>
>>> what's the point of having all this if nobody can use it?
>>> what's the point of going through all that energy and CO2 for a mere
>>> 24,000 transactions an hour?
>>>
>>> It's clear that it's just a matter of time before it collapses.
>>>
>>> Here's a simple proposal (concept) that doesn't pretend to set a fixed
>>> block size limit as you can't ever know the demands the future will bring
>>> https://gist.github.com/gubatron/143e431ee01158f27db4
>>>
>>> We don't need to go as far as countries with hyper inflation trying to
>>> use the technology to make it collapse, anybody here who has distributed
>>> commercial/free end user software knows that any small company out there
>>> installs more copies in a couple weeks than all the bitcoin users we have
>>> at the moment, all we need is a single company/project with a decent amount
>>> of users who are now enabled to transact directly on the blockchain to
>>> screw it all up (perhaps OpenBazaar this winter could make this whole thing
>>> come down, hopefully they'll take this debate and the current limitations
>>> before their release, and boy are they coding nonstop on it now that they
>>> got funded), the last of your fears should be a malicious government trying
>>> to shut you down, for that to happen you must make an impact first, for now
>>> this is a silly game in the grand scheme of things.
>>>
>>> And you did sound pretty bad, all of his points were very valid and they
>>> share the concern of many people, many investors, entrepreneurs putting
>>> shitload of money, time and their lives on a much larger vision than that
>>> of a network that does a mere 3,500 tx/hour, but some people seem to be
>>> able to live in impossible or useless ideals.
>>>
>>> It's simply irresponsible to not want to give the network a chance to
>>> grow a bit more. Miners centralizing is inevitable given the POW based
>>> consensus, hobbists-mining is only there for countries with very cheap
>>> energy.
>>>
>>> If things remain this way, this whole thing will be a massive failure
>>> and it will probably take another decade before we can open our mouths
>>> about cryptocurrencies, decentralization and what not, and this stubornness
>>> will be the one policy that censored everyone, that shutdown everyone, that
>>> made the immutable rules not matter.
>>>
>>> Perhaps it will be Stellar what ends up delivering at this stubborn pace.
>>>
>>> http://twitter.com/gubatron
>>>
>>> On Tue, Aug 11, 2015 at 4:38 AM, Thomas Zander via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> >It follows then, that if we make a decision now which destroys that
>>>> property, which makes it possible to censor bitcoin, to deny service, or to
>>>> pressure miners into changing rules contrary to user interests, then
>>>> Bitcoin is no longer interesting.
>>>>
>>>> You asked to be convinced of the need for bigger blocks. I gave that.
>>>> What makes you think bitcoin will break when more people use it?
>>>>
>>>> Sent on the go, excuse the brevity.
>>>> *From: *Mark Friedenbach
>>>> *Sent: *Tuesday, 11 August 2015 08:10
>>>> *To: *Thomas Zander
>>>> *Cc: *Bitcoin Dev
>>>> *Subject: *Re: [bitcoin-dev] Fees and the block-finding process
>>>>
>>>> On Mon, Aug 10, 2015 at 11:31 PM, Thomas Zander via bitcoin-dev <
>>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>>
>>>>> On Monday 10. August 2015 23.03.39 Mark Friedenbach wrote:
>>>>> > This is where things diverge. It's fine to pick a new limit or growth
>>>>> > trajectory. But defend it with data and reasoned analysis.
>>>>>
>>>>> We currently serve about 0,007% of the world population sending maybe
>>>>> one
>>>>> transaction a month.
>>>>> This can only go up.
>>>>>
>>>>> There are about 20 currencies in the world that are unstable and
>>>>> showing early
>>>>> signs of hyperinflation. If even small percentage of these people
>>>>> cash-out and
>>>>> get Bitcoins for their savings you'd have the amount of people using
>>>>> Bitcoin
>>>>> as savings go from maybe half a million to 10 million in the space of
>>>>> a couple
>>>>> of months. Why so fast? Because all the world currencies are linked.
>>>>> Practically all currencies follow the USD, and while that one may stay
>>>>> robust
>>>>> and standing, the linkage has been shown in the past to cause
>>>>> chain-effects.
>>>>>
>>>>> It is impossible to predict how much uptake Bitcoin will take, but we
>>>>> have
>>>>> seen big rises in price as Cyprus had a bailin and then when Greece
>>>>> first
>>>>> showed bad signs again.
>>>>> Lets do our due diligence and agree that in the current world economy
>>>>> there
>>>>> are sure signs that people are considering Bitcoin on a big scale.
>>>>>
>>>>> Bigger amount of people holding Bitcoin savings won't make the
>>>>> transaction
>>>>> rate go up very much, but if you have feet on the ground you already
>>>>> see that
>>>>> people go back to barter in countries like Poland, Ireland, Greece etc.
>>>>> And Bitcoin will be an alternative to good to ignore. Then
>>>>> transaction rates
>>>>> will go up. Dramatically.
>>>>>
>>>>> If you are asking for numbers, that is a bit tricky. Again; we are at
>>>>> 0,007%... Thats like a f-ing rounding error in the world economy. You
>>>>> can't
>>>>> reason from that. Its like using a float to do calculations that you
>>>>> should
>>>>> have done in a double and getting weird output.
>>>>>
>>>>> Bottom line is that a maximum size of 8Mb blocks is not that odd.
>>>>> Because a 20
>>>>> times increase is very common in a "company" that is about 6 years old.
>>>>> For instance Android was about that age when it started to get shipped
>>>>> by non-
>>>>> Google companies. There the increase was substantially bigger and the
>>>>> company
>>>>> backing it was definitely able to change direction faster than the
>>>>> Bitcoin
>>>>> oiltanker can change direction.
>>>>>
>>>>> ...
>>>>>
>>>>> Another metric to remember; if you follow hackernews (well, the
>>>>> incubator more
>>>>> than the linked articles) you'd be exposed to the thinking of these
>>>>> startups.
>>>>> Their only criteria is growth. and this is rather substantial growth.
>>>>> Like
>>>>> 150% per month. Naturally, most of these build on top of html or other
>>>>> existing technologies. But the point is that exponential growth is
>>>>> expected
>>>>> in any startup. They typically have a much much more agressive
>>>>> timeline,
>>>>> though. Every month instead of every year.
>>>>> Having exponential growth in the blockchain is really not odd and even
>>>>> if we
>>>>> have LN or sidechains or the next changetip, this space will be used.
>>>>> And we
>>>>> will still have scarcity.
>>>>
>>>>
>>>> I'm sorry, I really don't want to sound like a jerk, but not a single
>>>> word of that mattered. Yes we all want Bitcoin to scale such that every
>>>> person in the world can use it without difficulty. However if that were all
>>>> that we cared about then I would be remiss if I did not point out that
>>>> there are plenty of better, faster, and cheaper solutions to finding global
>>>> consensus over a payment ledger than Bitcoin. Architectures which are
>>>> algorithmically superior in their scaling properties. Indeed they are
>>>> already implemented and you can use them today:
>>>>
>>>> https://www.stellar.org/
>>>> http://opentransactions.org/
>>>>
>>>> So why do I work on Bitcoin, and why do I care about the outcome of
>>>> this debate? Because Bitcoin offers one thing, and one thing only which
>>>> alternative architectures fundamentally lack: policy neutrality. It can't
>>>> be censored, it can't be shut down, and the rules cannot change from
>>>> underneath you. *That* is what Bitcoin offers that can't be replicated at
>>>> higher scale with a SQL database and an audit log.
>>>>
>>>> It follows then, that if we make a decision now which destroys that
>>>> property, which makes it possible to censor bitcoin, to deny service, or to
>>>> pressure miners into changing rules contrary to user interests, then
>>>> Bitcoin is no longer interesting. We might as well get rid of mining at
>>>> that point and make Bitcoin look like Stellar or Open-Transactions because
>>>> at least then we'd scale even better and not be pumping millions of tons of
>>>> CO2 into the atmosphere from running all those ASICs.
>>>>
>>>> On the other side, 3Tb harddrives are sold, which take 8Mb blocks
>>>>> without
>>>>> problems.
>>>>>
>>>>
>>>> Straw man, storage is not an issue.
>>>>
>>>>
>>>>> You can buy broadband in every relevant country that easily supports
>>>>> the
>>>>> bandwidth we need. (remember we won't jump to 8Mb in a day, it will
>>>>> likely
>>>>> take at least 6 months).
>>>>>
>>>>
>>>> Neither one of those assertions is clear. Keep in mind the goal is to
>>>> have Bitcoin survive active censorship. Presumably that means being able to
>>>> run a node even in the face of a hostile ISP or government. Furthermore, it
>>>> means being location independent and being able to move around. In many
>>>> places the higher the bandwidth requirements the fewer the number of ISPs
>>>> that are available to service you, and the more visible you are.
>>>>
>>>> It may also be necessary to be able to run over Tor. And not just
>>>> today's Tor which is developed, serviced, and supported by the US
>>>> government, but a Tor or I2P that future governments have turned hostile
>>>> towards and actively censor or repress. Or existing authoritative
>>>> governments, for that matter. How much bandwidth would be available through
>>>> those connections?
>>>>
>>>> It may hopefully never be necessary to operate under such constraints,
>>>> except by freedom seeking individuals within existing totalitarian regimes.
>>>> However the credible threat of doing so may be what keeps Bitcoin from
>>>> being repressed in the first place. Lose the capability to go underground,
>>>> and it will be pressured into regulation, eventually.
>>>>
>>>> To the second point, it has been previously pointed out that large
>>>> miners stand to gain from larger blocks, for the same basic underlying
>>>> reasons as selfish mining. The incentive is to increase blocks, and miners
>>>> are able to do so at will and without cost. I would not be so certain that
>>>> we wouldn't see large blocks sooner than that.
>>>>
>>>>
>>>>> We should get the inverted bloom filters stuff (or competing products)
>>>>> working
>>>>> at least on a one-to-one basis so we can solve the propagation time
>>>>> problem.
>>>>> There frankly is a huge amount of optimization that can be done in
>>>>> that area,
>>>>> we don't even use locality (pingtime) to optimize distribution.
>>>>> From my experience you can expect a 2-magnitude speedup in that same 6
>>>>> month
>>>>> period by focusing some research there.
>>>>>
>>>>
>>>> This is basically already deployed thanks to Matt's relay network.
>>>> Further improvements are not going to have dramatic effects.
>>>>
>>>>
>>>>> Remember 8Gb/block still doesn't support VISA/Mastercard.
>>>>>
>>>>
>>>> No, it doesn't. And 8GB/block is ludicrously large -- it would
>>>> absolutely, without any doubt destroy the very nature of Bitcoin, turning
>>>> it into a fundamentally uninteresting reincarnation of the existing
>>>> financial system. And still be unable to compete with VISA/Mastercard.
>>>>
>>>> So why then the pressure to go down a route that WILL lead to failure
>>>> by your own metrics?
>>>>
>>>> I humbly suggest that maybe we should play the strengths of Bitcoin
>>>> instead -- it's trustlessness via policy neutrality.
>>>>
>>>> Either that, or go work on Stellar. Because that's where it's headed
>>>> otherwise.
>>>>
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>>
>>>>
>>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150811/d025c85c/attachment-0001.html>;

📅 Original date posted:2015-08-11 📝 Original message:So if ...

2023-06-07T19:33:47+02:00

In reply to nevent1q…gkh4
_________________________

📅 Original date posted:2015-08-11
📝 Original message:So if they dont care about decentralisation, they'll be happy using
cheaper off-chain systems, right?

Adam

On 11 August 2015 at 22:30, Angel Leon <gubatron at gmail.com> wrote:
> tell that to people in poor countries, or even in first world countries. The
> competitive thing here is a deal breaker for a lot of people who have no
> clue/don't care for decentralization, they just want to send money from A to
> B, like email.
>
> http://twitter.com/gubatron
>
> On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I dont think Bitcoin being cheaper is the main characteristic of
>> Bitcoin. I think the interesting thing is trustlessness - being able
>> to transact without relying on third parties.
>>
>> Adam
>>
>>
>> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > The only reason why Bitcoin has grown the way it has, and in fact the
>> > only
>> > reason why we're all even here on this mailing list talking about this,
>> > is
>> > because Bitcoin is growing, since it's "better money than other money".
>> > One
>> > of the key characteristics toward that is Bitcoin being inexpensive to
>> > transact. If that characteristic is no longer true, then Bitcoin isn't
>> > going
>> > to grow, and in fact Bitcoin itself will be replaced by better money
>> > that is
>> > less expensive to transfer.
>> >
>> > So the importance of this issue cannot be overstated -- it's compete or
>> > die
>> > for Bitcoin -- because people want to transact with global consensus at
>> > high
>> > volume, and because technology exists to service that want, then it's
>> > going
>> > to be met. This is basic rules of demand and supply. I don't necessarily
>> > disagree with your position on only wanting to support uncontroversial
>> > commits, but I think it's important to get consensus on the criticality
>> > of
>> > the block size issue: do you agree, disagree, or not take a side, and
>> > why?
>> >
>> >
>> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <pieter.wuille at gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>
>> >>> Hitting the limit in and of itself is not necessarily a bad thing. The
>> >>> question at hand is whether we should constrain that limit below what
>> >>> technology is capable of delivering. I'm arguing that not only we
>> >>> should
>> >>> not, but that we could not even if we wanted to, since competition
>> >>> will
>> >>> deliver capacity for global consensus whether it's in Bitcoin or in
>> >>> some
>> >>> other product / fork.
>> >>
>> >>
>> >> The question is not what the technology can deliver. The question is
>> >> what
>> >> price we're willing to pay for that. It is not a boolean "at this size,
>> >> things break, and below it, they work". A small constant factor
>> >> increase
>> >> will unlikely break anything in the short term, but it will come with
>> >> higher
>> >> centralization pressure of various forms. There is discussion about
>> >> whether
>> >> these centralization pressures are significant, but citing that it's
>> >> artificially constrained under the limit is IMHO a misrepresentation.
>> >> It is
>> >> constrained to aim for a certain balance between utility and risk, and
>> >> neither extreme is interesting, while possibly still "working".
>> >>
>> >> Consensus rules are what keeps the system together. You can't simply
>> >> switch to new rules on your own, because the rest of the system will
>> >> end up
>> >> ignoring you. These rules are there for a reason. You and I may agree
>> >> about
>> >> whether the 21M limit is necessary, and disagree about whether we need
>> >> a
>> >> block size limit, but we should be extremely careful with change. My
>> >> position as Bitcoin Core developer is that we should merge consensus
>> >> changes
>> >> only when they are uncontroversial. Even when you believe a more
>> >> invasive
>> >> change is worth it, others may disagree, and the risk from disagreement
>> >> is
>> >> likely larger than the effect of a small block size increase by itself:
>> >> the
>> >> risk that suddenly every transaction can be spent twice (once on each
>> >> side
>> >> of the fork), the very thing that the block chain was designed to
>> >> prevent.
>> >>
>> >> My personal opinion is that we should aim to do a block size increase
>> >> for
>> >> the right reasons. I don't think fear of rising fees or unreliability
>> >> should
>> >> be an issue: if fees are being paid, it means someone is willing to pay
>> >> them. If people are doing transactions despite being unreliable, there
>> >> must
>> >> be a use for them. That may mean that some use cases don't fit anymore,
>> >> but
>> >> that is already the case.
>> >>
>> >> --
>> >> Pieter
>> >>
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

📅 Original date posted:2015-08-11 📝 Original message:I dont ...

2023-06-07T19:33:46+02:00

In reply to nevent1q…ft7n
_________________________

📅 Original date posted:2015-08-11
📝 Original message:I dont think Bitcoin being cheaper is the main characteristic of
Bitcoin. I think the interesting thing is trustlessness - being able
to transact without relying on third parties.

Adam

On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The only reason why Bitcoin has grown the way it has, and in fact the only
> reason why we're all even here on this mailing list talking about this, is
> because Bitcoin is growing, since it's "better money than other money". One
> of the key characteristics toward that is Bitcoin being inexpensive to
> transact. If that characteristic is no longer true, then Bitcoin isn't going
> to grow, and in fact Bitcoin itself will be replaced by better money that is
> less expensive to transfer.
>
> So the importance of this issue cannot be overstated -- it's compete or die
> for Bitcoin -- because people want to transact with global consensus at high
> volume, and because technology exists to service that want, then it's going
> to be met. This is basic rules of demand and supply. I don't necessarily
> disagree with your position on only wanting to support uncontroversial
> commits, but I think it's important to get consensus on the criticality of
> the block size issue: do you agree, disagree, or not take a side, and why?
>
>
> On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>>
>> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Hitting the limit in and of itself is not necessarily a bad thing. The
>>> question at hand is whether we should constrain that limit below what
>>> technology is capable of delivering. I'm arguing that not only we should
>>> not, but that we could not even if we wanted to, since competition will
>>> deliver capacity for global consensus whether it's in Bitcoin or in some
>>> other product / fork.
>>
>>
>> The question is not what the technology can deliver. The question is what
>> price we're willing to pay for that. It is not a boolean "at this size,
>> things break, and below it, they work". A small constant factor increase
>> will unlikely break anything in the short term, but it will come with higher
>> centralization pressure of various forms. There is discussion about whether
>> these centralization pressures are significant, but citing that it's
>> artificially constrained under the limit is IMHO a misrepresentation. It is
>> constrained to aim for a certain balance between utility and risk, and
>> neither extreme is interesting, while possibly still "working".
>>
>> Consensus rules are what keeps the system together. You can't simply
>> switch to new rules on your own, because the rest of the system will end up
>> ignoring you. These rules are there for a reason. You and I may agree about
>> whether the 21M limit is necessary, and disagree about whether we need a
>> block size limit, but we should be extremely careful with change. My
>> position as Bitcoin Core developer is that we should merge consensus changes
>> only when they are uncontroversial. Even when you believe a more invasive
>> change is worth it, others may disagree, and the risk from disagreement is
>> likely larger than the effect of a small block size increase by itself: the
>> risk that suddenly every transaction can be spent twice (once on each side
>> of the fork), the very thing that the block chain was designed to prevent.
>>
>> My personal opinion is that we should aim to do a block size increase for
>> the right reasons. I don't think fear of rising fees or unreliability should
>> be an issue: if fees are being paid, it means someone is willing to pay
>> them. If people are doing transactions despite being unreliable, there must
>> be a use for them. That may mean that some use cases don't fit anymore, but
>> that is already the case.
>>
>> --
>> Pieter
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-08-07 📝 Original message:Please ...

2023-06-07T19:33:38+02:00

In reply to nevent1q…6m8y
_________________________

📅 Original date posted:2015-08-07
📝 Original message:Please try to focus on constructive technical comments.

On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> What will the backlash be when people here that are pushing for "off-chain-
> transactions" fail to produce a properly working alternative, which
> essentially means we have to say NO to more users.

But > 99% of Bitcoin transactions are already off-chain. There are
multiple competing companies offering consumer & retail service with
off-chain settlement.

I wasnt clear but it seemed in your previous mail that you seemed to
say you dont mind trusting other people with your money, and so
presumably you are OK using these services, and so have no problem?

> At this time and this size of bitcoin community, my personal experience (and
> I've been part of many communities) saying NO to new customers

Who said no to anything? The systems of off-chain transfer already
exist and are by comparison to Bitcoins protocol simple and rapid to
adapt and scale.

Indications are that we can even do off-chain at scale with Bitcoin
similar trust-minimisation with lightning, and duplex payment
channels; and people are working on that right now.

I think it would be interesting and useful for someone, with an
interest in low trust, high scale transactions, to work on and propose
an interoperability standard and API for such off-chain services to be
accessed by wallets, and perhaps periodic on-chain inter-service
netting.

Adam

📅 Original date posted:2015-08-07 📝 Original message:On 7 ...

2023-06-07T19:33:25+02:00

In reply to nevent1q…e2zg
_________________________

📅 Original date posted:2015-08-07
📝 Original message:On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> the need an individual has for running a node is a completely different concept than the
> need for nodes to exist. And, really, you are describing miners, not nodes.

It's not as simple as trusting miners, Bitcoin security needs some
reasonable portion of economic interest to be validating their receipt
of coins against a full node they run.

I do it myself because I dont want to lose money, as do many power
users. Most bitcoin ecosystem companies do it. You dont have to run
it all the time, just sync it when you want to check your own coin
receipt with higher assurance.

> As we concluded in our previous email, the need to run a node is inversely
> proportional to the ability (or willingness) to trust others.

Even if you are willing to trust others, trusting miners or random
full nodes would be unsafe if not for the reasonable portion of
economic interest validating their own received coins. That holds
miners honest, otherwise they could more easily present fake
information to SPV users.

> And lets face it, practically everyone trusts others with their money today.

Bitcoin's very reason for existence is to avoid that need. For people
fully happy to trust others with their money, Bitcoin may not be as
interesting to them.

>> If the impact of the system goes u[p], so should the - joint - incentives to
>> keep it secure. And I think we're (slowly) failing at that.
>
> That is your opinion.

What Pieter said is an accurate summary and non-controversial.

Adam

📅 Original date posted:2016-01-07 📝 Original message:You ...

2023-06-07T19:31:28+02:00

In reply to nevent1q…p406
_________________________

📅 Original date posted:2016-01-07
📝 Original message:You could say 256 bit ECDSA is overkill lets go to 160 equivalently.
Saves even more bytes.

The problem with arguing down is where to stop.

As Matt said these things dont degrade gracefully so a best practice
is to aim for a bit of extra margin.

256-bit is quite common at this point since AES, SHA256 etc even in
things with much less at stake than Bitcoin.

You could send the compressed (unhashed) pubkey then there's no hash
(and omit it from the sig). Greg had mentioned that in the past.

I think it might be possible to do both (reclaim the hash bits in the
serialisation of the pub key).

Adam

On 7 January 2016 at 20:02, Gavin Andresen via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I'm hoisting this from some private feedback I sent on the segregated
> witness BIP:
>
> I said:
>
> "I'd also use RIPEMD160(SHA256()) as the hash function and save the 12
> bytes-- a successful preimage attack against that ain't gonna happen before
> we're all dead. I'm probably being dense, but I just don't see how a
> collision attack is relevant here."
>
> Pieter responded:
>
> "The problem case is where someone in a contract setup shows you a script,
> which you accept as being a payment to yourself. An attacker could use a
> collision attack to construct scripts with identical hashes, only one of
> which does have the property you want, and steal coins.
>
> So you really want collision security, and I don't think 80 bits is
> something we should encourage for that. Normal pubkey hashes don't have that
> problem, as they can't be constructed to pay to you."
>
> ... but I'm unconvinced:
>
> "But it is trivial for contract wallets to protect against collision
> attacks-- if you give me a script that is "gavin_pubkey CHECKSIG
> arbitrary_data OP_DROP" with "I promise I'm not trying to rip you off, just
> ignore that arbitrary data" a wallet can just refuse. Even more likely, a
> contract wallet won't even recognize that as a pay-to-gavin transaction.
>
> I suppose it could be looking for some form of "gavin_pubkey
> somebody_else_pubkey CHECKMULTISIG ... with the attacker using
> somebody_else_pubkey to force the collision, but, again, trivial contract
> protocol tweaks ("send along a proof you have the private key corresponding
> to the public key" or "everybody pre-commits pubkeys they'll use at protocol
> start") would protect against that.
>
> Adding an extra 12 bytes to every segwit to prevent an attack that takes
> 2^80 computation and 2^80 storage, is unlikely to be a problem in practice,
> and is trivial to protect against is the wrong tradeoff to make."
>
> 20 bytes instead of 32 bytes is a savings of almost 40%, which is
> significant.
>
> The general question I'd like to raise on this list is:
>
> Should we be worried, today, about collision attacks against RIPEMD160 (our
> 160-bit hash)?
>
> Mounting a successful brute-force collision attack would require at least
> O(2^80) CPU, which is kinda-sorta feasible (Pieter pointed out that Bitcoin
> POW has computed more SHA256 hashes than that). But it also requires O(2^80)
> storage, which is utterly infeasible (there is something on the order of
> 2^35 bytes of storage in the entire world). Even assuming doubling every
> single year (faster than Moore's Law), we're four decades away from an
> attacker with THE ENTIRE WORLD's storage capacity being able to mount a
> collision attack.
>
>
> References:
>
> https://en.wikipedia.org/wiki/Collision_attack
>
> https://vsatglobalseriesblog.wordpress.com/2013/06/21/in-2013-the-amount-of-data-generated-worldwide-will-reach-four-zettabytes/
>
>
> --
> --
> Gavin Andresen
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-08-23 📝 Original message:Some ...

2023-06-07T17:49:27+02:00

In reply to nevent1q…44yl
_________________________

📅 Original date posted:2015-08-23
📝 Original message:Some comments:

"(i) remove any possibility of free transactions unless

associated with basic transaction data;"

I believe it is not possible to prevent free transactions for the
reason that people can pay out of band (via existing banking transfers
to miners) or make payments to addresses belonging to miners (that are
contingent on the requested user transaction being processed via input
dependency) .

I am not sure I fully understand the way you see monetisation working,
and you do indicate this is quite far future what-if stage idea, and
you do identify a conflict with fungibility - but I think this is
probably quite badly in conflict with fungibility to the point of
conflicting with many planned Bitcoin improvements? And mid term
technical directions.

I would say the long term idealised requirements are that the
transaction itself would have cryptographic fungibility, and policy
relating to identity for authorisation, approval in regulated
transactions would take place at the payment protocol layer. The
payment protocol is already seeing some use.

Lightning protocol sees more of the data going point to point and so
not broadcast nor visible for big data analytic monetisation.

Adam

On 22 August 2015 at 23:51, Jorge Timón
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Again, did you got a bip number asigned or did you self-assigned it yourself?
>
> On Sat, Aug 22, 2015 at 1:01 PM, Ahmed Zsales via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Hello,
>>
>> In response to public and private comments and feedback, we have updated
>> this working draft.
>>
>> https://drive.google.com/file/d/0BwEbhrQ4ELzBOUVtOHJQdlhvUmc/view?usp=sharing
>>
>> Update highlights:
>>
>> 1. Specific clarifications on replacing the Coinbase subsidy and
>> supplementing and not replacing transaction fees.
>>
>> 2. Clarification on block chain overhead. The value of data mining is on a
>> bell curve, so year six data will be removed every year.
>>
>> 3. Added references to an ability to create global, national and regional
>> Bitcoin Price Indices for popular baskets of goods transacted with Bitcoin.
>>
>> 4. Added references for an ability to use structured block chain data for
>> Bitcoin capacity and fork planning.
>>
>> 5. Removed references to price speculation.
>>
>> 6. Added preferences for deployment dates of January 2017 or January 2018.
>>
>> 7. Moving towards BIP format after discussion and evaluation period.
>> Technical content will increase in due course and discussion content will be
>> removed.
>>
>> Further views and feedback welcome.
>>
>> Regards,
>>
>> Ahmed
>>
>>
>> On Mon, Aug 17, 2015 at 5:23 PM, Ahmed Zsales <ahmedzsales18 at gmail.com>
>> wrote:
>>>
>>> Hello,
>>>
>>> Here we propose a long-term solution to replace mining rewards and
>>> transactions fees.
>>>
>>> BIP 104 is currently a discussion draft only.
>>>
>>>
>>> https://drive.google.com/file/d/0BwEbhrQ4ELzBSXpoUjRkc01QUGc/view?usp=sharing
>>>
>>> Views and feedback welcome.
>>>
>>> Regards,
>>>
>>> Ahmed
>>>
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2015-08-17 📝 Original message:Thank ...

2023-06-07T17:47:45+02:00

In reply to nevent1q…j34p
_________________________

📅 Original date posted:2015-08-17
📝 Original message:Thank you Eric for saying what needs to be said.

Starting a fork war is just not constructive and there are multiple
proposals being evaluated here.

I think that one thing that is not being so much focussed on is
Bitcoin-XT is both a hard-fork and a soft-fork. It's a hard-fork on
Bitcoin full-nodes, but it is also a soft-fork attack on Bitcoin core
SPV nodes that did not opt-in. It exposes those SPV nodes to loss in
the likely event that Bitcoin-XT results in a network-split.

The recent proposal here to run noXT (patch to falsely claim to mine
on XT while actually rejecting it's blocks) could add enough
uncertainty about the activation that Bitcoin-XT would probably have
to be aborted.

Adam

On 17 August 2015 at 15:03, Eric Lombrozo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> NxtChg,
>
> In the entire history of Bitcoin we’ve never attempted anything even closely resembling a hard fork like what’s being proposed here.
>
> Many of us have wanted to push our own hard-forking changes to the protocol…and have been frustrated because of the inability to do so.
>
> This inability is not due to any malice on anyone’s part…it is a feature of Satoshi’s protocol. For better or worse, it is *very hard* to change the rules…and this is exactly what imbues Bitcoin with one of its most powerful attributes: very well-defined settlement guarantees that cannot be suddenly altered nor reversed by anyone.
>
> We’ve managed to have a few soft forks in the past…and for the most part these changes have been pretty uncontroversial…or at least, they have not had nearly the level of political divisiveness that this block size issue is having. And even then, we’ve encountered a number of problems with these deployments that have at times required goodwill cooperation between developers and mining pool operators to fix.
>
> Again, we have NEVER attempted anything even remotely like what’s being proposed - we’ve never done any sort of hard fork before like this. If even fairly uncontroversial soft forks have caused problems, can you imagine the kinds of potential problems that a hard fork over some highly polarizing issue might raise? Do you really think people are going to want to cooperate?!?
>
> I can understand that some people would like bigger blocks. Other people might want feature X, others feature Y…and we can argue the merits of this or that to death…but the fact remains that we have NEVER attempted any hard forking change…not even with a simple, totally uncontroversial no-brainer improvement that would not risk any sort of ill-will that could hamper remedies were it not to go as smoothly as we like. *THIS* is the fundamental problem - the whole bigger block thing is a minor issue by comparison…it could be any controversial change, really.
>
> Would you want to send your test pilots on their first flight…the first time an aircraft is ever flown…directly into combat without having tested the plane? This is what attempting a hard fork mechanism that’s NEVER been done before in such a politically divisive environment basically amounts to…but it’s even worse. We’re basically risking the entire air force (not just one plane) over an argument regarding how many seats a plane should have that we’ve never flown before.
>
> We’re talking billlions of dollars’ worth of other people’s money that is on the line here. Don’t we owe it to them to at least test out the system on a far less controversial, far less divisive change first to make sure we can even deploy it without things breaking? I don’t even care about the merits regarding bigger blocks vs. smaller blocks at this point, to be quite honest - that’s such a petty thing compared to what I’m talking about here. If we attempt a novel hard-forking mechanism that’s NEVER been attempted before (and which as many have pointed out is potentially fraught with serious problems) on such a politically divisive, polarizing issue, the result is each side will refuse to cooperate with the other out of spite…and can easily lead to a war, tanking the value of everyone’s assets on both chains. All so we can process 8 times the number of transactions we currently do? Even if it were 100 times, we wouldn’t even come close to touching big payment processors like Visa. It’s hard to imagine a protocol improvement that’s worth the risk.
>
> I urge you to at least try to see the bigger picture here…and to understand that nobody is trying to stop anyone from doing anything out of some desire for maintaining control - NONE of us are able to deploy hard forks right now without facing these problems. And different people obviously have different priorities and preferences as to which of these changes would be best to do first. This whole XT thing is essentially giving *one* proposal special treatment above those that others have proposed. Many of us have only held back from doing this out of our belief that goodwill amongst network participants is more important than trying to push some pet feature some of us want.
>
> Please stop this negativity - we ALL want the best for Bitcoin and are doing our best, given what we understand and know, to do what’s right.

📅 Original date posted:2015-08-19 📝 Original message:It ...

2023-06-07T17:47:30+02:00

In reply to nevent1q…8hku
_________________________

📅 Original date posted:2015-08-19
📝 Original message:It seems to be a recurring meme that BIP 101 is somehow "a solution
put forward" where BIP 100, 102, 103, flexcap, extension blocks etc
etc are not.

That is not at ALL the case, and is insulting (present company excluded).

It is just that no one else is reckless enough to bypass the review
process and risk a controversial hard fork deployment war. Myself and
many other people warned Gavin a network fork "war" would start (ie
someone would think of some way to sabotage or attack the deployment
of Bitcoin-XT via protocol, code, policy, consensus soft-fork etc. He
ignored the warnings. Many also warned that 75% was an optimally BAD
trigger ratio (and that in a hard fork it is not a miner vote really
as in soft-forks). Gavin & Mike ignored that warning to. I know they
heard those warnings because I told them 1:1 in person or via email
and had on going conversations. Others did too.

People can not blame bitcoin core or me, that this then predictably
happened exactly as we said it would - it was completely obvious and
predictable.

In fact noBitcoinXT is even more dangerous and therefore amplified in
effect in creating mutual assured destruction kind of risk profile
than the loose spectrum of technical counters imagined. I did not
personally put much effort into thinking about counters because I
though it counter productive and hoped that Gavin & Mike would have
the maturity to not start down such a path.

Again any of the other proposals can easily be implemented. They
*could* also spin up a web page and put up binaries, however no one
else was crazy enough to try to start a deployment in that way.

It is also puzzling timing - with all these BIPs and ongoing
discussion and workshops coming imminently to then release ahead of
that process where as far as I know Gavin said he was equally happy
with BIP 100 or other proposal which ever is best, and on basically
the eve of workshops planned to progress this collaboratively.
Bitcoin-XT is also under tested, people are finding privacy bugs and
other issues. (Not even mentioning the above 75% optimally bad
parameter, and the damage to community reputation and collaborative
environment that this all causes.)

Very disappointing Gavin and Mike.

I find it quite notable that Gavin and Mike have been radio silent on
the bitcoin-dev list and yet we see a stream of media articles, blog
posts, pod casts, and from what I can tell ongoing backroom lobbying
of companies to run bitcoin-XT without trying AT ALL to offer a
neutral or balanced or multi proposal information package so that
companies technical people can make a balanced informed decision.
That is what the workshops are trying to provide.

Gavin, Mike - anything to say here?

Adam

On 18 August 2015 at 19:59, Angel Leon via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> "How then to end this XT madness?"
>
> Instead of bashing on someone that has actually put a solution forward, make
> your own fork and see if your ideas on how to solve the issue are any
> better.
>
> As of now, 1Mb blocks are pure madness, and people are voting over an 8mb
> block increase every day that passes, even with a "useless project" like you
> call it.
>
> Go out there and see how bitcoin is actually used.
>
> http://twitter.com/gubatron
>
> On Tue, Aug 18, 2015 at 10:54 PM, odinn via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> The "XT Fork" (better said, a POS alt*) and those behind it make not
>> even a pretense to work through process involved with bitcoin developmen
>> t.
>>
>> (*This is not intended as a slight toward any other alts, as here in
>> this post I am focusing solely on XT.)
>>
>> Instead of abandoning their useless project, or at least conceding
>> that their alt is operating essentially outside of the development
>> funnel (by this I mean BIP process), the developers of XT, via their
>> latest presentation of XT give nothing more than an attack on bitcoin
>> (albeit one that, more than anything, is designed to sidetrack real
>> discussion necessary to resolve the issues so as to achieve some level
>> of consensus in block size debates). Curiously, XT is not even truly
>> the implementation of BIP 101; the actual proposed implementation of
>> BIP 101 as proposed at
>> https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki#implement
>> ation
>> is found here: https://github.com/bitcoin/bitcoin/pull/6341
>> (It is currently a closed issue.)
>>
>> It's probably valid to call into question why Mike Hearn in particular
>> persists with this project at all, as he has been its biggest
>> cheerleader. Some reasons may be:
>> 1) His interest in attacking bitcoin in the past (seems to be a
>> recurring pattern)
>> https://bitcointalk.org/index.php?topic=333824.0
>>
>> 2) His employment (has come up before) - QinetiQ, Google, etc
>> https://plus.google.com/+MikeHearn/about - it's simply not
>> unreasonable to ask why he's pushing it so hard when nobody wants it.
>>
>> 3) Various reasons mentioned here:
>> https://www.reddit.com/r/Bitcoin/comments/39yaug/the_history_of_mike_hea
>> rn_and_why_you_should_not/
>>
>>
>> 4) His disinterest in following what is actually happening with votes
>> on legitimate proposals (e.g. Garzik's BIP 100) in the blocks. (Caveat
>> ~ one doesn't see the BIP 100 yet in bitcoin/bips because it won't
>> appear for another couple weeks, supposedly. The miners' voting is
>> already happening however.) Even according to http://xtnodes.com/ we
>> see that XT runs minimal nodes in comparison to the rest of nodes
>> being run across the network.
>>
>> BIP 100 itself is anticipated to be submitted w/ implementation in the
>> next 2 weeks and many miners are already voting on BIP 100 (as per
>> Jeff Garzik, from a post 08/12/2015 12:46 PM -0400 to this mailing list)
>> .
>>
>> It is an insult to see Hearn fling the XT turd into the community
>> repeatedly.
>>
>> How then to end this XT madness?
>>
>> "The ring was made in the fires of Mount Doom. Only there can it be
>> unmade. The ring must be taken deep into Mordor and cast back into the
>> fiery chasm from whence it came. One of you must do this."
>> - - Lord Elrond
>>
>> Do not download this loathsome XT thing. Cast it back into the fires
>> from whence it came.
>>
>> - -Odinn
>>
>>
>> On 08/15/2015 10:43 AM, Satoshi Nakamoto via bitcoin-dev wrote:
>> > I have been following the recent block size debates through the
>> > mailing list. I had hoped the debate would resolve and that a fork
>> > proposal would achieve widespread consensus. However with the
>> > formal release of Bitcoin XT 0.11A, this looks unlikely to happen,
>> > and so I am forced to share my concerns about this very dangerous
>> > fork.
>> >
>> > The developers of this pretender-Bitcoin claim to be following my
>> > original vision, but nothing could be further from the truth. When
>> > I designed Bitcoin, I designed it in such a way as to make future
>> > modifications to the consensus rules difficult without near
>> > unanimous agreement. Bitcoin was designed to be protected from the
>> > influence of charismatic leaders, even if their name is Gavin
>> > Andresen, Barack Obama, or Satoshi Nakamoto. Nearly everyone has
>> > to agree on a change, and they have to do it without being forced
>> > or pressured into it. By doing a fork in this way, these
>> > developers are violating the "original vision" they claim to
>> > honour.
>> >
>> > They use my old writings to make claims about what Bitcoin was
>> > supposed to be. However I acknowledge that a lot has changed since
>> > that time, and new knowledge has been gained that contradicts some
>> > of my early opinions. For example I didn't anticipate pooled
>> > mining and its effects on the security of the network. Making
>> > Bitcoin a competitive monetary system while also preserving its
>> > security properties is not a trivial problem, and we should take
>> > more time to come up with a robust solution. I suspect we need a
>> > better incentive for users to run nodes instead of relying solely
>> > on altruism.
>> >
>> > If two developers can fork Bitcoin and succeed in redefining what
>> > "Bitcoin" is, in the face of widespread technical criticism and
>> > through the use of populist tactics, then I will have no choice but
>> > to declare Bitcoin a failed project. Bitcoin was meant to be both
>> > technically and socially robust. This present situation has been
>> > very disappointing to watch unfold.
>> >
>> > Satoshi Nakamoto
>> >
>> > _______________________________________________ bitcoin-dev mailing
>> > list bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>>
>> - --
>> http://abis.io ~
>> "a protocol concept to enable decentralization
>> and expansion of a giving economy, and a new social good"
>> https://keybase.io/odinn
>> -----BEGIN PGP SIGNATURE-----
>> Version: GnuPG v1
>>
>> iQEcBAEBAgAGBQJV0+/fAAoJEGxwq/inSG8C4ZAIAKm1pEne0FlOW1O4zLe6mZOz
>> YTcnpSHFiVw4AfUPgbzR813ODphnJqcwnoT1q/sojjqgIDtwZY+AqdjA3VAbe15D
>> bAPlvQGmXMlaXq8OteDYPKxPzQMUlRtxEd9+sxO5IGFx0kvmKQLzdk6cmgawcRhN
>> PrDyXIqLlx6Yp0REQ03v3poLTGojUkPLeqdMrJAjwpuAyv9F8iVUn7SeHemEi8cm
>> fW4wOJogA8j9P//3a7+Cr8bjnOz6+QwpHsdlZlKM4VUTxt3Vgx4vu+SQjQxWgZEK
>> I+HGvgQW1buoDxleBbFq6SJc55lhF41IB17tewuDuPzT2nL4zOkbis1tUk3ASxY=
>> =Rm7w
>> -----END PGP SIGNATURE-----
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-08-19 📝 Original ...

2023-06-07T17:47:18+02:00

In reply to nevent1q…q5kc
_________________________

📅 Original date posted:2015-08-19
📝 Original message:Wouldnt the experience for SPV nodes be chaotic? If the full nodes
are 50:50 XT and bitcoin core, then SPV clients would connect at
random and because XT and core will diverge immediately after
activation.

Adam

On 19 August 2015 at 15:28, Jorge Timón
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 19, 2015 at 5:41 PM, s7r <s7r at sky-ip.org> wrote:
>> Hello Jorge, Eric,
>>
>> With all this noise on the -dev mail list I had to implement application
>> level filters so I can treat with priority posts from certain people,
>> you are on that list. While I agree with your arguments, I think it is
>> _very_ important to highlight some things. I am neither for the
>> blocksize increase neither against it, because plain and simple I don't
>> have enough arguments to take some definitive decision on this topic.
>
> I think everyone is in that position (we just don't have enough data
> about the proposed sizes) or it's just too optimistic.
>
>> What I am angry about is spreading FUD that a fork could kill Bitcoin
>> and what we are experiencing now is somehow terrible.
>>
>> 1. Bitcoin XT is not necessarily an attack over Bitcoin and will not
>> split it into 2 different coins. It is the result of an open source free
>> system which lacks centralization. It is just at early stage, it could
>> have thousands for forks (or fork attempts) during its life.
>
> Bitcoin XT is just a software fork and nobody seem to have a problem
> with that (as repeated in other threads), people are worried about the
> way bip101 is going to be attempted to be deployed using Bitcoin XT.
> We already have more than 5000 software forks and that's totally fine.
>
> A Schism fork may not kill Bitcoin but it will certainly create 2
> different coins.
> The claim that "there will be a winner and everybody will just move
> there" is incredibly naive and uninformative.
> Many people will sell their xtbtc and reject the hardfork
> independently of its support by miners.
> Nobody knows what the result will be, but both currencies' prices
> dropping near zero is certainly a possibility that Gavin and Mike are
> not aware about or are not informing their followers about.
> Here's something a little bit longer about this topic:
> https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR137
> Note the last part:
>
> "
> +This is very disruptive and hopefully will never be needed. But if
> +it's needed the best deployment path is just to activate the rule
> +changes after certain block height in the future. On the other hand,
> +it is healthy decentralization-wise that many independent software
> +projects are ready to deploy a schism hardfork.
> "
>
>> 2. We have no proof that Mike Hearn and Gavin Andresen are trying to do
>> something bad to Bitcoin. So far everything they have done is (or should
>> be) allowed. They have forked an open source software and implemented a
>> voting system for a consensus rule change - doesn't sound like they are
>> committing a crime here (either legally or morally). If they are
>> qualified enough to maintain the software, or if the decision is
>> technically correct or not is another story, and it should only matter
>> to whoever uses / wants to use -XT.
>
> Again, no problem with the code fork, but the Schism hardfork is very
> risky regardless of their intentions.
>
>> 3. If Bitcoin's value can be decreased (or Bitcoin as a project killed)
>> just by 2 people forking the software and submitting a consensus rule to
>> a vote, it means Bitcoin is dead already and it should be worthless! We
>> can't go around and panic every time somebody forks Bitcoin and tries to
>> change something - this should be allowed by the nature of its license.
>> If tomorrow 5 more people fork 5 different software implementing the
>> bitcoin protocol and submit 5 different new consensus rules to a vote,
>> then what? We should all sell so the price will drop to 1 cent, because
>> it is somehow not good enough, not stable enough?
>
> If they don't extensively lobby Bitcoin companies, they don't start a
> massive PR campaign labbeling other developers as "obstructionists"
> and don't misinform a big part of the Bitcoin users (often using
> logical fallacies, intentionally or not), probably those 5 new
> currencies will be ignored and nothing bad will happen.
> Unfortunately in this case a great division between users is being created.
>
>> I can fork tomorrow Bitcoin Core to a Bitcoin-XYZ software which at some
>> block in the future spends all the longest dusted coins to me, out of
>> which I give away 50% to the miners (so the hashing power will have
>> incentive to use my fork).
>>
>> Can they do it? YES
>> Will they do it? NO
>> Should the world care about this? NO
>>
>> It's as simple as that. We cannot continue to panic that "Bitcoin as a
>> project" is at threat because somebody forked it.
>
> Can you please stop conflating "Bitcoin Core as a project" and
> "Bitcoin consensus rules".
> They are different things and nobody is or can be "in charge" of the
> later, face it.
>
> Can you please also stop conflating software fork and
> "Schism/controversial/contentious hardfork"? Nobody has anything
> against the former and as you point out it is allowed by its free
> software license.
>
>> 4. By having a software fork and consensus rule submitted to vote we
>> actually prove how open Bitcoin is, and how there is lack of control
>> over it from all parties (developers, miners, engineers on the mail
>> list). This is reason to increase Bitcoin's value! It is a feature, not
>> a flaw!
>
> Why should miners have a voting power that the rest of the users lack?
>
>> It's very important for everyone in the ecosystem to understand:
>>
>> - yes, Bitcoin is open source, even you can fork it tomorrow if you want
>> and you think enough users might follow you.
>>
>> - no, it's not a requirement for 100% of the nodes in the network to be
>> running Core, or -XT or other implementation. The more we have, the better.
>>
>> - yes, there is absolutely no authority in Bitcoin - this is what lead
>> to this dispute in the first place. This is the truly decentralized
>> nature of the software, not important if we have 10.000 full nodes or
>> 1000 full nodes.
>
> All this sounds reasonable.
>
>> - no, Bitcoin won't split / die or whatever because of this fork.
>> Regardless what it happens, if XT will reach the threshold or not,
>> Bitcoin will go on just because it has some unique advantages and has no
>> competitor from some points of view.
>
> But you cannot know this will happen this way!
> If the threshold is reached (let's forget about noXT for now), the
> remaining miners cannot be forced to adopt bip101.
> And users can never be forced to adopt hardforks.
> It is possible that 75% of the hashrate moves to the bip101 chain
> while 99% of the users remain in the old Bitcoin chain. Or 50/50,
> 40/60...nobody knows.
>
>> - Bitcoin by its design has many many advantages, but also the
>> limitation that it relies on majority being honest / doing the right
>> thing! This is just the way it is, and the benefits it is offering
>> heavily win over this fundamental limitation.
>
> No, it doesn't rely on that. It just relies on the majority of the
> miners not attacking the network for too long (ie the number of
> confirmations people are waiting).
> If I'm running a full node, I'm not isolated from the network and the
> majority of the hashrate is not reorging the chain I am safe no matter
> how dishonest the "majority" (whatever that means in this context) is.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2015-08-16 📝 Original message:Hi ...

2023-06-07T17:47:13+02:00

In reply to nevent1q…40pw
_________________________

📅 Original date posted:2015-08-16
📝 Original message:Hi Tamas

Do you find BIP 101, BIP 102, BIP 103 and the flexcap proposal
deserving of equal consideration? Just curious because of your post.

Will you be interested to participate in the BIP review process and
perhaps attend the workshop on Bitcoin scaling announced here
recently?

Adam

On 16 August 2015 at 17:07, Tamas Blummer via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Being a bitcoin software developer an entrepreneur for years I learned that success is not a direct consequence of technology and is not inevitable.
> BitcoinXT manifesto (https://github.com/bitcoinxt/bitcoinxt#the-xt-manifesto) should resonate with many fellow entrepreneurs.
> I applaud Mike and Gavin for creating that choice for us.
>
> Tamas Blummer
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-08-08 📝 Original message:If you ...

2023-06-07T17:46:20+02:00

In reply to nevent1q…9dr2
_________________________

📅 Original date posted:2015-08-08
📝 Original message:If you are saying that some people are happy trusting other people,
and so would be perfectly fine with off-chain use of Bitcoin, then we
agree and I already said that off-chain use case would be a
constructive thing for someone to improve scale and interoperability
of in the post you are replying to. However that use case is not a
strong argument for weakening Bitcoin's security to get to more scale
for that use case.

In a world where we could have scale and decentralisation, then of
course it would be nice to provide people with that outlook more
security than they seem to want. And sometimes people dont understand
why security is useful until it goes wrong, so it would be a useful
thing to do. (Like insurance, your money being seized by paypal out
of the blue etc). And indeed providing security at scale maybe
possible with lightning like protocols that people are working on.

Adam

📅 Original date posted:2015-08-11 📝 Original message:So if ...

2023-06-07T17:45:54+02:00

In reply to nevent1q…aw76
_________________________

📅 Original date posted:2015-08-11
📝 Original message:So if they dont care about decentralisation, they'll be happy using
cheaper off-chain systems, right?

Adam

On 11 August 2015 at 22:30, Angel Leon <gubatron at gmail.com> wrote:
> tell that to people in poor countries, or even in first world countries. The
> competitive thing here is a deal breaker for a lot of people who have no
> clue/don't care for decentralization, they just want to send money from A to
> B, like email.
>
> http://twitter.com/gubatron
>
> On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> I dont think Bitcoin being cheaper is the main characteristic of
>> Bitcoin. I think the interesting thing is trustlessness - being able
>> to transact without relying on third parties.
>>
>> Adam
>>
>>
>> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > The only reason why Bitcoin has grown the way it has, and in fact the
>> > only
>> > reason why we're all even here on this mailing list talking about this,
>> > is
>> > because Bitcoin is growing, since it's "better money than other money".
>> > One
>> > of the key characteristics toward that is Bitcoin being inexpensive to
>> > transact. If that characteristic is no longer true, then Bitcoin isn't
>> > going
>> > to grow, and in fact Bitcoin itself will be replaced by better money
>> > that is
>> > less expensive to transfer.
>> >
>> > So the importance of this issue cannot be overstated -- it's compete or
>> > die
>> > for Bitcoin -- because people want to transact with global consensus at
>> > high
>> > volume, and because technology exists to service that want, then it's
>> > going
>> > to be met. This is basic rules of demand and supply. I don't necessarily
>> > disagree with your position on only wanting to support uncontroversial
>> > commits, but I think it's important to get consensus on the criticality
>> > of
>> > the block size issue: do you agree, disagree, or not take a side, and
>> > why?
>> >
>> >
>> > On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <pieter.wuille at gmail.com>
>> > wrote:
>> >>
>> >> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
>> >> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >>>
>> >>> Hitting the limit in and of itself is not necessarily a bad thing. The
>> >>> question at hand is whether we should constrain that limit below what
>> >>> technology is capable of delivering. I'm arguing that not only we
>> >>> should
>> >>> not, but that we could not even if we wanted to, since competition
>> >>> will
>> >>> deliver capacity for global consensus whether it's in Bitcoin or in
>> >>> some
>> >>> other product / fork.
>> >>
>> >>
>> >> The question is not what the technology can deliver. The question is
>> >> what
>> >> price we're willing to pay for that. It is not a boolean "at this size,
>> >> things break, and below it, they work". A small constant factor
>> >> increase
>> >> will unlikely break anything in the short term, but it will come with
>> >> higher
>> >> centralization pressure of various forms. There is discussion about
>> >> whether
>> >> these centralization pressures are significant, but citing that it's
>> >> artificially constrained under the limit is IMHO a misrepresentation.
>> >> It is
>> >> constrained to aim for a certain balance between utility and risk, and
>> >> neither extreme is interesting, while possibly still "working".
>> >>
>> >> Consensus rules are what keeps the system together. You can't simply
>> >> switch to new rules on your own, because the rest of the system will
>> >> end up
>> >> ignoring you. These rules are there for a reason. You and I may agree
>> >> about
>> >> whether the 21M limit is necessary, and disagree about whether we need
>> >> a
>> >> block size limit, but we should be extremely careful with change. My
>> >> position as Bitcoin Core developer is that we should merge consensus
>> >> changes
>> >> only when they are uncontroversial. Even when you believe a more
>> >> invasive
>> >> change is worth it, others may disagree, and the risk from disagreement
>> >> is
>> >> likely larger than the effect of a small block size increase by itself:
>> >> the
>> >> risk that suddenly every transaction can be spent twice (once on each
>> >> side
>> >> of the fork), the very thing that the block chain was designed to
>> >> prevent.
>> >>
>> >> My personal opinion is that we should aim to do a block size increase
>> >> for
>> >> the right reasons. I don't think fear of rising fees or unreliability
>> >> should
>> >> be an issue: if fees are being paid, it means someone is willing to pay
>> >> them. If people are doing transactions despite being unreliable, there
>> >> must
>> >> be a use for them. That may mean that some use cases don't fit anymore,
>> >> but
>> >> that is already the case.
>> >>
>> >> --
>> >> Pieter
>> >>
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> >
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

📅 Original date posted:2015-08-11 📝 Original message:I dont ...

2023-06-07T17:45:52+02:00

In reply to nevent1q…vnjc
_________________________

📅 Original date posted:2015-08-11
📝 Original message:I dont think Bitcoin being cheaper is the main characteristic of
Bitcoin. I think the interesting thing is trustlessness - being able
to transact without relying on third parties.

Adam

On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> The only reason why Bitcoin has grown the way it has, and in fact the only
> reason why we're all even here on this mailing list talking about this, is
> because Bitcoin is growing, since it's "better money than other money". One
> of the key characteristics toward that is Bitcoin being inexpensive to
> transact. If that characteristic is no longer true, then Bitcoin isn't going
> to grow, and in fact Bitcoin itself will be replaced by better money that is
> less expensive to transfer.
>
> So the importance of this issue cannot be overstated -- it's compete or die
> for Bitcoin -- because people want to transact with global consensus at high
> volume, and because technology exists to service that want, then it's going
> to be met. This is basic rules of demand and supply. I don't necessarily
> disagree with your position on only wanting to support uncontroversial
> commits, but I think it's important to get consensus on the criticality of
> the block size issue: do you agree, disagree, or not take a side, and why?
>
>
> On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <pieter.wuille at gmail.com>
> wrote:
>>
>> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>> Hitting the limit in and of itself is not necessarily a bad thing. The
>>> question at hand is whether we should constrain that limit below what
>>> technology is capable of delivering. I'm arguing that not only we should
>>> not, but that we could not even if we wanted to, since competition will
>>> deliver capacity for global consensus whether it's in Bitcoin or in some
>>> other product / fork.
>>
>>
>> The question is not what the technology can deliver. The question is what
>> price we're willing to pay for that. It is not a boolean "at this size,
>> things break, and below it, they work". A small constant factor increase
>> will unlikely break anything in the short term, but it will come with higher
>> centralization pressure of various forms. There is discussion about whether
>> these centralization pressures are significant, but citing that it's
>> artificially constrained under the limit is IMHO a misrepresentation. It is
>> constrained to aim for a certain balance between utility and risk, and
>> neither extreme is interesting, while possibly still "working".
>>
>> Consensus rules are what keeps the system together. You can't simply
>> switch to new rules on your own, because the rest of the system will end up
>> ignoring you. These rules are there for a reason. You and I may agree about
>> whether the 21M limit is necessary, and disagree about whether we need a
>> block size limit, but we should be extremely careful with change. My
>> position as Bitcoin Core developer is that we should merge consensus changes
>> only when they are uncontroversial. Even when you believe a more invasive
>> change is worth it, others may disagree, and the risk from disagreement is
>> likely larger than the effect of a small block size increase by itself: the
>> risk that suddenly every transaction can be spent twice (once on each side
>> of the fork), the very thing that the block chain was designed to prevent.
>>
>> My personal opinion is that we should aim to do a block size increase for
>> the right reasons. I don't think fear of rising fees or unreliability should
>> be an issue: if fees are being paid, it means someone is willing to pay
>> them. If people are doing transactions despite being unreliable, there must
>> be a use for them. That may mean that some use cases don't fit anymore, but
>> that is already the case.
>>
>> --
>> Pieter
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-08-07 📝 Original message:Please ...

2023-06-07T17:45:45+02:00

In reply to nevent1q…d40m
_________________________

📅 Original date posted:2015-08-07
📝 Original message:Please try to focus on constructive technical comments.

On 7 August 2015 at 23:12, Thomas Zander via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> What will the backlash be when people here that are pushing for "off-chain-
> transactions" fail to produce a properly working alternative, which
> essentially means we have to say NO to more users.

But > 99% of Bitcoin transactions are already off-chain. There are
multiple competing companies offering consumer & retail service with
off-chain settlement.

I wasnt clear but it seemed in your previous mail that you seemed to
say you dont mind trusting other people with your money, and so
presumably you are OK using these services, and so have no problem?

> At this time and this size of bitcoin community, my personal experience (and
> I've been part of many communities) saying NO to new customers

Who said no to anything? The systems of off-chain transfer already
exist and are by comparison to Bitcoins protocol simple and rapid to
adapt and scale.

Indications are that we can even do off-chain at scale with Bitcoin
similar trust-minimisation with lightning, and duplex payment
channels; and people are working on that right now.

I think it would be interesting and useful for someone, with an
interest in low trust, high scale transactions, to work on and propose
an interoperability standard and API for such off-chain services to be
accessed by wallets, and perhaps periodic on-chain inter-service
netting.

Adam

📅 Original date posted:2015-08-07 📝 Original message:On 7 ...

2023-06-07T17:45:34+02:00

In reply to nevent1q…ap2h
_________________________

📅 Original date posted:2015-08-07
📝 Original message:On 7 August 2015 at 22:35, Thomas Zander via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> the need an individual has for running a node is a completely different concept than the
> need for nodes to exist. And, really, you are describing miners, not nodes.

It's not as simple as trusting miners, Bitcoin security needs some
reasonable portion of economic interest to be validating their receipt
of coins against a full node they run.

I do it myself because I dont want to lose money, as do many power
users. Most bitcoin ecosystem companies do it. You dont have to run
it all the time, just sync it when you want to check your own coin
receipt with higher assurance.

> As we concluded in our previous email, the need to run a node is inversely
> proportional to the ability (or willingness) to trust others.

Even if you are willing to trust others, trusting miners or random
full nodes would be unsafe if not for the reasonable portion of
economic interest validating their own received coins. That holds
miners honest, otherwise they could more easily present fake
information to SPV users.

> And lets face it, practically everyone trusts others with their money today.

Bitcoin's very reason for existence is to avoid that need. For people
fully happy to trust others with their money, Bitcoin may not be as
interesting to them.

>> If the impact of the system goes u[p], so should the - joint - incentives to
>> keep it secure. And I think we're (slowly) failing at that.
>
> That is your opinion.

What Pieter said is an accurate summary and non-controversial.

Adam

📅 Original date posted:2015-08-10 📝 Original message:In ...

2023-06-07T17:45:22+02:00

In reply to nevent1q…3exm
_________________________

📅 Original date posted:2015-08-10
📝 Original message:In terms of usage I think you'd more imagine a wallet that basically
parks Bitcoins onto channels at all times, so long as they are
routable there is no loss, and the scalability achieved thereby is
strongly advantageous, and there is even the potential for users to
earn fees by having their wallets participate in channel rebalancing
(where hubs pay users to rebalance channels - end up with the same net
position but move funds from one user-owned channel to another.)
Exchange deposit, withdrawal, payments, even in-exchange trades can
usefully happen in lightning for faster, cheaper more scalable
transactions.

Adam

📅 Original date posted:2015-08-03 📝 Original message:Again ...

2023-06-07T17:44:38+02:00

In reply to nevent1q…2a7c
_________________________

📅 Original date posted:2015-08-03
📝 Original message:Again this should not be a political or business compromise model - we
must focus on scientific evaluation, technical requirements and
security.

But specifically as you asked a group of Chinese miners said they
would not run it:

http://cointelegraph.com/news/114657/chinese-mining-pools-call-for-consensus-refuse-switch-to-bitcoin-xt

Imagine if we had a nuclear reactor design criteria - we would not be
asking around with companies what parameter would they compromise on.
We'd be looking to scientific analysis of what is safe, based on
empirical and theoretical work on safety. If we're risking $4b of
other peoples money (and a little bit of mine) I would strongly want a
scientific approach.

A closer analogy would be the NIST SHA3 design process. With crypto
building blocks it is a security / speed tradeoff, a little analogous
to the security / throughput trade off in Bitcoin.

They do not ask companies or governments which algorithm they like or
what parameter they'd compromise on. They have a design competition
and analyse the algorithms and parameters for security margin and
speed optimisation in hardware and software. Much effort is put in
and it is very rigorous because a lot is at stake if they get it
wrong.

Adam

On 3 August 2015 at 09:34, Hector Chu <hectorchu at gmail.com> wrote:
> On 3 August 2015 at 08:16, Simon Liu via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Increasing the block size shouldn't be a problem for Chinese miners.
>> Five of the largest - F2Pool, Antpool, BW, BTCChina, Huobi - have
>> already signed a draft agreement indicating they are fine with an
>> increase to 8 MB: http://www.8btc.com/blocksize-increase-2
>
>
> What's the current stance of the Chinese pools on Bitcoin XT, should Bitcoin
> Core refuse to increase the block size to 8 MB in a timely fashion? Would
> they run it if the economic majority (e.g. Coinbase, Bitpay, etc.) publicly
> stated their support for big blocks?

📅 Original date posted:2015-08-03 📝 Original message:If ...

2023-06-07T17:44:37+02:00

In reply to nevent1q…9htk
_________________________

📅 Original date posted:2015-08-03
📝 Original message:If block-sizes are increased in a way detrimental to the Chinese miners, it
is not the Chinese miners that lose, it is all of the non-Chinese miners -
this is because the Chinese miners have the slight majority of the
hashrate. The relatively low external bandwidth connecting China to the
net is actually the problem of the non-Chinese miners problem. Non Chinese
miners will experience higher orphan rate once Chinese miners cease to
build on top of blocks that are too large to sync in a timely fashion into
China.

Adam

On 2 August 2015 at 23:02, Jim Phillips via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:

> China is a communist country. It is no secret that all "capitalist"
> enterprises are essentially State controlled, or at the very least are
> subject to nationalization should the State deem it necessary. Most ASIC
> chips are manufactured in China, so they are cheap and accessible to
> Chinese miners. Electricity is subsidized and essentially free. Cooling is
> not an issue since large parts of China are mountainous and naturally cool.
> In short the Chinese miners have HUGE advantages over all other mining
> operations. This is probably why, between just the top 4 Chinese miners,
> the People's Republic of China effectively controls 57% of all the Bitcoin
> being mined.
>
> The ONLY disadvantage the Chinese miners have in competing with the rest
> of the world is bandwidth. China has poor connectivity with the rest of the
> world, and Chinese miners have said that an increase in the block size
> would be detrimental to them. I say, GOOD! Most of the free world has
> enough bandwidth to be able to handle larger blocks. We need to take
> advantage of that fact to get mining out of the centralized control of the
> Chinese.
>
> If you're truly worried about larger blocks causing centralization, think
> about how, by restricting blocksize, you're enabling the Communist Chinese
> government to maintain centralized control over 57% of the Bitcoin hashing
> power.
>
> --
> *James G. Phillips IV*
> <https://plus.google.com/u/0/113107039501292625391/posts>;
> <http://www.linkedin.com/in/ergophobe>;
>
> *"Don't bunt. Aim out of the ball park. Aim for the company of immortals."
> -- David Ogilvy*
>
> *This message was created with 100% recycled electrons. Please think
> twice before printing.*
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150803/fca1c9e3/attachment-0001.html>;

📅 Original date posted:2015-07-30 📝 Original message:btw ...

2023-06-07T17:44:07+02:00

In reply to nevent1q…kdvt
_________________________

📅 Original date posted:2015-07-30
📝 Original message:btw the fact that mining is (or can be) anonymous also makes oligopoly
or cartel behaviour likely unstable. Miners can break ranks and
process transactions others wish to block, or with lower fees than a
cartel would like to charge, without detection.

Anonymous mining is a feature and helps ensure policy neutrality.

This is all overlaid by the 51% attack - if a coherent cartel arose
that could maintain 51% and had enough mutual self-interest to make
that stable, they could attack miners bypassing their cartel policies,
by orphaning their blocks. This is partly why mining decentralisation
is important. Also that is an overt act which is very detectable and
could lead to technical counter-measures by the users, who are in
ultimately in control of the protocol. So there is some game theory
suggesting it would be inadvisable for miners to be overt in cartel
attacks. Non overt attacks cant prevent anonymous under cutting of
cartel desired fee minimums.

Adam

On 29 July 2015 at 21:00, Adam Back <adam at cypherspace.org> wrote:
> On 29 July 2015 at 20:41, Ryan Butler via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Does an unlimited blocksize imply the lack of a fee market? Isn't every
>> miner able to set their minimum accepted fee or transaction acceptance
>> algorithm?
>
> The assumption is that wont work because any miner can break ranks and
> do so profitably, so to expect otherwise is to expect oligopoly
> behaviour which is the sort of antithesis of a decentralised mining
> system. It's in fact a similar argument as to why decentralisation of
> mining provides policy neutrality: some miner somewhere with some
> hashrate will process your transaction even if some other miners are
> by policy deciding not to mine it. It is also similar reason why free
> transactions are processed today - policies vary and this is good for
> ensuring many types of transaction get processed.
>
> Adam

📅 Original date posted:2015-07-30 📝 Original message:On 29 ...

2023-06-07T17:44:07+02:00

In reply to nevent1q…fyav
_________________________

📅 Original date posted:2015-07-30
📝 Original message:On 29 July 2015 at 20:41, Ryan Butler via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Does an unlimited blocksize imply the lack of a fee market? Isn't every
> miner able to set their minimum accepted fee or transaction acceptance
> algorithm?

The assumption is that wont work because any miner can break ranks and
do so profitably, so to expect otherwise is to expect oligopoly
behaviour which is the sort of antithesis of a decentralised mining
system. It's in fact a similar argument as to why decentralisation of
mining provides policy neutrality: some miner somewhere with some
hashrate will process your transaction even if some other miners are
by policy deciding not to mine it. It is also similar reason why free
transactions are processed today - policies vary and this is good for
ensuring many types of transaction get processed.

Adam

📅 Original date posted:2015-07-30 📝 Original message:I dont ...

2023-06-07T17:43:57+02:00

In reply to nevent1q…ap69
_________________________

📅 Original date posted:2015-07-30
📝 Original message:I dont think people consider other blockchains as a competitive
threat. A PoW-blockchain is a largely singleton data structure for
security reasons (single highest hashrate), it is hard for an
alternative chain to bootstrap or provide meaningful security.
Secondly the world largely lacks expertise to maintain a blockchain to
bitcoin's security level, perhaps you can see a hint of this in the
recently disclosed security vulnerability by Pieter Wuille and Gregory
Maxwell. Calls to this as an argument are not resonating and probably
not helping your argument. Bitcoin has security properties, and a
competing system cant achieve better properties by bypassing security,
any blockchain faces the same fundamental security / decentralisation
limitations.

Secondly Bitcoin can obviously compete with itself with different
parameters and defacto *does* today. I think it is a safe estimate
that > 99% of Bitcoin transactions right now are happening in Bitcoin
related systems with various degrees of audit, reconciliation,
provable reserves etc. I think we can expect this to continue and
become more secure via more reconciliation, and longer term via
lightning or Bitcoin sidechains with different parameters. It is a
different story to have a single central system (Bitcoin with
parameters changed to the point of centralisation failure) vs having
multiple choices, because some transactions can more easily use
relatively centralised systems (eg micropayments), and more
interestingly the combination of a secure and decentralised layer 1
plus choices of less decentralised layer 2 options, can be interesting
because the layer 2 is provided cover from attack. There is less to
be gained by attacking relatively centralised layer 2 because any
payments at risk of policy abuse (which is typically a small subset)
can easily switch to layer 1. That in itself makes layer 2
transactions also less susceptible to policy abuse. Further lightning
it appears from work so far should add significant scale while
retaining trustlessness and a good degree of decentralisation.

Finally you seem to be focusing on "artificial" limits where that is
not the issue under consideration. The limits are technical and
relating to decentralisation and security. I wont go over them again
as this topic has been covered many times in recent months. Any chain
that tried to go to extreme parameters (very low block intervals, or
very large blocksizes) would have the same decentralisation problems
as Bitcoin would if it did the same thing. There are a number of alt
coins that have failed as a result of poor parameter choices, there
are inherent security limits.

Adam

ps Etiquette note for yourself and others: please dont be repetitive
or attempt to be forceful. Many people have spent many years
understanding this very complex system, from my own experience it is
rare indeed to think of an entirely new concept or analysis, that
hasnt' been long considered and put to bed 3 or 4 years ago.
Thoughtful polite and constructive comments are welcome but I
recommend to not start from an assumption that you have a clear and
better insight than the entire technical community, because I have to
say from my own experience that is very rarely the case. It can be
useful to test theories on #bitcoin IRC channel to find out what has
been already concluded, find the references and avoid having to have
that hashed out on this list which is trying to be focussed on
technical solutions.

On 29 July 2015 at 16:10, Raystonn . via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>> Cheapest way to send value? Is this what Bitcoin is trying to do? So
>> all of the smart contract, programmable money, consensus coding and
>> tremendous developer effort is bent to the consumer demand for cheaper
>> fees. Surely thou jests!
>
>
> These other features can be replicated into any alternative blockchain,
> including those with lower fees. In the open-source world of
> cryptocurrency, no feature will remain a value-add for very long after it
> has been identified to be such. Anything adding value will quickly be
> absorbed into competing alternative blockchains. That will leave economic
> policy as the distinguishing factor.
>
>> ... it is not the case ... that reluctance to concede
>> blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
>> explained in this thread that the protocol's current state of
>> development relies on blocksize for security and, ultimately, as a
>> means of protecting its degree of decentralization.
>
>
> A slow or lack of increase to maximum transaction rate will cause pressure
> on fees. Whether this is the desired goal is not relevant. Everyone has
> agreed this will be the outcome. As to a smaller block size being needed
> for additional decentralization, one must simply ask how much we are all
> willing to pay for that additional decentralization. It is likely that the
> benefit thereto will have to be demonstrated by some power attacking and
> destroying a less decentralized currency before the benefit of this feature
> is given monetary value by the market. Until then, value will bleed to the
> network with the least friction, because it will have the greatest ability
> to grow its network effect. That means the blockchain with adequate
> features and cheapest fees will eventually have the largest market share.
>
>
> -----Original Message----- From: Venzen Khaosan
> Sent: Wednesday, July 29, 2015 3:11 PM
> To: Raystonn .
> Cc: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure
> isn'ttemporary
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Raystonn, I'm aware that you're addressing your question to Greg
> Maxwell, however a point you keep stating as fact calls for reference:
>
> On 07/30/2015 04:28 AM, Raystonn . via bitcoin-dev wrote:
> [snip]
>>
>> How do you plan to address the bleeding of value from Bitcoin to
>> alternative lower-fee blockchains created by the artificially-high
>> bitcoin transaction fees when users begin looking for the cheapest
>> way to send value?
>
> Cheapest way to send value? Is this what Bitcoin is trying to do? So
> all of the smart contract, programmable money, consensus coding and
> tremendous developer effort is bent to the consumer demand for cheaper
> fees. Surely thou jests!
>
>> Modern economic study has shown that liquidity moves to the
>> location of least friction.
>
> Modern economic study? Can you please provide a link or reference to
> the study you are referring to.
>
> "liquidity moves to the location of least friction"
>
> This sounds like "econo-speak" and makes no sense. The definition of
> Liquidity is the degree to which an asset/security can be bought or
> sold in the market without affecting the price.
>
> That is why bitcoin is said to have low liquidity: buying or selling
> only 100 BTC visibly affects the exchange price. You probably mean
> "people like cheap fees", which is true, but as others have said,
> because of Bitcoin's powerful features, they are willing to pay higher
> fees and wait longer for transactions to execute.
>
> As for your public cross-examination of Greg Maxwell, your case seems
> to be made on the assumption that limiting the size of the blockchain
> is an attempt to artificially raise tx fees, but it is not the case
> (as you and others repeatedly argue) that reluctance to concede
> blocksize is an attempt to constrain capacity. Greg Maxwell thoroughly
> explained in this thread that the protocol's current state of
> development relies on blocksize for security and, ultimately, as a
> means of protecting its degree of decentralization.
>
> Surely, this is an obvious concern even for those who are campaigning
> for the hare-brained ideal of making Bitcoin a "faster, cheaper
> alternative" to visa or paypal? If we lose decentralization, we lose
> the whole thing, right? Incorrect or correct?
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1
>
> iQEcBAEBAgAGBQJVuU+rAAoJEGwAhlQc8H1m9nkH/00xXJ53H4qvHjPrdNRniwvB
> RXi96QjbnVj/fxU2J2TBPYF1LxJ13avyL58bbaJF7GKqcpoYNZArCKLQyGaZGCTp
> h7Oe/0S+b1QCrvxcVK8Ikeb7a1h9wnhAPf1FvAWoJ1cFGx/qGHetKqx1dQTWkVWz
> Mp17vjaofmp2OhBzh0Smj+wV9hXn9w9giZKc6UGvC0Qc7Rf3GL/YVJzM2CZNvlLS
> YhQSqnnqduugYztqLV/NvNExF41zC2IMyNmA41q46v/nh8stNSIcJleD39csNMfx
> BXjrlnPfZ+JI4RhiH3I0qjOYWPtBH9od788DY509EOn3MT4vU+EVcQaxyuFqZyw=
> =lQvy
> -----END PGP SIGNATURE-----
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

📅 Original date posted:2015-06-28 📝 Original message:On 28 ...

2023-06-07T17:40:57+02:00

In reply to nevent1q…24ca
_________________________

📅 Original date posted:2015-06-28
📝 Original message:On 28 June 2015 at 23:05, Gavin Andresen <gavinandresen at gmail.com> wrote:
> On Sun, Jun 28, 2015 at 2:58 PM, Adam Back <adam at cypherspace.org> wrote:
>>
>> This is probably going to sound impolite, but I think it's pertinent.
>>
>> Gavin, on dwelling on the the fact that you appear to not understand
>> the basics of the lightning network, I am a little alarmed about this
>
> If I don't see how switching from using the thousands of fully-validating
> bitcoin nodes with (tens? hundreds?) of Lightning Network hubs is better in
> terms of decentralization (or security, in terms of Sybil/DoS attacks),

Its a source routed network, not a broadcast network. Fees are
charged on channels so
DoS is just a way to pay people a multiple of bandwidth cost.

in terms of trustlessness Andrew Lapp explained it pretty well:
> I don't mind a set of central authorities being part of an option IF the central authority
> doesn't need to be trusted. On the blockchain, the larger miner is, the more you have
> to trust them to not collude with anyone to reverse your payments or destroy the trust
> in the system in some attack. On the Lightning network, a large hub can't steal my
> money.
>
> I think most people share the sentiment that trustlessness is what matters and
> decentralization is just a synonym for trustlessness when talking about the blockchain
> and mining, however decentralization isn't necessarily synonymous with trustlessness
> nor is centralization synonymous with trust-requiring when you're talking about
> something else.

Gavin wrote:
> then I doubt other people do, either. You need to do a better job of explaining it.

I gave it a go a couple of posts up. I didnt realise people here
proposing mega-blocks were not paying attention to the whole lightning
concept and detail.

People said lots of things about how it's better to work on lightning,
to scale algorithmically, rather than increasing block-size to
dangerously centralising proportions.
Did you think we were Gish Galloping you? We were completely serious.

The paper is on http://lightning.network

though it is not so clearly explained there, however Joseph is working
on improving the paper as I understand it.

Rusty wrote a high-level blog explainer: http://rusty.ozlabs.org/?p=450

though I don't recall that he got into recirculation, negative fees
etc. A good question
for the lightning-dev mailing list maybe.

http://lists.linuxfoundation.org/pipermail/lightning-dev/

There are a couple of recorded presentation videos / podcasts from Joseph Poon.

sf bitcoin dev presentation:

https://www.youtube.com/watch?v=2QH5EV_Io0E

epicenter bitcoin:

https://www.youtube.com/watch?v=fBS_ieDwQ9k

There's a related paper from Christian Decker "Duplex Micropayment Channels"

http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf

> But even if you could convince me that it WAS better from a
> security/decentralization point of view:

We don't need to convince people, we just have to code it and
demonstrate it, which people are working on.

But Lightning does need a decentralised and secure Bitcoin network for
anchor and reclaim transactions, so take it easy with the mega-blocks
in the mean-time.

> a) Lightning Network is nothing but a whitepaper right now. We are a long
> way from a practical implementation supported by even one wallet.

maybe you want to check in on

https://github.com/ElementsProject/lightning

and help code it.

I expect we can get something running inside a year. Which kind of
obviates the burning "need" for a schedule into the far future rising
to 8GB with unrealistic bandwidth growth assumptions that will surely
cause centralisation problems.

For block-size I think it would be better to have a 2-4 year or one
off size bump with policy limits and then re-evaluate after we've seen
what lightning can do.

I have been saying the same thing ad-nauseam for weeks.

> b) The Lightning Network paper itself says bigger blocks will be needed even
> if (especially if!) Lightning is wildly successful.

Not nearly as big as if you tried to put the transactions it would
enable on the chain, that's for sure! We dont know what that limit is
but people have been imagining 1,000 or 10,000 transactions per anchor
transaction. If micro-payments get popular many more.

Basically users would park Bitcoins a on a hub channel instead of the
blockchain. The channel can stay up indefinitely, and the user has
assurances analogous to greenaddress time-lock mechanism

Flexcap maybe a better solution because that allows bursting
block-size when economically rational.

Note that the time-locks with lightning are assumed to be relative
CTLV eg using the mechanism as Mark Friedenbach described in a post
here, and as implemented in the elements sidechain, so there is not a
huge rush to reclaim funds. They can be spread out in time.

If you want to scale Bitcoin - like really scale it - work on
lightning. Lightning + a decentralised and secure Bitcoin, scales
further and is more trustless than Bitcoin forced into centralisation
via premature mega-blocks.

To my mind a shorter, more conservative block-size increase to give a
few years room is enough for now. We'll be in a better position to
know what the right next step is after lightning is running.

Something to mention is you can elide transactions before reclaiming.
So long as the balancing transaction is correct, someone online can
swap it for you with an equal balance one with less hops of
intermediate payment flows.

It's pretty interesting what you can do already. I'm fairly confident
we're not finished algorithmically optimising it either. It's
surprising how much new territory there is just sitting there
unexplored.

Adam

📅 Original date posted:2015-06-28 📝 Original message:This ...

2023-06-07T17:40:56+02:00

In reply to nevent1q…xfns
_________________________

📅 Original date posted:2015-06-28
📝 Original message:This is probably going to sound impolite, but I think it's pertinent.

Gavin, on dwelling on the the fact that you appear to not understand
the basics of the lightning network, I am a little alarmed about this,
given your recent proposals to unilaterally push the network into
quite dangerous areas of game theory, to lobby companies etc.

People are super polite and respectful around here, but this is not
looking good, if you don't mind me saying so. You can't make balanced
or informed trade-offs on block-size schedules stretching into the
future, if you don't understand work that is underway, and has been
for months. Lightning is a major candidate approach the rest of the
technical community sees for Bitcoin to scale.

Lightning allows Bitcoin to scale even without a block-size increase,
and therefore considerably impacts any calculation of how much
block-size is required. In this light you appear to have been
attempting to push through a change without even understanding the
alternatives or greater ecosystem.

Adam

On 28 June 2015 at 19:51, Adam Back <adam at cypherspace.org> wrote:
> On Sun, Jun 28, 2015 at 1:12 PM, Mark Friedenbach <mark at friedenbach.org> wrote:
>> But ultimately, lightning usefully solves a problem where participants have semi-long lived payment endpoints.
>
> Recipients do benefit from keeping connections to hubs because if a
> hub goes away or a user abandons a hub that tends to generate new
> on-chain traffic for balance reclaim, and new channel establishment,
> as we understand the limits so far.
>
> On 28 June 2015 at 19:29, Gavin Andresen <gavinandresen at gmail.com> wrote:
>> Very few of my own personal Bitcoin transactions fit that use-case.
>
> I believe Mark is talking about the one hop (direct) connections
> benefits from being long-lived; the payment destination is not
> restricted in the same way. It's more like having a static IP address
> with your ISP, that doesnt stop you reaching anywhere on the internet.
>
> Say the Lightning Network has an average fan out of 10, now subject to
> capital and rebalancing flows in the network you can pay anyone of a
> billion people in 9 hops. Maybe the fanout is lumpy, with some bigger
> hubs - that just serves to reduce the number of hops. Maybe there are
> some capitalisation limits, that is dealt with by negative fees and
> recirculation (more on that below) or failing that recapitalisation
> on-chain. Some people assume that the hub will run out of
> capitalisation on a given channel, however if people and hubs retain
> redundant channels they can be paid to rebalance channels, and even
> users can be paid by other users if there is a net flow from some
> users, to a given business eg starbucks, where the users just buy new
> BTC for USD and spend and dont earn BTC. Rebalancing would work
> because the exchange where they buy new BTC would be incentivised to
> pay starbucks (or whoever has excess coins on a channel) to send the
> coins back to the users topping up by paying them negative fees,
> because the fees to do that should be less than using on-chain
> transactions.
>
>> But I don't think it is a scaling solution for the types of payments the Bitcoin
>> network is handling today.
>
> Actually I think it may well be able to do that very well. We dont
> know for sure how it will work until we see the balance and
> effectiveness of the network algorithms against usage (eg simulating
> from Bitcoin's historic usage say), but there's good reason to see
> that BTC can recirculate and rebalance due to the reversible
> non-expiring channels and capitalisation requirements can be lower
> than simple expectation due higher velocity and redistribution of fees
> to anyone with excess liquidity and connectivity heading in the right
> direction.
>
> Adam

📅 Original date posted:2015-06-28 📝 Original message:On ...

2023-06-07T17:40:56+02:00

In reply to nevent1q…a2h6
_________________________

📅 Original date posted:2015-06-28
📝 Original message:On Sun, Jun 28, 2015 at 1:12 PM, Mark Friedenbach <mark at friedenbach.org> wrote:
> But ultimately, lightning usefully solves a problem where participants have semi-long lived payment endpoints.

Recipients do benefit from keeping connections to hubs because if a
hub goes away or a user abandons a hub that tends to generate new
on-chain traffic for balance reclaim, and new channel establishment,
as we understand the limits so far.

On 28 June 2015 at 19:29, Gavin Andresen <gavinandresen at gmail.com> wrote:
> Very few of my own personal Bitcoin transactions fit that use-case.

I believe Mark is talking about the one hop (direct) connections
benefits from being long-lived; the payment destination is not
restricted in the same way. It's more like having a static IP address
with your ISP, that doesnt stop you reaching anywhere on the internet.

Say the Lightning Network has an average fan out of 10, now subject to
capital and rebalancing flows in the network you can pay anyone of a
billion people in 9 hops. Maybe the fanout is lumpy, with some bigger
hubs - that just serves to reduce the number of hops. Maybe there are
some capitalisation limits, that is dealt with by negative fees and
recirculation (more on that below) or failing that recapitalisation
on-chain. Some people assume that the hub will run out of
capitalisation on a given channel, however if people and hubs retain
redundant channels they can be paid to rebalance channels, and even
users can be paid by other users if there is a net flow from some
users, to a given business eg starbucks, where the users just buy new
BTC for USD and spend and dont earn BTC. Rebalancing would work
because the exchange where they buy new BTC would be incentivised to
pay starbucks (or whoever has excess coins on a channel) to send the
coins back to the users topping up by paying them negative fees,
because the fees to do that should be less than using on-chain
transactions.

> But I don't think it is a scaling solution for the types of payments the Bitcoin
> network is handling today.

Actually I think it may well be able to do that very well. We dont
know for sure how it will work until we see the balance and
effectiveness of the network algorithms against usage (eg simulating
from Bitcoin's historic usage say), but there's good reason to see
that BTC can recirculate and rebalance due to the reversible
non-expiring channels and capitalisation requirements can be lower
than simple expectation due higher velocity and redistribution of fees
to anyone with excess liquidity and connectivity heading in the right
direction.

Adam

📅 Original date posted:2015-06-28 📝 Original message:On 28 ...

2023-06-07T17:40:54+02:00

In reply to nevent1q…cqn3
_________________________

📅 Original date posted:2015-06-28
📝 Original message:On 28 June 2015 at 12:29, Benjamin <benjamin.l.cordes at gmail.com> wrote:
> I agree that naive scaling will likely lead to bad outcomes. They might have
> the advantage though, as this would mean not changing Bitcoin.

Sure we can work incrementally and carefully, and this is exactly what
Bitcoin has been doing, and *must* do for safety and security for the
last 5 years!
That doesnt mean that useful serious improvements have not been made.

> Level2 and Lightning is not well defined. If you move money to a third
> party, even if it is within the constrained of a locked contract, then I
> don't think that will solve the issues.

I think you misunderstand how lightning works. Every lightning
transaction *is* a valid bitcoin transaction that could be posted to
the Bitcoin network to reclaim funds if a hub went permanently
offline. It is just that while the hubs involved remain in service,
there is no need to do so. This is why it has been described as a
(write coalescing) write cache layer for Bitcoin.>

I believe people expect lightning to be peer 2 peer like bitcoin.

Adam

📅 Original date posted:2015-06-28 📝 Original message:On 28 ...

2023-06-07T17:40:53+02:00

In reply to nevent1q…lcez
_________________________

📅 Original date posted:2015-06-28
📝 Original message:On 28 June 2015 at 07:34, Raystonn <raystonn at hotmail.com> wrote:
> nodes are limited to 133 connections. This is 8 outgoing connections and
> 125 incoming connections. [...] Once your full node reaches 133 connections,
> it will see no further increase in load [...] Only transaction rate will affect the
> load on your node.

The total system cost is more relevant, or total cost per user. I think you
are stuck on the O( t * m ) t = tx, m = nodes thinking. Total cost per user
is increasing. That better scaling algorithms need to be found. That's why
people are working on lightning-like systems.

> fear larger blocks based on an assumption of exponential growth of work, which just
> isn't the case.

People have been explaining quadratic system level increase, which is
not exponential,
wrong assumption.

> Decentralisation is planned to scale down once the 133 connection limit is
> hit. Like it or not, this is the current state of the code.

No people are not assuming decentralisation would decrease. They are assuming
the number of economically dependent full nodes would increase, that's where the
O( n^2 ) comes from! If we assume say c= 0.1% of users will run full nodes,
and users make some small-world assumed number of transactions that doesnt
increase greatly as more users are added to the network, then O( t * m
) => O( n^2 ).

Seeing decentralisation failing isn't a useful direction as Bitcoin depends on
decentralisation for most of it's useful security properties. People running
around saying great lets centralise Bitcoin and scale it, are not working on
Bitcoin. They may more usefully go work on competing systems without
proof of work as that's where this line of reasoning ends up. There
are companies working on such things. Some of them support Bitcoin IOUs.
Some of them have job openings.

We can improve decentralisation, and use bandwidth and relay improvements
to get some increase in throughput. But starting a direction of simplistic
thinking about an ever increasing block-size mode of thinking is destructive
and not Bitcoin. If you want to do that, you need to do it in an offchain
system. You cant build on sand so your offchain system wont be useful
if Bitcoin doesnt have reasonable decentralisation to retain useful meaning.
Hence lightning. There are existing layer 2 things that have on-chain netting.
Go work on one of those. But people need to understand the constraints
and stop arguing to break Bitcoin to "scale". It's too simplistic.

Even Gavin's proposal is not trying to do that, hence reference to
Nielsen's law.
His parameters are too high for too long for basic safety or prudence, but the
general idea to reclaim some throughput from network advances, is reasonable.
Also decentralisation is key, and that is something we can improve with pooling
protocols to phase out the artificial centralisation. We can also
educate people
to use fullnode they economically depend on to keep the full to SPV ratio
reasonable which is also needed for security.

Adam

📅 Original date posted:2015-06-27 📝 Original ...

2023-06-07T17:40:50+02:00

In reply to nevent1q…g0cp
_________________________

📅 Original date posted:2015-06-27
📝 Original message:Michael Naber wrote:
> Bitcoin Core must remain the lowest-fee, highest-capacity, most secure, distributed, fastest, overall best solution possible to the global consensus problem.

Everyone here is excited about the potential of Bitcoin and would
aspirationally like it to reach its full potential as fast as
possible. But the block-size is not a free variable, half those
parameters you listed are in conflict with each other. We're trying
to improve both decentralisation and throughput short-term while
people work on algorithmic improvements mid-term. If you are
interested you can take a look through the proposals:

http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-June/008603.html

Note that probably 99% of Bitcoin transactions already happen
off-chain in exchanges, tipping services, hosted wallets etc. Maybe
you're already using them, assuming you are a bitcoin user.
They constitute an early stage layer 2, some of them even have on
chain netting and scale faster than the block-chain.

You can also read about layer 2, the lightning network paper and the
duplex micropayment channel paper:

http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf
http://www.tik.ee.ethz.ch/file/716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf

and read the development list and look at the code:

http://lists.linuxfoundation.org/pipermail/lightning-dev/
https://github.com/ElementsProject/lightning

Adam

On 27 June 2015 at 16:39, Michael Naber <mickeybob at gmail.com> wrote:
> Demand to participate in a low-fee global consensus network will likely
> continue to rise. Technology already exists to meet that rising demand using
> a blockchain with sufficient block size. Whether that blockchain is Bitcoin
> Core with an increased block size, or whether it is a fork, market forces
> make it almost certain that demand will be met by a blockchain with adequate
> capacity. These forces ensure that not only today’s block size will be
> increased, but also that future increases will occur should the demand
> arise.
>
> In order to survive, Bitcoin Core must remain the lowest-fee,
> highest-capacity, most secure, distributed, fastest, overall best solution
> possible to the global consensus problem. Attempting to artificially
> constrain the block size below the limits of technology for any reason is a
> conflict with this objective and a threat to the survival of Bitcoin Core.
> At the same time, scheduling large future increases or permitting unlimited
> dynamic scaling of the block size limit raises concerns over availability of
> future computing resources. Instead, we should manually increase the block
> size limit as demand occurs, except in the special case that increasing the
> limit would cause an undue burden upon users wishing to validate the
> integrity of the blockchain.
>
> Compromise: Can we agree that raising the block size to a static 8MB now
> with a plan to increase it further should demand necessitate except in the
> special case above is a reasonable path forward?
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

📅 Original date posted:2015-06-15 📝 Original message:Hi ...

2023-06-07T17:38:10+02:00

In reply to nevent1q…fxzp
_________________________

📅 Original date posted:2015-06-15
📝 Original message:Hi Mike

Well thank you for replying openly on this topic, its helpful.

I apologise in advance if this gets quite to the point and at times
blunt, but transparency is important, and we owe it to the users who
see Bitcoin as the start of a new future and the$3b of invested funds
and $600m of VC funds invested in companies, we owe it to them that we
be open and transparent here.

I would really prefer on a personal nor professional basis to be
having this conversation period, never mind in public, but Mike - your
and Gavin's decision to promote a unilateral hard-fork and code fork
are extremely high risk for bitcoin and so there remains little
choice. So I apologise again that we have to have this kind of
conversation on a technical discussion list. This whole thing is
hugely stressful and worrying for developers, companies and investors.

I strongly urge that we return to the existing collaborative
constructive review process that has been used for the last 4 years
which is a consensus by design to prevent one rogue person from
inserting a backdoor, or lobbying for a favoured change on behalf of a
special interest group, or working for bad actor (without accusing you
of any of those - I understand you personally just want to scale
bitcoin, but are inclined to knock heads and try to force an issue you
see, rather than work collaboratively).

For you (and everyone)

- Should there be a summit of some kind, that is open attendance, and
video recorded so that people who are unable to attend can participate
too, so that people can present the technical proposals and risks in
an unbiased way?

(It is not theoretical question, I may have a sponsor and host - not
Blockstream, an independent, its a question for everyone, developers,
users, CTOs, CEOs.)

So here I come back to more frank questions:

Governance

The rest of the developers are wise to realise that they do not want
exclusive control, to avoid governance centralising into the hands of
one person, and this is why they have shared it with a consensus
process over the last 4 years. No offence but I dont think you
personally are thinking far enough ahead to think you want personal
control of this industry. Maybe some factions dont trust your
motives, or they dont mind, but feel more assured if a dozen other
people are closely reviewing and have collective review authority.

- Do you understand that attempting to break this process by
unilateral hard-fork is extremely weakening of Bitcoin's change
governance model?

- Do you understand that change governance is important, and that it
is important that there be multiple reviewers and sign-off to avoid
someone being blackmailed or influenced by an external party - which
could potentially result in massive theft of funds if something were
missed?

- Secondarily do you understand that even if you succeed in a
unilateral fork (and the level of lost coins and market cap and damage
to confidence is recoverable), that it sets a precedent that others
may try to follow in the future to introduce coercive features that
break the assurances of bitcoin, like fungibility reducing features
say (topically I hear you once proposed on a private forum the concept
of red-lists, other such proposals have been made and quickly
abandoned), or ultimately if there is a political process to obtain
unpopular changes by unilateral threat, the sky is the limit - rewrite
the social contract at that point without consensus, but by
calculation that people will value Bitcoin enough that they will
follow a lead to avoid risk to the system?

Security

As you probably know some extremely subtle bugs in Bitcoin have at
times slipped past even the most rigorous testings, often with
innocuous but unexpected behaviours, but some security issues Some
extremely intricate and time-sensitive security defect and incident
response happens from time to time which is not necessarily publicly
disclosed until after the issue has been rolled out and fixed, which
can take some time due to the nature of protocol upgrades,
work-arounds, software upgrade via contacting key miners etc. We
could take an example of the openSSL bug.

- How do you plan to deal with security & incident response for the
duration you describe where you will have control while you are
deploying the unilateral hard-fork and being in sole maintainership
control?

- Are you a member of the bitcoin security reporting list?

On 15 June 2015 at 11:56, Mike Hearn <mike at plan99.net> wrote:
> I will review both and mostly delegate to Gavin's good taste around the
> details, unless there is some very strong disagreement. But that seems
> unlikely.
> ...
> Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests
> aren't scored in any way. The final decision rests with the maintainer as in
> ~all open source projects.

As you know the people who have written 95% of the code (and reviewed,
and tested, and formally proved segments etc) are strenuously advising
not to push any consensus code into public use without listening to
and addressing review questions which span beyond rigorous code &
automated guided fuzz testers, simulation and sometimes formal proofs,
but also economics, game-theory and critically very subtle
determinism/consensus safety that they have collectively 4-5 years
experience of each.

- Will you pause your release plans if all of the other developers
insist that the code or algorithm is defective?

- Please don't take this the wrong way, and I know your bitcoinj work
was a significant engineering project which required porting bitcoin
logic. But If the answer to the above question is no, as you seemed
to indicate in your response, as you not have not written much bitcoin
core code yourself (I think 3 PRs in total), do you find yourself more
qualified than the combination of peer review of the group of people
who have written 95% of it, and maintained it and refactored most of
it over the last 4-5 years?

I presume from your security background you are quite familiar with
the need for review of crypto protocol changes & rigorous code review.
That is even more the case with Bitcoin given the consensus
criticality.

>> - On the idea of a non-consensus hard-fork at all, I think we can
>> assume you will get a row of NACKs. Can you explain your rationale
>> for going ahead anyway? The risks are well understood and enormous.
>
> If Bitcoin runs out of capacity it will break and many of our users will
> leave. That is not an acceptable outcome for myself or the many other
> wallet, service and merchant developers who have worked for years to build
> an ecosystem around this protocol.

That you are frustrated, is not a sufficient answer as to why you are
proposing to go ahead with a universally acknowledged extreme network
divergence danger unilateral hard-fork, lacking wide-spread consensus.
People are quite concerned about this. Patience, caution and prudence
is necessary in a software system with such high assurance
requirements.

So I ask again:

- On the idea of a non-consensus hard-fork at all, I think we can
assume you will get a row of NACKs. Can you explain your rationale
for going ahead anyway? The risks are well understood and enormous.

Note the key point is that you are working on a unilateral hard-fork,
where there is a clear 4 year established process for proposing
improvements and an extremely well thought out and important change
management governance process. While there has been much discussion,
you nor Gavin, have not actually posted a BIP for review. Nor
actually was much of the discussion even conducted in the open: it was
only when Matt felt the need to clear the air and steer this
conversation into the open that discussion arose here. During that
period of private discussion you and Gavin were largely unknown to
most of us lobbying companies with your representation of a method
that concerns everyone of the Bitcoin users. Now that the technical
community aware aware they are strenuously discouraging you on the
basis of risks.

Openness

- Do you agree that bitcoin technical discussions should happen in the open?

- As this is a FOSS project, do you agree that companies should also
be open, about their requirements and trade-offs they would prefer?

- Can you disclose the list of companies you have lobbied in private
whether they have spoken publicly or not, and whether they have
indicated approval or not?

- Did you share a specific plan, like a BIP or white paper with these
companies, and if so can we see it?

- If you didnt submit a plan, could you summarise what you asked them
and what you proposed, and if you discussed also the risks? (If you
asked them if they would like Bitcoin to scale, I expect almost
everyone does, including every member of the technical community, so
that for example would not fairly indicate approval for a unilateral
hard-fork)

I and others will be happy to talk with the CTO and CEOs of companies
you have lobbied in private, for balance to assure ourselves and the
rest of the community that their support was given - and with full
understanding of the risks of doing it unilaterally, without peer
review, benefit of maintenance and security inidence management, and
what exactly they are being quoting as having signed up for.

(This maybe more efficiently and openly achieved by the open process,
on a mailing list, maybe a different one even special purpose to this
topic, with additional option of the open public meeting I proposed at
the top).

- Do you agree that it would be appropriate, that companies be aware
of both the scaling opportunities (of course, great everyone wants
scalability) as well as the technical limits and risks with various
approaches? And that these be presented by parties from a range of
views to ensure balance?

- Do you consider your expression of issues to hold true to the ideal
of representing balanced nuanced view of all sides of a technical
debate, even when under pressure or feeling impatient about the
process?

You may want to review the opening few minutes of your epicenter 82
bitcoin for example where you claimed and I quote "[the rest of the
technical community] dont want capacity to ever increase and want it
to stay where it is and when it fills up people move to other
systems".

- Do you think that is an accurate depiction of the complex trade-offs
we have been discussing on this list?

(For the record I am not aware of a single person who has said they do
not agree with scaling Bitcoin. Changing a constant is not the
hard-part. The hard part is validating a plan and the other factors
that go into it. It's not a free choice it is a security/scalability
tradeoff. No one will thank us if we "scale" bitcoin but break it in
hard to recover ways at the same time.)

- Were you similarly balanced in your explanations when talking to
companies in private discussions?

- Do you understand that if we do not work from balanced technical
discussion, that we may end up with some biased criteria?

Authority

Neither you nor Gavin have any particular authority here to speak on
behalf of Bitcoin (eg you acknowledge in your podcast that Wladimir is
dev lead, and you and Gavin are both well aware of the 4 year
established change management consensus decision making model where
all of the technical reviewers have to come to agreement before
changes go in for security reasons explained above). I know Gavin has
a "Chief Scientist" title from the Bitcoin Foundation, but sadly that
organisation is not held in as much regard as it once was, due to
various irregularities and controversies, and as I understand it no
longer employs any developers, due to lack of funds. Gavin is now
employed by MIT's DCI project as a researcher in some capacity. As
you know Wladimir is doing the development lead role now, and it seems
part of your personal frustration you said was because he did not
agree with your views. Neither you nor Gavin have been particularly
involved in bitcoin lately, even Gavin, for 1.5 years or so.

- Do you agree that if you presume to speak where you do not have
authority you may confuse companies?

> If Bitcoin runs out of capacity it will break and many of our users will
> leave. That is not an acceptable outcome for myself or the many other
> wallet, service and merchant developers who have worked for years to build
> an ecosystem around this protocol.

But I think this is a false dichotomy. As I said in previous mail I
understand people are frustrated that it has taken so long, but it is
not the case that no progress has been made on scalability.

I itemised a long list of scalability work which you acknowledged as
impressive work (CPU, memory, network bandwidth/latency) and RBF, CPFP
fee work, fee-estimation, and so on, which you acknowledged and are
aware of.

There are multiple proposals and BIPs under consideration on the list right now.

- what is the reason that you (or Gavin) would not post your BIP along
side the others to see if it would win based on technical merit?

- why would you feel uniquely qualified to override the expert opinion
of the rest of the technical community if your proposal were not
considered to have most technical merit? (Given that this is not a
simple market competition thing where multiple hard-forks can be
considered - it is a one only decision, and if it is done in a
divisive unilateral way there are extreme risks of the ledger
diverging.)

Network Divergence Risk

>> - How do you propose to deal with the extra risks that come from
>> non-consensus hard-forks? Hard-forks themselves are quite risky, but
>> non-consensus ones are extremely dangerous for consensus.
>
> The approach is the same for other forks. Voting via block versions and then
> when there's been >X% for Y time units the 1mb limit is lifted/replaced.

But this is not a soft-fork, it is a hard-fork. Miner voting is only
peripherally related. Even if in the extremis 75% of miners tried a
unilateral hard-fork but 100% of the users stayed on the maintained
original code, no change would occur other than those miners losing
reward (mining fork-coins with no resale value) and the difficulty
would adjust. The miners who made an error in choice would lose money
and go out of business or rejoin the chain.

However if something in that direction happens with actual users and
companies on both sides of it users will lose money, the ledger will
diverge as soon as a single double-spend happens, and never share a
block again, companies will go instantly insolvent, and chaos will
break out. This is the dangerous scenario we are concerned about.

So the same question again:

- How do you propose to deal with the extra risks that come from
non-consensus hard-forks? Hard-forks themselves are quite risky, but
non-consensus ones are extremely dangerous for consensus.

Being sensitive to alarming the market

It is something akin to Greece or Portugal or Italy exiting the euro
currency in a disorderly way. Economists and central bank policy
makers are extremely worried about such an eventuality and talk about
related factors in careful, measured terms, watch Mario Draghi when he
speaks.

Imagine that bitcoin is 10x or 100x bigger. Bitcoin cant have people
taking unilateral actions such as you have been proposing. It is not
following the consensus governance process, and not good policy and it
is probably affecting bitcoin confidence and price at this moment.

>> - Do you have contingency plans for what to do if the non-consensus
>> hard-fork goes wrong and $3B is lost as a result?
>
> Where did you get the $3B figure from? The fork either doesn't happen, or it
> happens after quite a long period of people knowing it's going to happen -
> for example because their full node is printing "You need to upgrade"
> messages due to seeing the larger block version, or because they read the
> news, or because they heard about it via some other mechanisms.

This is not a soft-fork, and the community will not want to take the
risks once they understand them, and they have months in which to
understand them and at this point you've motivated and wasted 100s of
developer man hours such that we will feel impelled to make sure that
no one opts into a unilateral hard-fork without understanding the
risks. It would be negligent to allow people to do that. Before this
gets very far FAQs will be on bitcoin.org etc explaining this risk I
would imagine. Its just starting not finished.

What makes you think the rest of the community may not instead prefer
Jeff Garzik's BIP after revisions that he is making now with review
comments from others?

Or another proposal. Taken together with a deployment plan that sees
work on decentralisation tying into that plan.

- If you persisted anyway, what makes you think bitcoin could not make
code changes defensively relating to your unilateral fork?
(I am sure creative minds can find some ways to harden bitcoin against
a unilateral fork, with a soft-fork or non-consensus update can be
deployed much faster than a hard-fork).

I tried to warn Gavin privately that I thought he was under-estimating
the risk of failure to his fork proposal due to it being unilateral.
Ie as you both seem sincere in your wish to have your proposal
succeed, then obviously the best way to do that is to release a BIP in
the open collaborative process and submit it to review like everyone
else. Doing it unilaterally only increases its chance of failure.

The only sensible thing to do here is submit a BIP and stop the
unilateral fork threat.

Scalability Plans

> Let me flip the question around. Do you have a contingency plan if Bitcoin
> runs out of capacity and significant user disruption occurs that results in
> exodus, followed by fall in BTC price? The only one I've seen is "we can
> perform an emergency hard fork in a few weeks"!

Yes people have proposed other plans. Bryan Bishop posted a list of them.

Jeff Garzik has a proposal, BIP-100 which seems already better than
Gavin's having benefit of peer review which he has been incorporating.

I proposed several soft-fork models which can be deployed safely and
immediately, which do not have ledger risk.

I have another proposal relating to simplified soft-fork one-way pegs
which I'll write up in a bit.

I think there are still issues in Jeff's proposal but he is very open
and collaborating and there maybe related but different proposals
presently.

>> As you can probably tell I think a unilateral fork without wide-scale
>> consensus from the technical and business communities is a deeply
>> inadvisable.
>
> Gavin and I have been polling many key players in the ecosystem. The
> consensus you seek does exist. All wallet developers (except Lawrence), all
> the major exchanges, all the major payment processors and many of the major
> mining pools want to see the limit lifted (I haven't been talking to pools,
> Gavin has).

It does not seem to me that you understand the issue. Of course they
want to increase the scalability of bitcoin. So does everyone else on
this mailing list.

That they would support that is obvious. If you presented your
unilateral action plan without explaining the risks too.

I think I covered this further above. If you would like to share the
company list, or we can invite them to the proposed public physical
meeting, I think it would be useful for them to have a balanced view
of the ledger divergence risks, and alternative in-consensus proposals
underway, as well as the governance risks, maintenance risks, security
incident risks.

Note that other people talk to companies too, as part of their day to
day jobs, or from contacts from being in the industry. You have no
special authority or unique ability to talk with business people. Its
just that the technical community did not know you were busy doing
that.

I can not believe that any company that would listen to their CTO, CSO
or failing that board would be ok with the risks implied by what you
are proposing on full examination.

> This notion that the change has no consensus is based on you polling the
> people directly around you and people who like to spend all day on this
> mailing list. It's not an accurate reflection of the wider Bitcoin community
> and that is one of the leading reasons there is going to be a fork. A small
> number of people have been flatly ignoring LOTS of highly technical and
> passionate developers who have written vast amounts of code, built up the
> Bitcoin user base, designed hardware and software, and yes built companies.

I know you want scale bitcoin, as I said everyone here does. I think
what you're experiencing is that you've had more luck explaining your
pragmatic unilateral plan to non-technical people without peer review,
and so not experienced the kind of huge pushback you are getting from
the technical community. The whole of bitcoin is immensely
complicated such that it takes an uber-geek CS genius years to
catchup, this is not a slight of any of the business people who are
working hard to deploy Bitcoin into the world, its just complicated
and therefore not easy to understand the game-theory, security,
governance and distributed system thinking. I have a comp sci PhD in
distributed systems, implemented p2p network systems and have 2
decades of applied crypto experience with a major interest in
electronic cash crypto protocols, and it took me a several years to
catchup and even I have a few hazy spots on low-level details, and I
addictively into read everything I could find. Realistically all of
us are still learning, as bitcoin combines so many fields that it
opens new possibilities.

What I am expecting that yourself and Gavin are thinking is that
you'll knock heads and force the issue and get to consensus.

However I think you have seriously misjudged the risks and have not
adequately explained them to companies you are talking with. Indeed
you do not fully seem to acknowledge the risks, nor to have a well
thought out plan here of how you would actually manage it, nor the
moral hazards of having a lone developer in hugely divisive
circumstances in sole control of bitcoins running code. Those are
exactly the reasons for the code change governance process!

Even though you are trying to help, the full result is you are not
helping achieve anything by changing a constant and starting a
unilateral hard-fork (not to trivialise the work of making a patch to
do that).

The work to even make the constant change be feasible was a result of
1000s of hours of work by others in the development community, that is
emphatically and unilaterally telling you that hard-forks are hugely
inadvisable.

You are trying to break the code change governance security procedure
that were put in place for good reason for the security of $3b of
other peoples money, even if you have a pragmatic intent to help, this
is flat out unacceptable.

There are also security implications to what you are proposing, which
I have heard you attempting to trivialise, that are core to Bitcoins
security and core functionality.

> the overwhelming impression I get from a few
> others here is that no, they don't want to scale Bitcoin. They already
> decided it's a technological dead end.

I think this is a significant mischaracterisation, and I think almost
everybody is on board with a combination plan:

1. work to improve decentralisation (specific technical work already
underway, and education)
2. create a plan to increase block-size in a slow fashion to not cause
system shocks (eg like Jeff is proposing or some better variant)
3. work on actual algorithmic scaling

In this way we can have throughput needed for scalability and security
work to continue.

As I said you can not scale a O(n^2) broadcast network by changing
constants, you need algorithmic improvements.

People are working on them already. All of those 3 things are being
actively worked on RIGHT NOW, and in the case of algorithmic scaling
and improve decentralisation have been worked on for months.

You may have done one useful thing which is to remind people that
blocks are only 3x-4x below capacity such that we should look at it.

But we can not work under duress of haste, nor unilateral ultimatums,
this is the realm of human action that leads to moral hazard, and
ironically reminds us of why Satoshi put the quote in the genesis
block.

Bitcoin is too complex a system with too much at stake to be making
political hasty decisions, it would be negligent to act in such a way.

Again please consider that you did your job, caused people to pay
attention, but return to the process, submit a BIP, retract the
unilateral hard-fork which is so dangerous and lets have things be
calm, civil and collaborative in the technical zone of Bitcoin and not
further alarm companies and investors.

Adam

📅 Original date posted:2015-06-14 📝 Original message:Mike ...

2023-06-07T17:38:09+02:00

In reply to nevent1q…2rdj
_________________________

📅 Original date posted:2015-06-14
📝 Original message:Mike Hearn <mike at plan99.net> wrote:
> Which is why there will soon be a fork that does it.

I understand why you would be keen to scale bitcoin, everyone here is.

But as you seem to be saying that you will do a unilateral hard-fork,
and fork the code-base simultaneously, probably a number of people
have questions, so I'll start with some:

( I noticed some of your initial thoughts are online here
https://www.youtube.com/watch?v=DB9goUDBAR0 or the full podcast
https://epicenterbitcoin.com/podcast/082/ )

- Are you releasing a BIP for that proposal for review?

- If the reviewers all say NACK will you take on board their suggestions?

- On the idea of a non-consensus hard-fork at all, I think we can
assume you will get a row of NACKs. Can you explain your rationale
for going ahead anyway? The risks are well understood and enormous.

- How do you propose to deal with the extra risks that come from
non-consensus hard-forks? Hard-forks themselves are quite risky, but
non-consensus ones are extremely dangerous for consensus.

- If you're going it alone as it were, are you proposing that you will
personally maintain bitcoin-XT? Or do you have a plan to later hand
over maintenance to the bitcoin developers?

- Do you have contingency plans for what to do if the non-consensus
hard-fork goes wrong and $3B is lost as a result?

As you can probably tell I think a unilateral fork without wide-scale
consensus from the technical and business communities is a deeply
inadvisable. While apparently some companies have expressed interest
in increased scale, I can only assume they do no yet understand the
risks. I suggest before they would actually go ahead that they seek
independent advice.

Of the overall process, I think you can agree we should not be making
technical decisions with this level of complexity and consensus risk
with financial implications of this magnitude under duress of haste?
This seems otherwise a little like the moral hazard of the 2008
financial collapse that Satoshi put the quote in the genesis block
about.

I think its best that we progress as Jeff Garzik has done to have
engineering discussions centre around BIPs, running code for review,
simulation and careful analysis.

I understand this has been going on for a long time, and some people
are frustrated with the rate of progress, but making hasty,
contentious or unilateral actions in this space is courting disaster.

Please use your considerable skills to, along with the rest of the
community, work on this problem collaboratively.

I can sincerely assure you everyone does want to scale bitcoin and
shares your long term objective on that.

Adam

📅 Original date posted:2015-06-01 📝 Original message:Agree ...

2023-06-07T17:36:12+02:00

In reply to nevent1q…v9ll
_________________________

📅 Original date posted:2015-06-01
📝 Original message:Agree with everything you said. Spot on observations on all counts.
Thank you for speaking up.

Adam

On 1 June 2015 at 13:45, Jérôme Legoupil <jjlegoupil at gmail.com> wrote:
>>What do other people think?
>>
>>
>>If we can't come to an agreement soon, then I'll ask for help
>>reviewing/submitting patches to Mike's Bitcoin-Xt project that implement a
>>big increase now that grows over time so we may never have to go through
>>all this rancor and debate again."
>>
>>
>>I'll then ask for help lobbying the merchant services and exchanges and
>>hosted wallet companies and other bitcoind-using-infrastructure companies
>
>
> It's surprising to see a core dev going to the public to defend a proposal
> most other core devs disagree on, and then lobbying the Bitcoin ecosystem.
>
> This is an very unhealthy way to go because it incentives the other core
> devs to stop their technical work and go public and lobby too (cf G.Maxwell
> trying to raise redditters awareness).
>
> We need core devs to work on technical issues, not waste time doing
> politics, but Gavin's confrontational approach doesn't give them much of a
> choice.
>
> I fear that because of this approach, in the next monthes, core devs with be
> lobbying and doing politics : precious time will be wasted for everyone
> having stake in Bitcoin.
>
>
> Regarding the 20MB proposal content:
>
> Decentralization is the core of Bitcoin's security model and thus that's
> what gives Bitcoin its value.
>
> The danger is that decentralization tends naturally towards centralization,
> because centralization is more efficient. Going from decentralization to
> centralization is easy, going the other way is a lot harder :
> decentralization we lose, may never be gained back.
>
> Regarding "the urgency to do something":
>
> I believe it would be extremely healthy for the network to bump into any
> limit ASAP ... (let it be 1MB) : to incentive layer 2 and offchain solutions
> to scale Bitcoin : there are promising designs/solutions out there (LN,
> ChainDB, OtherCoin protocole, ...), but most don't get much attention,
> because there is right now no need for them. And, I am sure new solutions
> will be invented.
>
> If during the "1MB bumpy period" something goes wrong, consensus among the
> community would be reached easily if necessary.
>
> Pretending there is urgency and that Apocalypse is approaching is a fallacy.
>
> The Gavin 20MB proposal is compromising Bitcoin's long-term security in an
> irreversible way, for gaining short-term better user experience.
>
> I oppose the Gavin proposal in both content and form.
>
> Cheers,
> Jerome
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

📅 Original date posted:2015-05-26 📝 Original message:The ...

2023-06-07T17:34:32+02:00

In reply to nevent1q…t42c
_________________________

📅 Original date posted:2015-05-26
📝 Original message:The general idea for replace by fee is that it would be restricted so
as to make it safe, eg all the original addresses should receive no
less bitcoin (more addresses can be added).

The scorched earth game theory stuff (allowing removing recipients) is
kind of orthogonal.

Adam

On 26 May 2015 at 19:22, Danny Thorpe <danny.thorpe at gmail.com> wrote:
> What prevents RBF from being used for fraudulent payment reversals?
>
> Pay 1BTC to Alice for hard goods, then after you receive the goods broadcast
> a double spend of that transaction to pay Alice nothing? Your only cost is
> the higher network fee of the 2nd tx.
>
> Thanks,
> -Danny
>
> On Mon, May 25, 2015 at 5:10 PM, Peter Todd <pete at petertodd.org> wrote:
>>
>> On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote:
>> > CPFP also solves it just fine.
>>
>> CPFP is a significantly more expensive way of paying fees than RBF,
>> particularly for the use-case of defragmenting outputs, with cost
>> savings ranging from 30% to 90%
>>
>>
>> Case 1: CPFP vs. RBF for increasing the fee on a single tx
>> ----------------------------------------------------------
>>
>> Creating an spending a P2PKH output uses 34 bytes of txout, and 148
>> bytes of txin, 182 bytes total.
>>
>> Let's suppose I have a 1 BTC P2PKH output and I want to pay 0.1 BTC to
>> Alice. This results in a 1in/2out transaction t1 that's 226 bytes in size.
>> I forget to click on the "priority fee" option, so it goes out with the
>> minimum fee of 2.26uBTC. Whoops! I use CPFP to spend that output,
>> creating a new transaction t2 that's 192 bytes in size. I want to pay
>> 1mBTC/KB for a fast confirmation, so I'm now paying 418uBTC of
>> transaction fees.
>>
>> On the other hand, had I use RBF, my wallet would have simply
>> rebroadcast t1 with the change address decreased. The rules require you
>> to pay 2.26uBTC for the bandwidth consumed broadcasting it, plus the new
>> fee level, or 218uBTC of fees in total.
>>
>> Cost savings: 48%
>>
>>
>> Case 2: Paying multiple recipients in succession
>> ------------------------------------------------
>>
>> Suppose that after I pay Alice, I also decide to pay Bob for his hard
>> work demonstrating cryptographic protocols. I need to create a new
>> transaction t2 spending t1's change address. Normally t2 would be
>> another 226 bytes in size, resulting in 226uBTC additional fees.
>>
>> With RBF on the other hand I can simply double-spend t1 with a
>> transaction paying both Alice and Bob. This new transaction is 260 bytes
>> in size. I have to pay 2.6uBTC additional fees to pay for the bandwidth
>> consumed broadcasting it, resulting in an additional 36uBTC of fees.
>>
>> Cost savings: 84%
>>
>>
>> Case 3: Paying multiple recipients from a 2-of-3 multisig wallet
>> ----------------------------------------------------------------
>>
>> The above situation gets even worse with multisig. t1 in the multisig
>> case is 367 bytes; t2 another 367 bytes, costing an additional 367uBTC
>> in fees. With RBF we rewrite t1 with an additional output, resulting in
>> a 399 byte transaction, with just 36uBTC in additional fees.
>>
>> Cost savings: 90%
>>
>>
>> Case 4: Dust defragmentation
>> ----------------------------
>>
>> My wallet has a two transaction outputs that it wants to combine into
>> one for the purpose of UTXO defragmentation. It broadcasts transaction
>> t1 with two inputs and one output, size 340 bytes, paying zero fees.
>>
>> Prior to the transaction confirming I find I need to spend those funds
>> for a priority transaction at the 1mBTC/KB fee level. This transaction,
>> t2a, has one input and two outputs, 226 bytes in size. However it needs
>> to pay fees for both transactions at once, resulting in a combined total
>> fee of 556uBTC. If this situation happens frequently, defragmenting
>> UTXOs is likely to cost more in additional fees than it saves.
>>
>> With RBF I'd simply doublespend t1 with a 2-in-2-out transaction 374
>> bytes in size, paying 374uBTC. Even better, if one of the two inputs is
>> sufficiently large to cover my costs I can doublespend t1 with a
>> 1-in-2-out tx just 226 bytes in size, paying 226uBTC.
>>
>> Cost savings: 32% to 59%, or even infinite if defragmentation w/o RBF
>> costs you more than you save
>>
>> --
>> 'peter'[:-1]@petertodd.org
>> 0000000000000000134ce6577d4122094479f548b997baf84367eaf0c190bc9f
>>
>>
>> ------------------------------------------------------------------------------
>> One dashboard for servers and applications across Physical-Virtual-Cloud
>> Widest out-of-the-box monitoring support with 50+ applications
>> Performance metrics, stats and reports that give you Actionable Insights
>> Deep dive visibility with transaction tracing using APM Insight.
>> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> One dashboard for servers and applications across Physical-Virtual-Cloud
> Widest out-of-the-box monitoring support with 50+ applications
> Performance metrics, stats and reports that give you Actionable Insights
> Deep dive visibility with transaction tracing using APM Insight.
> http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

📅 Original date posted:2015-02-20 📝 Original message:The ...

2023-06-07T17:30:44+02:00

In reply to nevent1q…at20
_________________________

📅 Original date posted:2015-02-20
📝 Original message:The idea is not mine, some random guy appeared in #bitcoin-wizards one
day and said something about it, and lots of people reacted, wow why
didnt we think about that before.

It goes something like each block contains a commitment to a bloom
filter that has all of the addresses in the block stored in it.

Now the user downloads the headers and bloom data for all blocks. The
know the bloom data is correct in an SPV sense because of the
commitment. They can scan it offline and locally by searching for
addresses from their wallet in it. Not sure off hand what is the most
efficient strategy, probably its pretty fast locally anyway.

Now they know (modulo false positives) which addresses of theirs maybe
in the block.

So now they ask a full node for merkle paths + transactions for the
addresses from the UTXO set from the block(s) that it was found in.

Separately UTXO commitments could optionally be combined to improve
security in two ways:

- the normal SPV increase that you can also see that the transaction
is actually in the last blocks UTXO set.

- to avoid withholding by the full node, if the UTXO commitment is a
trie (sorted) they can expect a merkle path to lexically adjacent
nodes either side of where the claimed missing address would be as a
proof that there really are no transactions for that address in the
block. (Distinguishing false positive from node withholding)

Adam

On 20 February 2015 at 17:43, Mike Hearn <mike at plan99.net> wrote:
> Ah, I see, I didn't catch that this scheme relies on UTXO commitments
> (presumably with Mark's PATRICIA tree system?).
>
> If you're doing a binary search over block contents then does that imply
> multiple protocol round trips per synced block? I'm still having trouble
> visualising how this works. Perhaps you could write down an example run for
> me.
>
> How does it interact with the need to download chains rather than individual
> transactions, and do so without round-tripping to the remote node for each
> block? Bloom filtering currently pulls down blocks in batches without much
> client/server interaction and that is useful for performance.
>
> Like I said, I'd rather just junk the whole notion of chain scanning and get
> to a point where clients are only syncing headers. If nodes were calculating
> a script->(outpoint, merkle branch) map in LevelDB and allowing range
> queries over it, then you could quickly pull down relevant UTXOs along with
> the paths that indicated they did at one point exist. Nodes can still
> withhold evidence that those outputs were spent, but the same is true today
> and in practice this doesn't seem to be an issue.
>
> The primary advantage of that approach is it does not require a change to
> the consensus rules. But there are lots of unanswered questions about how it
> interacts with HD lookahead and so on.
>

📅 Original date posted:2015-02-20 📝 Original message:Mike ...

2023-06-07T17:30:43+02:00

In reply to nevent1q…asr2
_________________________

📅 Original date posted:2015-02-20
📝 Original message:Mike Hearn wrote:
> Adam Back wrote:
> > Its seems surprising no one thought of it
> > that way before (as it seems obvious when you hear it) but that seems
> > to address the privacy issues as the user can fetch the block bloom
> > filters and then scan it in complete privacy.
>
> And then what? So you know the block matches. But with reasonable FP
> rates every block will match at least a few transactions (this is already the
> case - the FP rate is low but high enough that we get back FPs on nearly
> every block). So you end up downloading every block?

I mean because the user is scanning he can binary search which set of
addresses from his wallet are possibly in the block and then request
the specific addresses and some will be false positives and some real,
but with the bloom commitment (and UTXO trie organised commitment) he
can verify that the positive hits are correct via the merkle path, and
that the false positives are not being wrongly withheld by obtaining
merkle path proof that they are not in the trie.

Adam

On 20 February 2015 at 16:54, Mike Hearn <mike at plan99.net> wrote:
> Hey Adam,
>
>>
>> Mike had posted a detailed response on the topic on why its complex
>> and becomes bandwidth inefficient to improve it usefully.
>
>
> To clarify, we could improve privacy and still preserve usefully high
> performance, it's just a lot of complicated programming work. You need to
> find out from the OS how much bandwidth you have to play with, for example,
> and do all the very complex tracking to surf the wave and keep yourself in
> roughly the right place.
>
>> The basic summary of which I think is that its not even intended to
>> provide any practical privacy protection, its just about compacting
>> the query for a set of addresses.
>
>
> The original intent of Bloom filtering was to allow both. We want our cake
> and we want to eat it.
>
> The protocol can still do that, with sufficiently smart clients. The problem
> is that being sufficiently smart in this regard has never come to the top of
> the TODO list - users are always complaining about other things, so those
> things are what gets priority.
>
> It's not IMO a protocol issue per se. It's a code complexity and manpower
> issue.
>
>>
>> Its seems surprising no one thought of it
>> that way before (as it seems obvious when you hear it) but that seems
>> to address the privacy issues as the user can fetch the block bloom
>> filters and then scan it in complete privacy.
>
>
> And then what? So you know the block matches. But with reasonable FP rates
> every block will match at least a few transactions (this is already the case
> - the FP rate is low but high enough that we get back FPs on nearly every
> block). So you end up downloading every block? That won't work.
>
> Eventually, wallets need to stop doing linear scans of the entire block
> chain to find tx data. That worked fine when blocks were 10kb, it's still
> working OK even though we scaled through two orders of magnitude, but we can
> imagine that if we reach 10mb blocks then this whole approach will just be
> too slow.
>
> The main reason wallets are scanning the chain today (beyond lack of
> protocol support for querying the UTXO set by script), is that they want to
> show users time-ordered lists of transactions. Financial apps should show
> you payment histories, everyone knows this, and without knowing roughly when
> a tx happened and which inputs/outputs were mine, providing a useful
> rendering is hard. Even with this data the UI is pretty useless, but at
> least it's not actually missing.
>
> By combining Subspace and BIP70 we can finally replace the payments list UI
> with actual proper metadata that isn't extracted from the block chain, and
> at that point non-scanning architectures become a lot more deployable.

📅 Original date posted:2015-02-20 📝 Original message:I saw ...

2023-06-07T17:30:42+02:00

In reply to nevent1q…2cqt
_________________________

📅 Original date posted:2015-02-20
📝 Original message:I saw there was some discussion on this topic on the bitcoinj list.

(I dont think I can post there without subscribing probably.)

Someone had posted about the lack of privacy provision from the
current implementation parameters and real-world factors similar to
described in this academic paper

http://eprint.iacr.org/2014/763.pdf

Mike had posted a detailed response on the topic on why its complex
and becomes bandwidth inefficient to improve it usefully.

https://groups.google.com/forum/#!msg/bitcoinj/Ys13qkTwcNg/9qxnhwnkeoIJ

The basic summary of which I think is that its not even intended to
provide any practical privacy protection, its just about compacting
the query for a set of addresses.

So I was wondering what about changing to committing a bloom filter of
the addresses in the block. Its seems surprising no one thought of it
that way before (as it seems obvious when you hear it) but that seems
to address the privacy issues as the user can fetch the block bloom
filters and then scan it in complete privacy. (Someone appeared on
bitcoin wizards IRC a while back and made this observation.)

>From there its a question of fetching the candidate TXOs.

Am I missing anything?

Adam

📅 Original date posted:2015-02-14 📝 Original ...

2023-06-07T17:30:33+02:00

In reply to nevent1q…gzs7
_________________________

📅 Original date posted:2015-02-14
📝 Original message:Strongly with Peter on this. That its highly complex to maintain strict
consensus between bitcoin versions, does not justify consensus rewrite
experiments; it tells you that the risk is exponentially worse and people
should use and rally around libconsensus.

I would advise any bitcoin ecosystem part, wallet, user to not use software
with consensus protocol rw-writes nor variants, you WILL lose money.

You could view bitcoin as a digital signature algorithm speculatively
tinkering with the algo is highly prone to binary failure mode and
unbounded funds loss.

Want to be clear this is not a political nor emotive issue. It is a
critical technical requirement for security if users of software people
write.

Please promote this meme.

Adam
On Feb 14, 2015 6:24 AM, "Tamas Blummer" <tamas at bitsofproof.com> wrote:

> Peter,
>
> You did not address me but libbitcoin. Since our story and your evaluation
> is probably similar, I chime in.
>
> On Feb 14, 2015, at 2:13 PM, Peter Todd <pete at petertodd.org> wrote:
>
> So stop wasting your time. Help get the consensus critical code out of
> Bitcoin Core and into a stand-alone libconsensus library,
>
>
> We have seen that the consensus critical code practically extends to
> Berkley DB limits or OpenSSL laxness, therefore
> it is inconceivable that a consensus library is not the same as Bitcoin
> Core, less its P2P service rules, wallet and RPC server.
>
>
> On Feb 14, 2015, at 2:13 PM, Peter Todd <pete at petertodd.org> wrote:
>
>
> Or you can be stereotypical programmers and dick around on github for
> the next ten years chasing stupid consensus bugs in code no-one uses.
>
>
>
> The Core code base is unfriendly to feature extensions because of its
> criticality, legacy design and ancient technology. It is also a commodity
> that the ecosystem takes for granted and free.
>
> I honestly admire the core team that works and progresses within these
> limits and perception.
>
> I am not willing to work within the core’s legacy technology limits. Does
> it mean I am dicking around? I think not.
> It was my way to go down the rabbit hole by re-digging it and I created
> successful commercial products on the way.
>
> It is entirely rational for me to focus on innovation that uses the core
> as a border router for this block chain.
>
> I am rather thankful for the ideas of the side chains, that enable
> innovation that is no longer measured on unapologetic compatibility with a
> given code base, but its services to end user.
>
> Tamas Blummer
> Bits of Proof
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150214/f093769e/attachment.html>;

📅 Original date posted:2014-10-25 📝 Original message:Some ...

2023-06-07T17:26:47+02:00

In reply to nevent1q…jla7
_________________________

📅 Original date posted:2014-10-25
📝 Original message:Some thoughts about Alex's analysis:

- bitcoin price may increase (though doubling immediately might be
unlikely) after the halving (because the new coins are in short
supply). Apparently there is some evidence of a feedback loop between
number of freshly mined coins sold to cover electrical costs ongoing
(which depends on halving also), in that there are claims that the btc
price experiences some downwards pressure when margins are slim as
miners sell almost all of them when the electrical cost takes most of
the profit, and otherwise tend more to hold coins longer term.

- that people who cant make money mining with 1/2 reward will resort
to attacking the network rather than living with it for 2weeks until
difficulty adjustment). actually it will be longer than two weeks if
its going to result in a difficulty fall.

- that the miners wont act in their own meta-interest to aim for the
plausible new hashrate supported by the lower reward. mining
equipment investment horizon being 3-6mo+ so it can easily make
economic sense to subsidise it for a bit to smooth the transition.

- fees might go up to unjam the network also, so the people
benefitting from the transactions utility also help cover the
transition costs. or maybe someone makes an assurance contract to pay
the short fall and phase it out over a few months to smooth the shift.

- there is a wide range of electrical efficiency, and some are much
worse than others so there maybe a convenient equilibrium where there
are enough left who can still profit.

- alternatively you might say why not 1/100th reward reduction per 2
week period rather than 1/2 every 4 years, a difficulty retarget could
be a convenient point to do that.

Adam

On 25 October 2014 11:06, Alex Mizrahi <alex.mizrahi at gmail.com> wrote:
> # Death by halving
>
> ## Summary
>
> If miner's income margin are less than 50% (which is a healthy situation
> when mining hardware is readily available), we might experience catastrophic
> loss of hashpower (and, more importantly, catastrophic loss of security)
> after reward halving.
>
> ## A simple model
>
> Let's define miner's income margin as `MIM = (R-C_e)/R`, where R is the
> total revenue miner receives over a period of time, and C_e is the cost of
> electricity spent on mining over the same period of time. (Note that for the
> sake of simplicity we do not take into account equipment costs, amortization
> and other costs mining might incur.)
>
> Also we will assume that transaction fees collected by miner are negligible
> as compared to the subsidy.
>
> Theorem 1. If for a certain miner MIM is less than 0.5 before subsidy
> halving and bitcoin and electricity prices stay the same, then mining is no
> longer profitable after the halving.
>
> Indeed, suppose the revenue after the halving is R' = R/2.
> MIM = (R-C_e)/R < 0.5
> R/2 < C_e.
>
> R' = R/2 < C_e.
>
> If revenue after halving R' doesn't cover electricity cost, a rational miner
> should stop mining, as it's cheaper to acquire bitcoins from the market.
>
> ~~~
>
> Under these assumptions, if the majority of miners have MIM less than 0.5,
> Bitcoin is going to experience a significant loss of hashing power.
> But are these assumptions reasonable? We need a study a more complex model
> which takes into account changes in bitcoin price and difficulty changes
> over time.
> But, first, let's analyze significance of 'loss of hashpower'.
>
> ## Catastrophic loss of hashpower
>
> Bitcoin security model relies on assumption that a malicious actor cannot
> acquire more than 50% of network's current hashpower.
> E.g. there is a table in Rosenfeld's _Analysis of Hashrate-Based Double
> Spending_ paper which shows that as long as the malicious actor controls
> only a small fraction of total hashpower, attacks have well-define costs.
> But if the attacker-controlled hashrate is higher than 50%, attacks become
> virtually costless, as the attacker receives double-spending revenue on top
> of his mining revenue, and his risk is close to zero.
>
> Note that the simple model described in the aforementioned paper doesn't
> take into account attack's effect on the bitcoin price and the price of the
> Bitcoin mining equipment. I hope that one day we'll see more elaborate
> attack models, but in the meantime, we'll have to resort to hand-waving.
>
> Consider a situation where almost all available hashpower is available for a
> lease to the highest bidder on the open market. In this case someone who
> owns sufficient capital could easily pull off an attack.
>
> But why is hashpower not available on the market? Quite likely equipment
> owners are aware of the fact that such an attack would make Bitcoin useless,
> and thus worthless, which would also make their equipment worthless. Thus
> they prefer to do mining for a known mining pools with good track record.
> (Although hashpower marketplaces exist: https://nicehash.com/ they aren't
> particularly popular.)
>
> Now let's consider a situation where mining bitcoins is no longer profitable
> and the majority of hashpower became dormant, i.e. miners turned off their
> equipment or went to mine something else. In this case equipment is already
> nearly worthless, so people might as well lease it to the highest bidder,
> thus enabling aforementioned attacks.
>
> Alternatively, the attacker might buy obsolete mining equipment from people
> who are no longer interested in mining.
>
> ## Taking into account the Bitcoin price
>
> This is largely trivial, and thus is left as an exercise for the reader.
> Let's just note that the Bitcoin subsidy halving is an event which is known
> to market participants in advance, and thus it shouldn't result in
> significant changes of the Bitcoin price,
>
> ## Changes in difficulty
>
> Different mining devices have different efficiency. After the reward halving
> mining on some of these devices becomes unprofitable, thus they will drop
> out, which will result in a drop of mining difficulty.
>
> We can greatly simplify calculations if we sum costs and rewards across all
> miners, thus calculating average MIM before the halving: `MIM = 1 - C_e/R`.
>
> Let's consider an equilibrium break-even situation where unprofitable mining
> devices were turned off, thus resulting in the change in electricity
> expenditures: `C_e' = r * C_e`. and average MIM after the halving `MIM' =
> 0`. In this case:
>
> r * C_e = R/2
> C_e / R = 1/2r
> (1 - MIM) = 1/2r
> r = 1/(2*(1-MIM))
>
> Let's evaluate this formulate for different before-halving MIM:
>
> 1. If `MIM = 0.5`, then `r = 1/(2*0.5) = 1`, that is, all miners can remain
> mining.
> 2. If `MIM = 0.25`, then `r = 1/(2*0.75) = 0.66`, the least efficient miners
> consuming 33% of total electricity costs will drop out.
> 3. If `MIM = 0.1`, then `r = 1/(2*0.9) = 0.55`, total electricity costs drop
> by 45%.
>
> We can note that for the before-halving MIM>0, r is higher than 1/2, thus
> less than half of total hashpower will drop out.
>
> The worst-case situation is when before-halving MIM is close to zero and
> mining devices, as well as cost of electricity in different places, are
> nearly identical, in that case approximately a half of all hashpower will
> drop out.
>
> ## MIM estimation
>
> OK, what MIM do we expect in the long run? Is it going to be less than 50%
> anyway?
>
> We can expect that people will keep buying mining devices as long as it is
> profitable.
>
> Break-even condition: `R - C_e - P = 0`, where P is the price of a mining
> device, R is the revenue it generates over its lifetime, and C_e is the
> total cost of required electricity over its lifetime. In this case, `R = C_e
> + P`, and thus:
>
> MIM = 1 - C_e / (C_e + P)
>
> `f = C_e / P` is a ratio of the cost of electricity to the cost of hardware,
> `C_e = f * P`, and thus
>
> MIM = 1 - f * P / (f * P + P) = 1 - f / (f + 1) = 1 / (1 + f)
>
> MIM is less than 0.5 when f > 1.
>
> Computing f is somewhat challenging even for a concrete device, as it's
> useful lifetime is unknown.
>
> Let's do some guesstimation:
>
> Spondoolies Tech's SP35 Yukon unit consumes 3.5 KW and costs $4000. If it's
> useful lifetime is more than 2 years and a cost of KWh is $0.1, the total
> expenditures on electricity will be at least $6135, thus for this device we
> have `f > 6135/4000 > 1.5`.
>
> If other devices which will be sold on the market will have similar specs,
> we will have MIM lower than 0.5. (Well, no shit.)
>
> ## Conclusions
>
> Reward halving is a deficiency in Bitcoin's design, but there is some hope
> it won't be critical: in the equilibrium break-even situation hashpower drop
> is less than 50%.
> Hashrate might drop by more than 50% immediately after the halving (and
> before difficulty is updated), thus a combination of the halving and slow
> difficulty update pose a real threat.
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

📅 Original date posted:2014-10-15 📝 Original message:please ...

2023-06-07T17:26:30+02:00

In reply to nevent1q…jfhf
_________________________

📅 Original date posted:2014-10-15
📝 Original message:please not google groups *, I'd vote for sourceforge or other simple
open list software over google groups.

Adam

* Google lists are somehow a little proprietary or gmail lockin
focused eg it makes things extra hard to subscribe with a non-google
address if google has any hint that your address is associated with a
gmail account. Quite frustrating.

On 15 October 2014 16:46, Mike Hearn <mike at plan99.net> wrote:
>> Great idea. Jeff Garzik was looking for a better mailing list solution
>> than SourceForge, but assuming
>> there isn't a clearly better solution I think "we" should create a
>> strictly moderated bitcoin-bips at lists.sourceforge list.
>
>
> Let's stay away from SF.net or any mailman-controlled lists if at all
> possible. They break DKIM signatures which means they're no longer
> compatible with Yahoo, all mail from Yahoo users gets spamfoldered
> immediately. Google Groups gets this right. Perhaps other list operators do
> too. Groups also has moderation features.
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

📅 Original date posted:2014-04-28 📝 Original message:On ...

2023-06-07T17:19:40+02:00

In reply to nevent1q…yt6n
_________________________

📅 Original date posted:2014-04-28
📝 Original message:On Sun, Apr 27, 2014 at 10:53:08PM +1000, Gareth Williams wrote:
>Bitcoin is this perfect /trustless/ mathematical machine [...]
>
>2. the economic majority will not cooperate to reinterpret history
>
> [this proposal was...] replacing it with:
>
>2. the economic majority will not cooperate to reinterpret history
>against any good guys, only against bad guys; "please trust their good
>judgement."

Nicely put.

I agree the idea of a populist vote to redistribute or remove mining reward
is an inelegant thing which would probably devolve into politics.

I think the reason that it would likely work out badly is that its not
provable, and so no consensus rule can be constructed requiring proof, so
then it risks devolving to a political decision.

Step 1: Finney attackers for hire anonymize their blocks (publish via Tor,
use a different reward address for each block, and each pool miner).
Demanding identification of blocks is generally undesirable for the
objective of avoiding centralization and policy abuse. Dont even think
about demanding identity, there is no identity in a distributed system.

Step 2: people send tracer payments through Finney attackers, and use that
evidence to decide to vote away their reward. (However the proof is
non-transitive so people can vote anyway they like for any reason).

Step 3: Finney attackers vote down other pools to make the point.

Adam

📅 Original date posted:2014-03-08 📝 Original message:Also ...

2023-06-07T17:14:38+02:00

In reply to nevent1q…94af
_________________________

📅 Original date posted:2014-03-08
📝 Original message:Also the other limitation for ECDSA is that there is no known protocol to
create a signture with a+b (where keys P=aG, Q=bG, R=P+Q=(a+b)G). without
either a sending its private key to b or viceversa (or both to a third
party).

With Schnorr sigs you can do it, but the k^-1 term in ECDSA makes a (secure)
direct multiparty signature quite difficult.

ps probably only 1 party needs to hash their key

P=aG
H(P) ->

<- Q=bG

P ->

Adam

On Sat, Mar 08, 2014 at 12:37:30PM +0200, Joel Kaartinen wrote:
> If both parties insist on seeing a hash of the other party's public key
> before they'll show their own public key, they can be sure that the
> public key is not chosen based on the public key they themselves
> presented.

📅 Original date posted:2014-03-21 📝 Original ...

2023-06-07T17:14:23+02:00

In reply to nevent1q…c5gh
_________________________

📅 Original date posted:2014-03-21
📝 Original message:According to Bernstein it's patent FUD (expired, ancient and solid prior
art).

http://lists.randombit.net/pipermail/cryptography/2013-August/005126.html

Adam

On Fri, Mar 21, 2014 at 12:33:57PM +0100, Mike Hearn wrote:
> Oh, one other reason I found - apparently RIM, at least in the past,
> has been telling CA's that they need to pay mad bux for the Certicom
> ECC patents. So that's another reason why most certs are still using
> RSA.

📅 Original date posted:2014-03-21 📝 Original message:Maybe ...

2023-06-07T17:14:22+02:00

In reply to nevent1q…mxjd
_________________________

📅 Original date posted:2014-03-21
📝 Original message:Maybe its time to explore raw ECDSA signed message based certs.

btw I dont think its quite 4kB. eg bitpay's looks to be about 1.5kB in der
format. And they contain a 2048-bit RSA server key, and 2048-bit RSA
signatures (256byte each right there = 512bytes). And even 2048 is weaker
than 256-bit ECDSA.

Adam

On Fri, Mar 21, 2014 at 11:25:59AM +0100, Andreas Schildbach wrote:
>On 03/20/2014 01:12 PM, Adam Back wrote:
>
>> Whats a sensible limit on practical/convenient QR code size?
>
>Technically 3 KB. In my experience codes above 1.5 KB become impossible
>to scan (ZXing scanner, 3 years ago). You will want to stay below 500
>bytes for convenient scanning. That said, I'm convinced there is a lot
>of room for scanning improvements.
>
>> How much of the payment protocol message size comes from use of x509?
>
>As said in the OP, a minimal PR uses 50 bytes. X.509 seems to put about
>4000 bytes on top of that.
>
>As you can see, we have quite some room for improvements to PR payload
>(PaymentDetails). X.509 certification will probably not be possible via
>QR, at least not until specialized CA's will issue space-efficient certs
>(using ECDSA?).

📅 Original date posted:2014-01-20 📝 Original ...

2023-06-07T17:12:24+02:00

In reply to nevent1q…jav5
_________________________

📅 Original date posted:2014-01-20
📝 Original message:Because the mnemonic is an encoding of a 128-bit random number using its
hash as a private key (or derived part of one) is not a problem, its just an
alternate alphabet encoding of the random private key.

Not being able to generically understand the checksum. Seems tricky to
solve other than say brute force eg H(mnemonic||1) mod 2^k == 0 where k is
the amount of check digit redundancy. But that might be expensive for a
trezor if k is very big at all. And then key = H(mnemonic).

Adam

On Mon, Jan 20, 2014 at 05:35:02PM -0500, Peter Todd wrote:
>On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
>> On Mon, Jan 20, 2014 at 11:42 AM, slush <slush at centrum.cz> wrote:
>>
>> > Hi all,
>> >
>> > during recent months we've reconsidered all comments which we received
>> > from the community about our BIP39 proposal and we tried to meet all
>> > requirements for such standard. Specifically the proposal now doesn't
>> > require any specific wordlist, so every client can use its very own list of
>> > preferred words. Generated mnemonic can be then applied to any other
>> > BIP39-compatible client. Please follow current draft at
>> > https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
>>
>> So, because the [mnemonic]->[bip32 root] is just hashing, you've
>> effectively made your "mnemonic sentence" into a brainwallet? Since every
>> mnemonic sentence can now lead to a bip32 root, and only the client that
>> created the mnemonic can verify the mnemonic passes its checksum (assuming
>> all clients use different wordlists, the only client that can help you if
>> you fat-finger the sentence is the client that created it)?
>
>That issue is more than enough to get a NACK from me on making the
>current BIP39 draft a standard - I can easily see that leading to users
>losing a lot of money.
>
>Have any wallets implemented BIP39 this way already in released code?
>
>--
>'peter'[:-1]@petertodd.org
>00000000000000009c3092c0b245722363df8b29cfbb86368f4f7303e655983a

>------------------------------------------------------------------------------
>CenturyLink Cloud: The Leader in Enterprise Cloud Services.
>Learn Why More Businesses Are Choosing CenturyLink Cloud For
>Critical Workloads, Development Environments & Everything In Between.
>Get a Quote or Start a Free Trial Today.
>http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2014-01-14 📝 Original message:I saw ...

2023-06-07T17:11:54+02:00

In reply to nevent1q…kz00
_________________________

📅 Original date posted:2014-01-14
📝 Original message:I saw in the math version you had said Q'=Q+H(S) and I presumed it was a
typo, but your code says the same thing. I presume you meant Q'=Q+H(S)*G
and therefore that Util.SingleSHA256() multiplies by G internally?

Adam

📅 Original date posted:2013-11-15 📝 Original message:While ...

2023-06-07T17:09:40+02:00

In reply to nevent1q…ehc9
_________________________

📅 Original date posted:2013-11-15
📝 Original message:While we're discussing the emotive (though actually of real relevance for
bitcoin user comprehension and sentiment) I couldnt resisnt to add some
trivia reference it is amusing that a currency rarely in history had to
deflate (remove 0s) rather than inflate (add 0s). Viz this hyperinflated
fifty trillion zimbabwe dollar note I carry in my wallet for bitcoin
contrast/amusement purposes:

http://www.ebay.com/itm/50-TRILLION-ZIMBABWE-DOLLARS-CURRENCY-MONEY-US-SELLER-/110671104681

I like Alan's suggestion to show both to avoid denomination confusion. That
is the one danger, and high risk given irrevocability.

Adam

📅 Original date posted:2013-06-19 📝 Original message:This ...

2023-06-07T17:03:31+02:00

In reply to nevent1q…n6zk
_________________________

📅 Original date posted:2013-06-19
📝 Original message:This maybe simpler and trivially compatible with existing type2 public keys
(ones that are multiples of a parent public key): send an ECDSA signature of
the multiplier, and as we know you can compute ("recover") the parent public
key from an the ECDSA signature made using it.

Adam

On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
>[q-th root with unknown no discrete log artefact]
>
>If it was a concern I guess you could require a proof of knowledge of
>discrete log. ie as well as public key parent, multiplier the address must
>include ECDSA sig or Schnorr proof of knowledge (which both demonstrate
>knowledge of the discrete log of Q to base G.)

📅 Original date posted:2013-06-02 📝 Original message:So the ...

2023-06-07T17:02:37+02:00

In reply to nevent1q…3muv
_________________________

📅 Original date posted:2013-06-02
📝 Original message:So the idea is that people may want to use proof-of-work unrelated to
bitcoin, and abuse bitcoin to obtain that proof, in a way denominated in BTC
(and with a published USD exchange rate). And the ways they can do that are
to:

a) create unspendable addresses (which maybe you cant compact in the UTXO
set if the unspendable address choices are not standardized)

b) spend to anyone which I take it goes to a random person who happens to
see the address first and race the "spend to me" out on to the network, and
hope miners dnt replace it with "spend to miner", which is insecure

c) doesnt delay by 100 blocks just delay the "spend to me" race? Also most
likely to be one by a big miner once they adapt and join the race.

d) some new standardized spend to fees (only miners can claim).

e) spend to charity/non-profit of choice could be useful also

f) I guess we see something related in zerocoin - locked but unlockable via
another type of transaction later.

g) why not instead make the beneficiary the address of the service the user
is consuming that is being DoS protected by the proof-of-sacrifice? Seems
more useful than burning virtual money, then it helps the bitcoin network
AND it helps the service provide better service!

so if I understand what you proposed d) seems like a useful concept if that
is not currently possible. eg alternatively could we not just propose a
standard recognized address that clearly no-one knows the EC discrete log
of?

Adam

On Sat, Jun 01, 2013 at 03:30:36PM -0400, Peter Todd wrote:
>Currently the most compact way (proof-size) to sacrifice Bitcoins that
>does not involve making them unspendable is to create a anyone-can-spend
>output as the last txout in the coinbase of a block:
>
>scriptPubKey: <data> OP_TRUE
>
>The proof is then the SHA256 midstate, the txout, and the merkle path to
>the block header. However this mechanism needs miner support, and it is
>not possible to pay for such a sacrifice securely, or create an
>assurance contract to create one.
>
>A anyone-can-spend in a regular txout is another option, but there is no
>way to prevent a miner from including a transaction spending that txout
>in the same block. Once that happens, there is no way to prove the miner
>didn't create both, thus invalidating the sacrifice. The announce-commit
>protocol solves that problem, but at the cost of a much larger proof,
>especially if multiple parties want to get together to pay the cost of
>the sacrifice. (the proof must include the entire tx used to make the
>sacrifice)
>
>However if we add a rule where txouts ending in OP_TRUE are unspendable
>for 100 blocks, similar to coinbases, we fix these problems. The rule
>can be done as a soft-fork with 95% support in the same way the
>blockheight rule was implemented. Along with that change
>anyone-can-spend outputs should be make IsStandard() so they will be
>relayed.
>
>The alternative is sacrifices to unspendable outputs, which is very
>undesirable compared to sending the money to miners to further
>strengthen the security of the network.
>
>We should always make it easy for people to write code that does what is
>best for Bitcoin.
>
>--
>'peter'[:-1]@petertodd.org
>00000000000000ce3427502ee6a254fed27e1cd21a656a335cd2ada79b7b5293

>------------------------------------------------------------------------------
>Get 100% visibility into Java/.NET code with AppDynamics Lite
>It's a free troubleshooting tool designed for production
>Get down to code-level detail for bottlenecks, with <2% overhead.
>Download for free and get started troubleshooting in minutes.
>http://p.sf.net/sfu/appdyn_d2d_ap2

>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2013-05-15 📝 Original message:btw I ...

2023-06-07T17:01:54+02:00

In reply to nevent1q…gkc0
_________________________

📅 Original date posted:2013-05-15
📝 Original message:btw I posted some of this thread on the dev forum:

https://bitcointalk.org/index.php?topic=206303.msg2157994#msg2157994

A related idea is occuring to me that maybe these committed transactions
could actually as a side effect make bitcoin scale slightly better by
reducing the p2p flood filled transaction size.

As I said on the forum:

> Note committed transactions are more compact than regular transactions -
> they are just two hashes, so they reduce network bandwidth and make
> bitcoin more scalable to the extent that transaction reveals stay off
> network. (As well as more secure against centralization policy risks).

Surely its lower bandwidth for nodes to send only committed transactions to
the p2p network, and pass committed payment chains direct to recipients.

Say committed transaction size is c (20bytes+32bytes+16bytes +header ~ 72
bytes?) And full transaction smallest size is t (txin=20bytes, amount out
4bytes, sender pub key 32bytes, recip address 20bytes, change address
20bytes, formatting 5 bytes, ECDSA signature 64bytes, script 10 byte surely
~ 175bytes)? Thats over twice the size. Probably average more, and it is
sent to every node. Its always going to be lower bandwidth to send
transactions to the recipients than to send to the network, even if you have
to increase the transaction size with each respend. The alternative is for
the entire network to see the same transaction.

I think the commitment needs to bind the two parts together eg

(blind-sender, auth-tag, tx-commit)

blind-sender = SHA1( SHA256( 1, pub ) )
auth = HMAC-SHA256-128( K, tx-commit )
tx-commit = SHA-256( tx )

Or some variantion, and you must not reuse the pub key, and must send change
if any to a different address, otherwise chain recipients or malicious
forwarders could lock your coin, by putting random junk onto the network
which would be unverifiable, and non-disclaimable - you cant prove you dont
know the preimage of some junk. The MAC prevents it. Maybe there's a more
compact way to do it even, but that works efficient demonstration of
security feasibility.

Other public key variants could be possible, P = xG is the ECDSA public key,
x the private key, G base point. Sender could reveal P' = cP, c some fixed
constant (computing c from cP is ECDL problem considered oneway & hard), and
a signature by private key x' = cx over the tx-commit. That is a publicly
auditable commitment also, but one tht can make an ECDSA signature over the
tx-commit hash, and can be revealed by revealing P later. However that
imposes public key computation on the validation (which it already currently
does, but faster validation as above is nicer). With that one you dont even
have to verify the transaction signature on reveal :) You already did it,
just provide the tx that hashes to the signed hash, and P for the recipient
to verify the signature was made by cP.

Adam

📅 Original date posted:2013-05-15 📝 Original message:On ...

2023-06-07T17:01:53+02:00

In reply to nevent1q…u4k3
_________________________

📅 Original date posted:2013-05-15
📝 Original message:On Wed, May 15, 2013 at 08:40:59AM -0400, Caleb James DeLisle wrote:
>If the commitment is opaque at the time of inclusion in the block then
>I will create multiple commitments and then after revealing the
>commitment and spend to you I will reveal the earlier commitment which
>commits the coins to an address I control.

Bit-commitments are based on deterministic one-way functions eg like SHA1(
SHA256( public key ) ) Obviously it has to be a different one-way function
to the coin address calculation which is RIPEMD( SHA256( public key ) ) as
that is already public. Alternatively it can be a different serialization
using the same hash eg RIPEMD( SHA256( 1 || public key ) ).

There is only one commitment possible per public key - so you can only
create one commitment that would validate to a receiver, or to the network.
The network checks that there are no non-blind double spends of committed
coins which it can do as spends require disclosure of the public key, which
allows existing commitments to be verified, and it similarly qchecks that
there are no blind double-commitments.

Each committed coin would be:

one-spend-commit = Com( spender pub ), Com( transaction )

where Com is implemented as the above hash. The network just places the
commitments in order as with conventional transactions.

The committed coins are not linkable to your non-blind coin because you did
not reveal your public key in the (largely passive) act of receiving to a
coin address.

>On the topic of reversibility, I suspect in the long term the lack of
>chargebacks will create issues as criminals learn that for the first
>time in history, kidnap & ransom is effective.

The temporary unlinkability (until commitment reveal) is a necessary side
effect, not a cryptographic anonymity feature like zerocoin. The
transactions are identical to bitcoins once revealed. How long the
committed transaction chains can be between reveals is an implementation
choice could be 1 hop, or as long as you like. (Actually it appears to be
up to the individual users how long the maximum chain they accept is - the
network itself, though ordering the committed spends (if there are multiple
spends on the same key) cant even tell how long the commitment payment
chains are).

Obviously the first coins in the network ordered committed coins on the same
key up to the coin value are spends as verified by the recipient, the rest
are double-spend and ignored. If someone wants to waste fees by sending
more spends than there inputs thats up to them.

Probably the typical user doesnt care about long committed chains other
than their wallet will bloat if the chains are too long, so probably they
would periodically compact it by revealing the long chains. Committed coins
are probably a bit less SPV client friendly, though with correct formatting
in the merkle trees between blocks, probably a committed coin holder can
provide enough proof to an SPV client to verify even multi-spend committed
coins directly (without a network feed).

About privacy, up to the entire commitment chain can be opened at any time
(to other people or to the bitcoin network in general) with the cooperation
of any user on the chain (up to the point they saw it), so while the blind
commitment protocol is not vulnerable to a > 50% power quorum unilaterally
imposed policy (without even needing client updates), it is fully dependent
on the good will of the recipients for its temporary unlinkability. Thats
the point: it puts policy control in the users hands not in the > 50% power
quorum.

If you want cryptographic anonymity its better to look to zerocoin. You may
have noticed zero coin talked about optional fraud tracing. Its usually
trivial to add tracing to an otherwise privay preserving protocol.

The blind commitment if implemented as described (and its not obvious how to
get more privacy from it) offers somewhat like community policing. Users on
the chain can still themselves do fraud tracing, or any policy they choose,
on any blind committed coins that they receive. If they dont like the
colour of them they can refund them. The point is to enforce that this is a
free uncoerced community choice, by individual end users, not a > 50% cpu
power quorum choice surreptitiously imposed.

Adam

📅 Original date posted:2013-05-15 📝 Original message:On ...

2023-06-07T17:01:52+02:00

In reply to nevent1q…3lsm
_________________________

📅 Original date posted:2013-05-15
📝 Original message:On Wed, May 15, 2013 at 07:19:06AM -0400, Peter Todd wrote:
>Protocols aren't set in stone - any attacker that controls enough
>hashing power to pose a 51% attack can simply demand that you use a
>Bitcoin client modified [to facilitate evaluation of his policy]

Protocol voting is a vote per user policy preference, not a CPU vote, which
is the point. Current bitcoin protocol is vulnerable to hard to prove
arbitrary policies being imposable by a quorum of > 50% miners. The blind
commitment proposal fixes that, so even an 99% quorum cant easily impose
policies, which leaves the weaker protocol vote attack as the remaining
avenue of attack. That is a significant qualitative improvement.

The feasibility of protocol voting attacks is an open question, but you
might want to consider the seeming unstoppability of p2p protocols for a
hint.

Adam

📅 Original date posted:2013-05-15 📝 Original message:So in ...

2023-06-07T17:01:51+02:00

In reply to nevent1q…lwcr
_________________________

📅 Original date posted:2013-05-15
📝 Original message:So in a previous mail I described a simple, extremely efficient and easy to
implement symmetric key commitment that is unlinkable until reveal time (at
bottom). I think this can help improve the byzantine generals problem, that
bitcoin only defends to simple majority (with one vote per CPU power), and
so assumes most nodes by cpu power are honest. With this simple protocol
change you dont need any honest nodes, just some honest clients to spend to,
to have your transaction accepted.

You can think of this in terms of a (somewhat distributed) server performing
validations, but in a way that it sufficiently blind to the details of the
validations that it can not selectively enforce a policy, it power is
limited to random DoS.

There are other situations where you can rely on a server for one property
but not another - eg a somewhat distributed encrypted backup (like Tahoe
LAFS) you rely on for availability, but not integrity nor confidentiality
(because you encrypt those, and some sharing scenarios still work.) So this
is in that class of protocols - zero-trust in server, but can extract
service and some guarantees from the (optionally distributed) server anyway.

(Bitcoin does not use known better than majority results for byzantine
generals based on fair coin toss, relying instead on simple majority and an
assumed largely unjammable network. I notice Nick Szabo was complaining
about this on his blog and saying bitcoins majority is not even a standard
or proven byzantine voting protocol - something adhoc. I think the bitcoin
unjammable network assumption is a false at the limit so that someone with
strong network hacking capabilities can create network splits long enough to
even overcome the network majority vote without having any compute power of
their own. All they need is to have a split with enough power to plausibly
quickly get the victims their desired number of (split) confirmations.)

Anyway this should be a clear voting improvement, that is efficient.

Imagine a couple of big pools or ASIC miners started enforcing some
arbitrary coin policy, eg say coins must not have some taint according to
its list of black coins, or coins must be certified by some entity, be
traceable to some type of event etc. Well call these miners/voters
"dishonest", in that they are not following the intended zero-policy
protocol.

If the coins dont match their chosen policy, the dishonest miners will
refuse to include transactions in blocks they issue. If they see a
transaction which does not match their policy in a block by someone else
they will ignore it and try to make it into an orphan. As they have say 75%
of the network power they can do that successfully. Even with current
validation protocols in the clients, so the "but clients wont accept the
change" argument does not apply - the existing clients will accept the
policy change, because they cant detect it, nor prove it, and dont have the
voting power to impose honest policies.

(For realism of this risk, note that according to Kaminsky there already
exist multiple entities with reserve ASIC power each exceeding current
network difficulty who are holding part of their power in reserve for profit
maximisation reasons. This is a coming to fruition of the concentration of
power issue I was talking about in my first bitcoin forum post. People who
have that kind of power in reserve have clearly invested millions of
dollars, which probably makes them more vulnerable to political influence.)

Alright so the solution. Use the commitment protocol (below) which even
though it is symmetric key strongly hides the committed transaction public
key. (Symmetric in the sense that the validation steps are all highly
efficient symmetric key based). Now send the transaction (which includes
the public key) direct to the receiver, over a secure channel, or an assumed
non-eavesdropped direct channel, with no p2p flood of the transaction. The
receiver can check the hash to the commitment, and decide how many
confirmtions he needs. Once he has eg 6 confirmations he reveals the
commitment to the transaction (by publishing it). The sender may also send
the reveal/transaction to the network directly himself, if the recipient is
offline. However there is no advantage to publishing early so it seems
better to let the recipient do it when he is ready to incorporate the
payment into his wallet.

Now the powerful dishonest voters if they try to apply their policy when
they see the reveal triggers it, must redo the work of the 6-commitments
that they computed themselves. This is like starting 6-steps behind in the
statstical gamblers ruin game that Nakamoto describes in the bitcoin paper.
Consequently even with 75%, they will find it very hard to outcompete their
own prior work, to create a 6 chain long orphan while the 25% is moving
forward on the honest chain. Each time they see transactions which violate
their policy, they have to restart their chain recalculation again from
scratch. Often if simple lower powered intermittent recipient sends the
coin will be burried hundreds of blocks back. In addition 6 chain long
branches are extremely unlikely with honest payers, so clients can (and
maybe already do?) act with suspicion of they see one.

Going further, I said for best security, the recipient should never even
reveal (to the network) until he is actually about to spend, but futher he
does not even have to reveal publicly ever, he can choose to reveal only to
the recipient with a direct connection (no p2p flood fill of transaction.)
And the direct spend argument composes, ie the 2nd recipient can not do the
same thing again. (public key A sends to public key B sends to public key
C: B publishes COM( transaction B->C ), sends the reveal of COM( transaction
A->B ), and COM transaction B->C ) to C. C waits 6 confirmations and is
convinced. So its the approach is composable, and in fact the network
doesnt learn the size of the transaction even, though the spend grows each
time. Eventually presumably someone will publish will the confirmations to
the network to trim the tansaction size, though it is not strictly
necessary, and the transaction flow is small and direct (no network scaling
issues), so that it wouldnt be a huge problem to have a 1MB payment
representing 1000s of hops of network blind transactions. (For the
composable network blind respending the commitment has to commit publicly to
both the sender and next hop recipient keys, so the network can see how long
the chain is).

Probably you can cope with multiple inputs and outputs, and maybe given even
you can work with a 100% dishonest network mining network (all the dishonest
miner can do is selectively DoS transactions if they are all network blind
except the mining), maybe the mining can even be decoupled from the voting,
as you no longer demand much from the voting process. That admits more
interesting things like pool free direct mining, low variance hashcash
coins, probably. Many things to think through.

I suppose the commitment could be described as a blind symmetric commitment.

Adam

On Tue, May 14, 2013 at 04:09:02PM +0200, Adam Back wrote:
> [...]
>
>One related concept is commitments. I think its relatively easy to commit
>to a payment and lock a coin without identifying yourself, until the
>commitment is released. You might do the commitment, wait 6-blocks for
>confirmation, then reveal the commitment. Then that is like a self-issued
>green coin with no need for trust, that can be immediately cleared. The
>recipient has to be committed to at the same time to prevent double
>spending.
>
>So just commit = H( input-pub ) H( transaction ) and put it in the block
>chain. Where transaction the is usual ( input signature, output-pub,
>script). (Fee for the commit would have to come from an unlinked coin or
>the input-pub reveals the coin). Wait 6 blocks, send/reveal the transaction
>(free because fee was already paid). Validators check input-pub hash
>against committed coins by hash, check the transaction hash, and the usual
>ransaction validations = sum inputs, otherwise reject. The user better pay
>change if any to a different public key, as the inputs public keys are one
>use - are after the reveal they are DoS lockable by other people reposting
>H( input-pub ).
>
>The input-pub coin is locked as normal transactions have their public key hash
>validate as not being locked.
>
>Adam

📅 Original date posted:2013-05-14 📝 Original message:On ...

2023-06-07T17:01:47+02:00

In reply to nevent1q…mxlf
_________________________

📅 Original date posted:2013-05-14
📝 Original message:On Tue, May 14, 2013 at 12:50:27PM -0400, Jeff Garzik wrote:
>> Well if it is a later transaction, not an integral part of the reward
>> transaction (that is definitionally mined by being serialized into the
>> coinbase), the user may elect to withhold the promised transaction
>> give-to-miner, so thats not so good. [...]
>[...]
>Just referring to a standard, fee-bearing, user-created bitcoin
>transaction, where output_value < input_value. The fee is paid to the
>first miner who includes that transaction in a block, as part of the
>protocol.

Yes but thats inferior in the sense that it is spamming the bitcoin payment
protocol slightly, to the small reward of miners, and involves actual money
and traceability to real-name (where did you get the coin from to spend).

If alternatively you just proof you direct mined on a block with a coinbase
that immediately makes payment to future miners its better because: a) you
can do that with no new traffic for the bitcoin network (except when you
mine a whole block, you'll post it); and b) anyone with a reasonable
verification on the blockchain head (even if the spender has to give it to
them!) can verify it without any other network traffic; and c) if its
micro-mined on the spot it can be bound to the service whereas if you give
it to fees as an on network transaction you are limited to values above the
min tx fee.

So idealy I think you need to be able to simultanously mine and give reward
to future block miners.

What you could do with out that is d) mine for the reward of bitcoin
foundation/software author/or service provider. In the last case (service
provider) its an extreme form of Rivests peppercoin probabilistic payment

Adam

📅 Original date posted:2013-05-14 📝 Original message:On ...

2023-06-07T17:01:46+02:00

In reply to nevent1q…r6tw
_________________________

📅 Original date posted:2013-05-14
📝 Original message:On Mon, May 13, 2013 at 06:00:27PM -0400, Jeff Garzik wrote:
>When a transaction's input value exceeds its output value, the
>remainder is the transaction fee. The miner's reward for processing
>transactions is the 25 BTC initial currency distribution + the sum of
>all per-transaction fees. A destroy-by-miner fee transaction is a
>normal bitcoin transaction sent by any user, that might look like
>
>Input 1: 1.0 BTC
>Output 1: 0.5 BTC
>
>(the miner fee is implicitly 0.5 BTC, paid to whomever mines the
>transaction into a block)
>
>Sadly the bitcoin protocol prevents zero-output,
>give-it-all-to-the-miner transactions.

Well if it is a later transaction, not an integral part of the reward
transaction (that is definitionally mined by being serialized into the
coinbase), the user may elect to withhold the promised transaction
give-to-miner, so thats not so good.

Or do you mean to say you could have (implicit reward 25BTC) and reward
transaction .001 BTC to self and 24.999 BTC with existing bitcoin format and
validation semantics? That would be close enough to give-to-miner. Also
the output sum > 0BTC limitation could be changed to >= maybe... (just one
well placed character :)

Adam

📅 Original date posted:2013-05-13 📝 Original message:Some ...

2023-06-07T17:01:44+02:00

In reply to nevent1q…9wsh
_________________________

📅 Original date posted:2013-05-13
📝 Original message:Some musings about the differences between Peter's proof-of-sacrifice (you
did the work but elected to make the small reward chance unclaimable), vs
conventional actually doing the work but then destroying the bitcoin!

- proof-of-sacrifice seems similiar to hashcash except its difficulty is
time stamped and measured against the bitcoins dynamic difficulty,
(coordinated inflation control being something posited but never
implemented in hashcash). So thats kind of interesting, particularly if
you can do it with very low bandwidth, and decentralized; unclear.

- with proof-of-sacrifice its more offline because you do not need an on
block-chain double spend protection (via flood-fill, validation, and block
chain mining) because it is simply "unspendable", though you could show
the same proof to multiple people. In any case the values are far too low
to spam the block chain with.

- because proof-of-sacrifice is small you can afford to mine them on the
spot and make them payable to the identity of the recipient, like cheques:
they identify the recipient, so they are automaticaly non-respendable in
the eyes of the recipient (he keeps his own double-spend db, and people
wont accept cheques made payabe to other people). This is how hashcash
works for email. Also a time-stamp ensures you dont even need a big
double-spend db, as you can prune it if you reject expired cheqes.

- you could give a proof-of-sacrifice a private key, just like bitcoins;
then they could be pre-mined and identity or other info could be signed
later. However then you have double spending issues again. You can

- I mentioned amortizable hashcash under-contribution feature you can make
it so the recipient uncovers the actual value of the coin (if it is
merge-mined). (Put recipient public key in coinbase, hash for min share
size eg 32-bits leading 0s call that "collision"; send to recipient, he
decrypts the hash with private key, so the decryption is verifiable with
public key. Then the full value of the coin is
zerobit( collision ) + zerobits( decrypt( collision ) )
if that alternate validation was allowed in bitcoin.

- what about if a pool could lock the reward (rather than receive it or
destroy it) eg some kind of merkle root instead of a public key hash in
the reward recipient address field in the coinbase. Then the miners who
created that block have actual share proofs that are claims against
something eventually redeemable. Maybe if they collect enough
share-proofs to reach a minimum bitcoin transaction size, they can redeem
a big strip of shares for a few mBTC, but claims below that are rejected
by the network due to tx fee. (btw I think it seems possible to have a
publicly auditable pool so it cant skim nor disclaim shares.)

>I've been thinking about a decentralized way to create an anonymous
>identity, something I think it key to any number of decentralized, P2P
>and anonymous markets.

There were some systems that charged hashcash for pseudonyms i2p names (i2p
is a ToR like system)... see htp://www.i2p2.e/naming.html then there was of
course namecoin. There was some remailer/email nymserver integration as
well.

>Getting back on topic, somewhat, one idea I had for creation cost of a
>SIN was associating the creation cost of a SIN with a bitcoin
>transaction's miner fee. Anybody in the world could, therefore,
>create a SIN in a decentralized fashion, simply by following a
>published protocol for burning a specified amount of bitcoins via
>miner fee. It can be cryptographically proven with 100% certainty who

Yes it seems that having a proof-of-sacrifice that hardens the block chain
is the important part.

When you said destroy-via-miner-fee:

>Don't forget: 4. destroy-via-miner-fee, which is useful because it
>provides funding for a public service (bitcoin transaction
>verification).

Is that directly possible? Because the reward transaction has no source,
and no fee? Or can you put a 25BTC fee in the reward transaction in the
coinbase?

If so that seems like the best option for proof-of-sacrifice rather than
proving destroying the possibility of reward. But alternatively the bitcoin
foundation as recipient, or EFF etc. 25BTC is a big reward might have some
double roll-over lottery effects - everyone piles in for the occasional
25BTC!

Adam

On Mon, May 13, 2013 at 02:38:15PM -0400, Jeff Garzik wrote:
>On Mon, May 13, 2013 at 6:54 AM, Adam Back <adam at cypherspace.org> wrote:
>> On Mon, May 13, 2013 at 07:31:21AM +0000, John Dillon wrote:
>>>[with] merge-mining [you get] more value from just one unit of work.
>>
>> correct.
>>
>>>But Peter's coinbase hashcash protocol carefully ensures [...] the amount
>>>of value the miner would have then given away in a "anyone-can-spend"
>>>output.
>>
>> I think there are 3 choices:
>>
>> 1. merged-mine (almost zero incremental cost as the bitcoin mining return is
>> still earned)
>>
>> 2. destroy bitcoin (hash of public key is all 00s so no computible private
>> key)
>>
>> 3. anyone-can-spend (= first to spend gets coin?)
>
>Don't forget: 4. destroy-via-miner-fee, which is useful because it
>provides funding for a public service (bitcoin transaction
>verification).
>
>(a tangent, but related)
>
>I've been thinking about a decentralized way to create an anonymous
>identity, something I think it key to any number of decentralized, P2P
>and anonymous markets. My main focus, for this identity project, is
>to develop a decentralized protocol for generating a UUID-like unique
>identifier (bitstring), in a way that has some amount of creation cost
>attached (to prevent creating a billion of such tokens etc.). I call
>it a system identifier, or SIN.
>
>Once you have a SIN, you may associate the SIN with a GPG fingerprint,
>email address, real name, login credentials, etc. eBay-like
>marketplaces publish SIN ratings (though it displays on screen as
>"jgarzik" not "1234-abcd-5678-def0"). Standard-and-Poors style
>ratings agencies would similarly rate a business's SIN. SIN's build a
>reputation and trust over time, while controlling their own anonymity
>(or lack thereof). Anybody may abandon a SIN at any time. Ownership
>of a SIN is cryptographically proven via digital signature.
>
>Getting back on topic, somewhat, one idea I had for creation cost of a
>SIN was associating the creation cost of a SIN with a bitcoin
>transaction's miner fee. Anybody in the world could, therefore,
>create a SIN in a decentralized fashion, simply by following a
>published protocol for burning a specified amount of bitcoins via
>miner fee. It can be cryptographically proven with 100% certainty who
>made such a transaction, and the miner fee attaches a creation cost to
>ensure that SINs are not -too- cheap.
>
>Burn-via-miner-fee is a useful tool outside of this example. It funds
>a public service, providing a positive feedback loop for miners who
>receive fees via such services.
>
>--
>Jeff Garzik
>exMULTI, Inc.
>jgarzik at exmulti.com

📅 Original date posted:2013-05-13 📝 Original message:On ...

2023-06-07T17:01:43+02:00

In reply to nevent1q…g3m6
_________________________

📅 Original date posted:2013-05-13
📝 Original message:On Mon, May 13, 2013 at 07:31:21AM +0000, John Dillon wrote:
>[with] merge-mining [you get] more value from just one unit of work.

correct.

>But Peter's coinbase hashcash protocol carefully ensures [...] the amount
>of value the miner would have then given away in a "anyone-can-spend"
>output.

I think there are 3 choices:

1. merged-mine (almost zero incremental cost as the bitcoin mining return is
still earned)

2. destroy bitcoin (hash of public key is all 00s so no computible private
key)

3. anyone-can-spend (= first to spend gets coin?)

Surely in 3 if you mine the bitcoin its no particular assurance a you will
do your best to make sure that it is *you* tht spends it, so it devolves to
merged-mine. (Eg delay revealing it for 10 seconds while you broadcast your
spend widely)

Peter talks about value, but the proof only proves cost equal to bitcoin.
Those are not the same thing. And they are so-far non-respendable.

I still dont understand what he was saying. If you do please speakup.

I think potentially a publicly auditable pooled mining protocol would be a
place to start thinking about respendble micropayments. I made a post
on the bitcointalk forum outlining how that could be done:

https://bitcointalk.org/index.php?topic=1976.msg2035637#msg2035637

if you have a publicly auditable pool, where users can prove to each other
outside of the bitcoin transaction log that they contributed a number of
shares to a block, those could be traded somehow. Possibly eg with the pool
keeping a double-spend db. If the payments are low value, people maybe
happy trusting a pool. If the pool cheats, everyone stops using the pool.
You rely on the pool not to spend the backing bitcoin blocks. But it
remains possible for the pool to cashout people who collected enough shares.
Probably you could do that with blinding if desired.

>> [probabilistic micro-payments]
>
>I think you are misremembering [...] It is not a probabalistic scheme.

You are right I was thinking of Rivest's peppercoin.

>> In this way one can merge mine bitcoin & hashcash to the benefit of the
>> recipient (or some beneficiary trusted not to be paying the proceeds to the
>> spammer). And in a way that scales to email scale, and does not involve
>> installing a bitcoin client in every client, nor mail server.
>
>Blockchain header data may very well be one of the most widely distributed
>single data sets in the history of mankind, and most of its closest cousins are
>definitions such as the ASCII table or near definitions like the DNS root
>servers. Not something with new data every 10 minutes.

Well there doesnt need to be a one-true-blockchain DNS, though the power to
output a hash at any reasonable rate is a big proportion of the network
power. And the outputs are instantly verifiable, so it forms a kind of
trapdoor hashchain (where the trap door is not a secret but havng a huge
amount of CPU power). And there can and should be many blockchain via DNS.

For namesaces in general another approach other than DHT/flood is numerous
competing hierarchical, heavily cached, but publicly auditable. Cheaters
are shunned. Same effect, more scalable, most people are not cheating most
of the time.

http://cypherspace.org/p2p/auditable-namespace.html

Adam

📅 Original date posted:2013-05-11 📝 Original message:I ...

2023-06-07T17:01:42+02:00

In reply to nevent1q…naa2
_________________________

📅 Original date posted:2013-05-11
📝 Original message:I didnt quite understand the writeup and the references were ambiguous.

But if you are talking about bitcoin/hashcash merged mining for email: it is
something I think should possible. Of course for email the scale means
bitcoin style flood-fill and direct tiny payments are completely out of the
question, thats why hashcash itself has no communication overhead other than
a header in the mail - its only scalability limit is email itself.

Rivest's PayWord for people who dont know the reference in this context is
the observation that for a low value micro-payment, you dont mind if you
only receive a payment 1 time in k so long as the expected payment is n
after receiving n (eg satoshi sized) payments. Eg like a penny tip jar so
long as your expected payment is correct long term (win as often as you
lose) you dont mind. And a fair 100% payout lottery can be fun of itself.

So let say each email client sends in an email header the head of the
bitcoin hash chain, it has seen via other emails, which can be offline
verified back to the genesis hash. Maybe some clients even have bitcoin
installed and ask the bitcoin client for the hash chain head. The client
also generates an address on setup, and sends its bitcoin address in a
header. If you send to a new address you dont know their address, so you
send to eg me (Adam;) as a default, or the bitcoin foundation, or an invalid
address to destroy the coin - the recipient assumes that is not the sender
as those address are in the client. A sender can under-contribute but makes
no gain. Under-contributing is fixable if desired (see under-contribute in
amortizable hashcash paper, but using PK decryption with recipients private
key x as its non-interactive b'=D(x,share).)

Then clients merge mine involving the recipients bitcoin address (or one of
the default addresses).

Even if the merged stamp provdes to be an orphan, even a very old one, its
valid in a hashcash anti-spam sense, meeting the same purpose as destroyed
coin.

Maybe one can put the bitcoin hash in DNS with a 5min TTL and have mail
clients read that to reduce scope for stale mining.

In this way one can merge mine bitcoin & hashcash to the benefit of the
recipient (or some beneficiary trusted not to be paying the proceeds to the
spammer). And in a way that scales to email scale, and does not involve
installing a bitcoin client in every client, nor mail server.

Adam

On Sat, May 11, 2013 at 12:53:42AM -0400, Peter Todd wrote:
>It has been previously(1) proposed that hashcash using the same PoW
>function as the Bitcoin block hashing algorithm be used to create
>hashcash whose value is denominated in Bitcoins. This poses two problems
>however: widespread use of such hashcash would harm overall network
>security and determining the value of the hashcash requires knowing the
>revenue miners can gain from transaction fees at a given block height -
>a non-computable function. However, with some modifications we can
>extend the idea to directly denominate the hashcash in Bitcoins at the
>cost of a small increase in proof size.
>
>Recall that the fundemental problem is the need to do some work to make
>digest D have value V, resulting in a proof that can be given to a third
>party. We want V to be denominated in Bitcoins, and we want the actual
>economic cost to create P to be as close as possible to the face-value
>V. Finally should computing P result in a valid Bitcoin block header,
>the creator of the proof should have a strong incentive to publish their
>header to the P2P network and extend the current best chain.
>
>
># Proof structure
>
>Lets look at the elements of the proof from the block header to the
>digest.
>
>
>## PoW Block Header
>
>This must be a valid block header. It is particularly important to
>ensure that the header can be linked to the actual blockchain, although
>the header itself does not need to be a part of the chain, and hence the
>block hash does not need to meet the difficulty requirements.
>
>
>### Previous Block Headers
>
>The proof may optionally include one or more previous block headers in
>the event that the PoW block header's previous block is an orphan.
>Unlike the PoW block header, these block headers MUST meet the
>difficulty requirements although an implementation MAY skip actually
>checking the difficulty if a difficulty retarget has not happened or the
>PoW is timestamped. (see below)
>
>
>## Partial Transaction and Merkle Path
>
>The partial transaction consists of a SHA256 midstate followed by
>exactly one transaction output. The merkle path to the PoW block header
>MUST prove the transaction was the coinbase transaction and not any
>other transaction.
>
>
>## Transaction Output
>
>The last transaction output must have a scriptPubKey consisting of
>exactly one PUSHDATA op which pushes H(D | N) to the stack. Its value,
>V', is the basis for determining the value of the proof of work. V' must
>satisfy V' < k*Vi(h) where Vi is the inflation reward for the PoW block
>height and k < 1 For a number of reasons, including making sure there
>are strong incentives for broadcasting succesful PoW solutions, the
>value of k should be chosen fairly conservatively; the author suggests k
>= 1/10 as a ballpark figure. Finally N is some fixed value specific to
>hashcash of this form to ensure the txout proof can-not be reused.
>
>Vi can also be calculated as the median of the last n "anyone-can-spend"
>outputs seen in coinbases when the value of the inflation reward falls
>low enough that using the inflation reward is impractical.
>
>
>## Timestamp
>
>If the proof-of-work is used after a difficulty retarget the PoW needs
>to be timestamped in the block chain with a merkle path leading to a
>valid block header. The difficulty used for calculating the value of the
>PoW then becomes the minimum of the difficulties of the PoW previous
>block and the timestamp.
>
>
># Determining the actual value of the PoW
>
>The proof proves that work was done to find a valid block header. That
>block header, had it met the difficulty threshhold, could have created a
>valid block worth at least the inflationary reward Vi(h) to the miner.
>
>The coinbase transaction output and merkle path shows that were such a
>block found, the miner would have then given away V' to whomever managed
>to create a transaction spending it when the coinbase matured. The
>coinbase takes 100 block to mature, so the chance of any one miner
>collecting it is proportional to the hashing power they control.(*)
>
>*) As with fidelity bonds we make the assumption that no party controls
>more than 50% of the hashing power - the assumption underlying Bitcoin's
>security anyway. If this assumption is proven incorrect or
>insufficiently strong, possibly due to a cartel of miners banding
>together to create low-cost PoW's, the output can use the provably
>unspendable/prunable OP_RETURN <digest> scriptPubKey instead with a
>non-zero value.
>
>With P(block hash, target), the expected probability of a valid PoW
>being found given the work required to create the block hash with the
>given difficulty target, we can finally calculate the value of the PoW
>in terms of expected cost: V = P(hash, target) * V'
>
>
># Pool implementation and 51% attack security
>
>Because doing the work required to create coinbase txout hashcash is
>sufficient to also create a valid block a pool can safely rent out
>hashing power to create hashcash of this form on demand without making
>it possible to rent large amounts of hashing power directly on short
>notice. (though some extensions to GetBlockTemplate for hashers
>verifying it may be required)
>
>Because the anyone-can-spend txout is the basis for the value of the
>hashcash the value remains computable even if transaction fees become a
>larger proportion of the block reward in the future.
>
>Unlike announce-commit sacrificies(2) proofs with very small values can
>be easily created; the pool operator can make a trade-off between the
>profit varience - remember that a block header with a valid PoW
>represents a loss - and latency by adjusting the proof of work
>difficulty and V'.
>
>As an aside, note how the mechanism of a anyone-can-spend txout in a
>coinbase can replace the announce portion of an announce-commit
>sacrifice; a coinbase transaction is the only case where a single merkle
>path proves that the transaction output was possible to spend in a
>subsequent block, but was not yet spent; also an argument for allowing
>coinbase transaction inputs.
>
>
># Application: Paying for additional flood-fill bandwidth
>
>Additional messaging applications built on top of the Bitcoin P2P
>network would be useful, yet there needs to be some general mechanism to
>make DoS attacks expensive enough that they are impractical. For
>instance a useful P2P network feature would be a mechanism to propose
>trust-free coin mixes transaction outputs, propose specific txout sets,
>and finally a mechanism to broadcast valid ANYONECANPAY signatures so
>the inputs and outputs can become a valid transaction. By separating the
>txout and signature broadcasts, who is paying for what output is made
>very difficult to determine.
>
>Of course such a mechanism will likely come under attack by those trying
>to combat anonymity. However with the coinbase txout hashcash mechanism
>those attackers are forced to either contribute to the security of the
>Bitcoin network or incur much higher opporuntity costs for conducting
>their attack than honest nodes pay. (remember how the choice of k = 10
>makes for a large ratio of maximum V' value to Vi(h) inflation reward)
>
>To reduce amortized proof size one proof can be used for multiple
>payments with Rivest PayWords and similar techniques.
>
>
># PowPay - Off-chain, anonymous, probabalistic payments
>
>By setting the special txout to a scriptPubKey spendable by the
>recipient we can prove to a third party that work was done that with
>probability P(hash,target) could have resulted in a txout spendable by
>them of value V' Thus the expected value of the payment is V = P(h,t)*V'
>The recipient needs to make the proof non-reusable, either by recording
>all proofs submitted, or by requiring a nonce in the scriptPubKey: (*)
>
> <nonce> DROP {additional ops}
>
>*) Note the implications for the IsStandardInput() test.
>
>Because the recipient has no way of knowing how the sender paid to have
>the hashing done on their behalf the source of the funds is unknown to
>them. Additionally the payment can be of any amount less than a full
>block reward, and the time varient between actual payments can be
>reduced to, in theory, as little as the block interval itself with 100%
>miner participation.
>
>
>## Maximum Payment amount
>
>Unlike coinbase txout hashcash the maximum value of a PowPay transaction
>is strictly limited by the inflation reward; the trick of calculating
>actual cost by prior sacrifices doesn't work because no honest sacrifice
>is involved. In any case it is desirable for the mechanism to account
>for a large percentage of total transaction value.
>
>The issue is that should a valid block be found either the miner must
>still have a strong incentive to broadcast that block that can be proven
>to the recipient, or the miner must not be the one who controls that
>decision.
>
>The latter option is possible by inverting the relationship: now the
>recipient constructs the block, and the sender simply arranges for a
>valid PoW to be created - essentially the recipient acts as a mining
>pool with an extremely high minimum work, and the sender provides
>hashing power. With the 1MB blocksize the cost to operate the full
>validating node required is low and attacks on block propagation are
>difficult to successfully pull off.
>
>
>### Supporting PowPay volume in excess of inflation reward + tx fees
>
>To support overall PowPay volumes that are in excess of the inflation
>reward and transaction fees the sender can provide the recipient with
>signed transaction inputs subject to the constraint that only blocks
>with PoW's generated by the sender can be used to spend them. For
>instance a nonce in a well-known place can be provided by the sender and
>included in a modified block header. By modifying the block hashing
>algorithm so that PoW-withholding is not possible - a significantly more
>serious problem in this application - the sender still is forced to send
>all potential solutions to the recipient, including possible winning
>ones. Provided that attacking block propagation is difficult the sender
>can't prevent the reciver from spending their transaction inputs.
>
>
>## Scalability
>
>PowPay can provide much greater scalability than Bitcoin itself, in
>terms of payments per second, however it is still limited in terms of
>actual fund transfers to recipients per second. A naive implementation
>would give a actual transfer every ten minutes maximum, and a highly
>sophisticated solution 7/second. (albeit probably requiring a hardfork
>to solve PoW withholding and/or use of third parties)
>
>At the same time the proofs required become large with an increased
>blocksize, and in the case of the inverted "recipient builds blocks"
>mode the recipients either incur large costs running full nodes, or
>greatly disrupt transaction flow for on-chain users by mining blocks
>with no transactions in them at all. (remember that a recipient who
>trusts someone else to construct the blocks for them is trusting that
>third-party to do so correctly)
>
>The latter is especially problematic because as the blocksize is
>increased a higher percentage of the cost of mining goes to the overhead
>required to run a validating node, rather than hashing, which has the
>perverse effect of decreasing the cost of mining blocks with no
>transactions in them at all. (or transactions that the miner knows have
>not been revealed to other miners)
>
>The analysis of this strange mixed bag of incentives is highly complex.
>
>
># Paying for mining
>
>TxOut HashCash and PayPow both require the sender to somehow get someone
>to mine on their behalf. The exact nature of these relationships will
>vary and are beyond the scope of this paper.
>
>
># Eliminating PoW withholding
>
>While the above examples have used economic incentives possible within
>the existing Bitcoin system a structural incentive is possible as well.
>A nonce N is chosen by the party paying for the PoW, such as a pool or
>PowPay recipient, and H(n) is included in the block header.(*) The PoW
>function is then modified to consider the PoW valid if the sum of the
>expected hashes required to find H(B) and H(B | n) exceeds the current
>difficulty target.
>
>*) Note how the block header can be extended, while remaining fairly compatible
>with existing ASIC mining hardware, by taking advantage of the fact that
>ASIC's use the SHA256 midstate at a starting point for their PoW
>calculations.(3)
>
>
>
>
>1) "Re: [Bitcoin-development] Discovery/addr packets (was: Service bits
>for pruned nodes)" - 2013-06-06 - Peter Todd <pete at petertodd.org> -
>bitcoin-development email list
>
>2) "Purchasing fidelity bonds by provably throwing away bitcoins" -
>https://bitcointalk.org/index.php?topic=134827.0 - Peter Todd
>
>3) "Re: 32 vs 64-bit timestamp fields" - 2013-06-09 - John Dillon
><john.dillon892 at gmail.com> - bitcoin-development email list
>
>--
>'peter'[:-1]@petertodd.org
>0000000000000039e49118426bbe6739360d35116e920d6502dcacd8e51bc74c

>------------------------------------------------------------------------------
>Learn Graph Databases - Download FREE O'Reilly Book
>"Graph Databases" is the definitive new guide to graph databases and
>their applications. This 200-page book is written by three acclaimed
>leaders in the field. The early access version is available now.
>Download your free book today! http://p.sf.net/sfu/neotech_d2d_may

>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2013-05-06 📝 Original message:On ...

2023-06-07T17:01:24+02:00

In reply to nevent1q…xmez
_________________________

📅 Original date posted:2013-05-06
📝 Original message:On Mon, May 06, 2013 at 11:25:50AM -0700, Gregory Maxwell wrote:
>On Mon, May 6, 2013 at 11:04 AM, Adam Back <adam at cypherspace.org> wrote:
>> bitcoins primaryvulnerability IMO (so far) is network attacks to induce
>> network splits, local lower difficulty to a point that a local and
>> artificially isolated area of the network can be fooled into accepting an
>> orphan branch as the one-true block chain,
>
>It currently costs about 2016*25*$120 = six million dollars to
>reduce the difficulty in your isolated fork by a factor of 4.

Well I take your point that you have to produce 2016 blocks, but at a lower
rate. But that doesnt directly translate into my cost, I am thinking pure
network hacking.

Maybe I could hack a pool to co-opt it into my netsplit and do the work for
me, or segment enough of the network to have some miners in it, and they do
the work.

I am just thinking $500k/day worth of relatively perfect crime reward is a
lot of motivation for hacking networks. Many routers home and even carrier
are vulnerable to people armed with cisco source code & 0-days. The
netsplit doesnt have to be geographical, nor even topological, nor even
particularly long-lived.

If you control enough people's network routing at a low enough level, you
dont even have to stop transactions, nor do any mining work, just stop
blocks from the netsplit crossing over, and hold that position for say a day
(if your netsplit has 1/24 of network hash rate in it, so the split gets 6
confirmations to reassure the victims) and let the miners do the work. Do
enough transactions to do a big cash out (spend differently on the two
netsplits). Obviously a big and human inattentive pool, dark-miner etc is
the ideal target to put into the netsplit to increase the power while
controlling less nodes.

Malware could do the same thing for clients, dont forget most are running
windows. Malware could also start a miner if none present.

>> maybe even from node first install time.
>
>Protecting against that— making sure any such attack has to start from
>a high difficulty— is, in my opinion, the biggest continued
>justification for checkpoints.

Do you know if there is any downwards limit on difficulty? I know it takes
going slow for a long and noticeable time, but I am just curious on the
theoretical limit.

>> (btw I notice most of the binaries and tar balls are not signed, nor served
>> from SSL - at least for linux).
>
>They are signed.

I dont see the signatures.

http://bitcoin.org/en/download

I see no signatures for linux and none in the tarball. There are some
public keys inside the tarball, thats it. Also no SSL. sourceforge support
SSL so you can download that. But bitcoin.org doesnt even answer 443, and
the source forge link is HTTP. But even if the sourceforge link was SSL one
should not serve an SSL download link from an HTTP page, any more than type
a password into an HTTPS form action on an HTTP page. The attacker can just
redirect and the user doesnt know what is legitimate.

Consequently even if there is code signing on the windows exe, the user
doesnt know that, nor who they should be signed by, and as they are served
via HTTP, its bypassable.

I guess by far the easiest way to attack right now (at least linux users) is
just to change the binaries to create a user operated netsplit, or just have
all their wallets empty to you via a mix once the amount gets interesting.

(All attacks hypothetical of course - I'm actually a white-hat type of
person).

Adam

📅 Original date posted:2013-05-06 📝 Original message:On ...

2023-06-07T17:01:20+02:00

In reply to nevent1q…8ljk
_________________________

📅 Original date posted:2013-05-06
📝 Original message:On Mon, May 06, 2013 at 03:08:57PM -0400, Peter Todd wrote:
>> Hmm: maybe one could use a Brands private credential with offline double
>> spend detection, with the reputation but not coin address of the node
>> disclosed, and the nodes coin address embedded in the proof. Each node
>> could be is own CA, providing a ZKP. If the node ever double spends a coin,
>> it loses its reputation as the coin address is revealed.
>
>Be careful not to mix up the concept of a relay node with someone
>posessing Bitcoins. Node's don't spend coins, people/wallets do.

My comment was to say that a good behaviour bond for a relay node could be
put on an address that is defined as unspendable until such time as an
auditor can prove the node engaged in the undesired behaviour, at which
point the audit receives the payment as part of his proof. Or until the
node ceases to operate. Its a smart contract.

However I added to that, that it is still possible to do that while
preseving privacy, to point out that it is technically possible, for people
to be aware of in their mental toolbox, if it helps solve an otherwise
tricky problem.

So that would be a privacy preserving smart contract, the parties are
unknown, and unknowable (with unconditional security even), but still the
smart contract executes. In some sense a privacy preserving smart-contract
is closer to the real point of Szabo's smart-contract idea because you cant
try to renege on the contract in a conventional court - because you cant
identify your counter-party. Bitcoins privacy feature is fairly weak so
that is probably often not true.

Of course you'd probably need zerocoin to stand much chance of proving an
address private key of an unlinked coin was in the double-spend disclosed
attribute in the first place, and as we know zerocoin is not that efficient.

> Make the node identity expensive to obtain. For instance, construct PoW's
> including the node pubkey somehow,

that could be easily done with the work of creating a vanity address. eg
address containing many leading 0s.

Adam

📅 Original date posted:2013-05-06 📝 Original message:btw ...

2023-06-07T17:01:19+02:00

In reply to nevent1q…rcpv
_________________________

📅 Original date posted:2013-05-06
📝 Original message:btw with nodes for transport security you might use self-certifying keys.
Referring to Zooko's triangle, then the key is the node identity. Similar
to a bitcion address. So then just another ECDSA key and use emphemeral
ECDH for transport authenticated with the nodes key.

Maybe there can be some value to reputation to a node - eg it can charge a
higher micropayment for its p2p network services, a node with a good
reptuation could charge a higher micropayment for relaying (though bitcoin
itself probably doesnt like micropayments as bloating the transaction log).

Another ZKS era idea I had was to have a gossip protocol for users to find
out what other people think about the trustworthiness and reliability of
nodes. If that info is distributed via gossip over multiple channels and
network connections over time, and kept in something like a gnutella host
cache (just a cache of random info with some eg random replacement policy)
it becomes very hard for a dishonest node to censor evidence of its low
reputation.

It is best as Gregory said to be able to directly prove, and punish by
block-chain validation, because that is more smart-contract like. Bisbehave
and nodes wont connect to you or lose somehow.

But what exactly could you prove about a node? You dont really know if a
node is an originator for a double spend, it could be relay. And for
privacy and security you cant expect the node to use its coin address
private key.

Hmm: maybe one could use a Brands private credential with offline double
spend detection, with the reputation but not coin address of the node
disclosed, and the nodes coin address embedded in the proof. Each node
could be is own CA, providing a ZKP. If the node ever double spends a coin,
it loses its reputation as the coin address is revealed.

btw another old idea was to require proof of the existance of the private
key of a high value coin in the double-spend revealed information. Then
basically to get a higher good-behaviour bond, the node ties up more coins,
and if a node cheats, the first person to discover this collects the
forfeited good behaviour bond.

Adam

ps I have an opensource openSSL based Brands (& Chaum) credential library at
http://www.cypherspace.org/credlb/ I didnt actually implement the ECDL
version, just the DL version, but that is not so hard, and its on my todo
list. (There is also a strong RSA assumption version, also not
implemented).

On Mon, May 06, 2013 at 11:01:22AM -0700, Gregory Maxwell wrote:
>> 1) Non-repudiation is only useful with fraud proofs, and they will have
>> to be thought out for everything the node might claim.
>
>That isn't so. If a node is reliably rogue I can go manually gather
>evidence and people can manually take action against it. Consider the
>DNSseeds, right now fraud proofs really wouldn't matter— the limited
>amount of trust put in those things is based not on "oh no, nodes will
>ignore you in the future if you're bad", it's based on the ability of
>misconduct to sully the operator's reputation.
>
>But without non-repudiation the ability to tie reputation to good
>behavior is fairly limited especially if they perform targeted
>attacks. "Wasn't me"
>
>Instead— I'd argue that non-repudiation is always useful when there is
>trust. It's things like fidelity bonds— a trust generator that depend
>on automatic enforcement— that are only useful with fraud proofs.
>
>> Anyway, the concept of a per-node identity keypair is the first step
>> towards non-repudiation, and implementing SSL transport.
>
>Yea, indeed, per-node keys are useful for a bunch of things. Care is
>needed to avoid problems like deanonymizing use over tor with them.
>
>------------------------------------------------------------------------------
>Learn Graph Databases - Download FREE O'Reilly Book
>"Graph Databases" is the definitive new guide to graph databases and
>their applications. This 200-page book is written by three acclaimed
>leaders in the field. The early access version is available now.
>Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development

📅 Original date posted:2013-05-06 📝 Original message:On ...

2023-06-07T16:56:35+02:00

In reply to nevent1q…cnlc
_________________________

📅 Original date posted:2013-05-06
📝 Original message:On Mon, May 06, 2013 at 11:25:50AM -0700, Gregory Maxwell wrote:
>On Mon, May 6, 2013 at 11:04 AM, Adam Back <adam at cypherspace.org> wrote:
>> bitcoins primaryvulnerability IMO (so far) is network attacks to induce
>> network splits, local lower difficulty to a point that a local and
>> artificially isolated area of the network can be fooled into accepting an
>> orphan branch as the one-true block chain,
>
>It currently costs about 2016*25*$120 = six million dollars to
>reduce the difficulty in your isolated fork by a factor of 4.

Well I take your point that you have to produce 2016 blocks, but at a lower
rate. But that doesnt directly translate into my cost, I am thinking pure
network hacking.

Maybe I could hack a pool to co-opt it into my netsplit and do the work for
me, or segment enough of the network to have some miners in it, and they do
the work.

I am just thinking $500k/day worth of relatively perfect crime reward is a
lot of motivation for hacking networks. Many routers home and even carrier
are vulnerable to people armed with cisco source code & 0-days. The
netsplit doesnt have to be geographical, nor even topological, nor even
particularly long-lived.

If you control enough people's network routing at a low enough level, you
dont even have to stop transactions, nor do any mining work, just stop
blocks from the netsplit crossing over, and hold that position for say a day
(if your netsplit has 1/24 of network hash rate in it, so the split gets 6
confirmations to reassure the victims) and let the miners do the work. Do
enough transactions to do a big cash out (spend differently on the two
netsplits). Obviously a big and human inattentive pool, dark-miner etc is
the ideal target to put into the netsplit to increase the power while
controlling less nodes.

Malware could do the same thing for clients, dont forget most are running
windows. Malware could also start a miner if none present.

>> maybe even from node first install time.
>
>Protecting against that— making sure any such attack has to start from
>a high difficulty— is, in my opinion, the biggest continued
>justification for checkpoints.

Do you know if there is any downwards limit on difficulty? I know it takes
going slow for a long and noticeable time, but I am just curious on the
theoretical limit.

>> (btw I notice most of the binaries and tar balls are not signed, nor served
>> from SSL - at least for linux).
>
>They are signed.

I dont see the signatures.

http://bitcoin.org/en/download

I see no signatures for linux and none in the tarball. There are some
public keys inside the tarball, thats it. Also no SSL. sourceforge support
SSL so you can download that. But bitcoin.org doesnt even answer 443, and
the source forge link is HTTP. But even if the sourceforge link was SSL one
should not serve an SSL download link from an HTTP page, any more than type
a password into an HTTPS form action on an HTTP page. The attacker can just
redirect and the user doesnt know what is legitimate.

Consequently even if there is code signing on the windows exe, the user
doesnt know that, nor who they should be signed by, and as they are served
via HTTP, its bypassable.

I guess by far the easiest way to attack right now (at least linux users) is
just to change the binaries to create a user operated netsplit, or just have
all their wallets empty to you via a mix once the amount gets interesting.

(All attacks hypothetical of course - I'm actually a white-hat type of
person).

Adam

📅 Original date posted:2013-05-06 📝 Original message:btw ...

2023-06-07T16:56:30+02:00

In reply to nevent1q…pcma
_________________________

📅 Original date posted:2013-05-06
📝 Original message:btw with nodes for transport security you might use self-certifying keys.
Referring to Zooko's triangle, then the key is the node identity. Similar
to a bitcion address. So then just another ECDSA key and use emphemeral
ECDH for transport authenticated with the nodes key.

Maybe there can be some value to reputation to a node - eg it can charge a
higher micropayment for its p2p network services, a node with a good
reptuation could charge a higher micropayment for relaying (though bitcoin
itself probably doesnt like micropayments as bloating the transaction log).

Another ZKS era idea I had was to have a gossip protocol for users to find
out what other people think about the trustworthiness and reliability of
nodes. If that info is distributed via gossip over multiple channels and
network connections over time, and kept in something like a gnutella host
cache (just a cache of random info with some eg random replacement policy)
it becomes very hard for a dishonest node to censor evidence of its low
reputation.

It is best as Gregory said to be able to directly prove, and punish by
block-chain validation, because that is more smart-contract like. Bisbehave
and nodes wont connect to you or lose somehow.

But what exactly could you prove about a node? You dont really know if a
node is an originator for a double spend, it could be relay. And for
privacy and security you cant expect the node to use its coin address
private key.

Hmm: maybe one could use a Brands private credential with offline double
spend detection, with the reputation but not coin address of the node
disclosed, and the nodes coin address embedded in the proof. Each node
could be is own CA, providing a ZKP. If the node ever double spends a coin,
it loses its reputation as the coin address is revealed.

btw another old idea was to require proof of the existance of the private
key of a high value coin in the double-spend revealed information. Then
basically to get a higher good-behaviour bond, the node ties up more coins,
and if a node cheats, the first person to discover this collects the
forfeited good behaviour bond.

Adam

ps I have an opensource openSSL based Brands (& Chaum) credential library at
http://www.cypherspace.org/credlb/ I didnt actually implement the ECDL
version, just the DL version, but that is not so hard, and its on my todo
list. (There is also a strong RSA assumption version, also not
implemented).

On Mon, May 06, 2013 at 11:01:22AM -0700, Gregory Maxwell wrote:
>> 1) Non-repudiation is only useful with fraud proofs, and they will have
>> to be thought out for everything the node might claim.
>
>That isn't so. If a node is reliably rogue I can go manually gather
>evidence and people can manually take action against it. Consider the
>DNSseeds, right now fraud proofs really wouldn't matter— the limited
>amount of trust put in those things is based not on "oh no, nodes will
>ignore you in the future if you're bad", it's based on the ability of
>misconduct to sully the operator's reputation.
>
>But without non-repudiation the ability to tie reputation to good
>behavior is fairly limited especially if they perform targeted
>attacks. "Wasn't me"
>
>Instead— I'd argue that non-repudiation is always useful when there is
>trust. It's things like fidelity bonds— a trust generator that depend
>on automatic enforcement— that are only useful with fraud proofs.
>
>> Anyway, the concept of a per-node identity keypair is the first step
>> towards non-repudiation, and implementing SSL transport.
>
>Yea, indeed, per-node keys are useful for a bunch of things. Care is
>needed to avoid problems like deanonymizing use over tor with them.
>
>------------------------------------------------------------------------------
>Learn Graph Databases - Download FREE O'Reilly Book
>"Graph Databases" is the definitive new guide to graph databases and
>their applications. This 200-page book is written by three acclaimed
>leaders in the field. The early access version is available now.
>Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>_______________________________________________
>Bitcoin-development mailing list
>Bitcoin-development at lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/bitcoin-development