<unnamed>

Public Key

npub1lhe3qfx2q5m7mq5d39waepf9lzhsy0cdey66svn63fyk6rt6n7ps7zg7ed

Profile Code

nprofile1qqs0mucsyn9q2dlds2xcjhwus5jl3tcz8uxujddgxfag5jtdp4aflqcpz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds5uuez8

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-06-07 20:04:04 CEST

- reply

📅 Original date posted:2017-07-08
📝 Original message:I am utterly appalled by this proposal both technically, ethically, and by
the process which it has adopted. Hard forks require consensus from the
entire ecosystem in order to prevent a fork, funds loss, confusion and harm
to the robust guarantees of the Bitcoin system has thus far displayed.
I know this is a draft, but you are seeking reviews of a proposal that has
just a few weeks remaining before deployment (where "technical review" is
pointless because the is not actually open
<https://pastebin.com/kktB1kaw> unless
you are an approved member
<https://github.com/btc1/bitcoin/commit/1719c872b6624c37b0f2d94e7a4a2656fac4804a#diff-6a3371457528722a734f3c51d9238c13>),
making it totally unworkable and irresponsible. For example, exactly how
are other implementations supposed to adopt the BIP in such a short
timeframe? For all the talk of how important "alternative implementations"
are, how does this rash and rushed action promote an ecosystem of multiple
implementors? By encouraging fast upgrades, you are actually centralizing
the ecosystem even further.
The linked coded doesn't uniquely identify itself on the network by
user-agent, something all distinct implementations have done to date.
The draft BIP text looks like an afterthought and doesn't actually specify
the proposal in enough detail to implement from the text. By contrast for
example, BIP141 has a level of detail which allowed others to implement
segwit without looking at any reference code (which consequently results to
more confidence and testing of the specification all round). The Bitcoin
system has a market cap of over $40bn supported by a robust and reliable
network and your proposal is an offence to all Bitcoin has achieved because
due to it's the strong foundations.
I cannot not support this proposal in the current form and timeline, nor do
I support the coercion that has been used behind closed doors to try and
gain more support (not limited to, but including approaching company
investors to twist arms and veiled threats of blacklisting companies from
further funding/collaboration).
I think the best you can hope for this hard fork proposal is for it to be
quietly ignored.
On Fri, Jul 7, 2017 at 10:25 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello,
>
> Here is a BIP that matches the reference code that the Segwit2x group has
> built and published a week ago.
>
> This BIP and code satisfies the requests of a large part of the Bitcoin
> community for a moderate increase in the Bitcoin non-witness block space
> coupled with the activation of Segwit.
>
> You can find the BIP draft in the following link:
>
> https://github.com/SergioDemianLerner/BIPs/blob/
> master/BIP-draft-sergiolerner-segwit2x.mediawiki
>
> Reference source was kindly provided by the Segwit2x group.
>
> Best regards,
> Sergio.
>
> _______________________________________________
> 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/20170708/b3a2925a/attachment.html>

2023-06-07 19:54:17 CEST

- reply

📅 Original date posted:2016-11-15
📝 Original message:I think this is already covered in the BIP text:-
"As of November 2016, the most recent of these changes (BIP 65,
enforced since December 2015) has nearly 50,000 blocks built on top of
it. The occurrence of such a reorg that would cause the activating
block to be disconnected would raise fundamental concerns about the
security assumptions of Bitcoin, a far bigger issue than any
non-backwards compatible change.
So while this proposal could theoretically result in a consensus
split, it is extremely unlikely, and in particular any such
circumstances would be sufficiently damaging to the Bitcoin network to
dwarf any concerns about the effects of this proposed change."
On Mon, Nov 14, 2016 at 6:47 PM, Eric Voskuil via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> NACK
>
> Horrible precedent (hardcoding rule changes based on the assumption that
> large forks indicate a catastrophic failure), extremely poor process
> (already shipped, now the discussion), and not even a material performance
> optimization (the checks are avoidable once activated until a sufficiently
> deep reorg deactivates them).
>
> e
>
> On Nov 14, 2016, at 10:17 AM, Suhas Daftuar via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Hi,
>
> Recently Bitcoin Core merged a simplification to the consensus rules
> surrounding deployment of BIPs 34, 66, and 65
> (https://github.com/bitcoin/bitcoin/pull/8391), and though the change is a
> minor one, I thought it was worth documenting the rationale in a BIP for
> posterity.
>
> Here's the abstract:
>
> Prior soft forks (BIP 34, BIP 65, and BIP 66) were activated via miner
> signaling in block version numbers. Now that the chain has long since passed
> the blocks at which those consensus rules have triggered, we can (as a
> simplification and optimization) replace the trigger mechanism by caching
> the block heights at which those consensus rules became enforced.
>
> The full draft can be found here:
>
> https://github.com/sdaftuar/bips/blob/buried-deployments/bip-buried-deployments.mediawiki
>
> _______________________________________________
> 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
>

2023-06-07 19:48:36 CEST

- reply

📅 Original date posted:2016-02-05
📝 Original message:On Fri, Feb 5, 2016 at 8:51 PM, Gavin Andresen via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> This has been reviewed by merchants, miners and exchanges for a couple of
> weeks, and has been implemented and tested as part of the Bitcoin Classic
> and Bitcoin XT implementations.
>
> Constructive feedback welcome; argument about whether or not it is a good
> idea to roll out a hard fork now will be unproductive, so I vote we don't
> go there.
>
> Draft BIP:
> https://github.com/gavinandresen/bips/blob/bump2mb/bip-bump2mb.mediawiki
>
> Summary:
> Increase block size limit to 2,000,000 bytes.
> After 75% hashpower support then 28-day grace period.
> With accurate sigop counting, but existing sigop limit (20,000)
> And a new, high limit on signature hashing
>
> Blog post walking through the code:
> http://gavinandresen.ninja/a-guided-tour-of-the-2mb-fork
>
> Blog post on a couple of the constants chosen:
> http://gavinandresen.ninja/seventyfive-twentyeight
>
It's great to finally see a BIP, although seems strange to ask for feedback
after releasing binaries.
In any case, the issue isn't about "whether or not it is a good idea to
roll out a hard fork", the question has always been about how to do safe
hard fork deployment and what the technological requirements are for doing
so. Your BIP/blogs do not actually address any of this. 75% miner
signalling with a 28 day flag day thereafter gives virtually no time for
the entire ecosystem to migrate and is widely considered unsafe. It's
plainly obvious that an entire ecosystem of 5000 full nodes cannot be
prepared in a month.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160205/0c3d2ed8/attachment-0001.html>

2023-06-07 19:44:35 CEST

- reply

📅 Original date posted:2015-11-13
📝 Original message:> * 2 MB, height 210,000 < 420,000; (when 75% of last 1,000 blocks signal
support)
This doesnt give anyone a chance to upgrade and would cause a hard fork the
moment a miner created a >1MB block. Flag day (hard fork) upgrades must
start the change at a sufficient time in the future (greater than the
current block height) to give all nodes the chance to upgrade.
On Fri, Nov 13, 2015 at 3:37 AM, John Sacco via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I like your suggestion for the continuity and it gets us up to 2 MB in the
> shorter term. Also I just noticed the math error.
>
> Here is a revised spec (incorporating suggestions from Chun Wang):
>
> Specification
>
> * 1 MB, height < 210,000;
> * 2 MB, height 210,000 < 420,000; (when 75% of last 1,000 blocks signal
> support)
> * 4 MB, height 420,000 < 630,000; (year 2016)
> * 8 MB, height 630,000 < 840,000; (year ~2020)
> * 16 MB, height 840,000 < 1,050,000; (year ~2024)
> * 32 MB, height >= 1,050,000. (year ~2028)
>
>
> On Thu, Nov 12, 2015 at 9:56 PM, Chun Wang <1240902 at gmail.com> wrote:
>
>> How about these specs:
>> * 1 MB, height < 210000;
>> * 2 MB, 210000 <= height < 420000;
>> * 4 MB, 420000 <= height < 630000;
>> * 8 MB, 630000 <= height < 840000;
>> * 16 MB, 840000 <= height < 1050000;
>> * 32 MB, height >= 1050000.
>>
>>
>> On Fri, Nov 13, 2015 at 7:47 AM, John Sacco via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Hi Devs,
>> >
>> >
>> > Please consider the draft proposal below for peer review.
>> >
>> >
>> > Thanks,
>> >
>> >
>> > John
>> >
>> >
>> > BIP
>> >
>> > BIP: ?
>> >
>> > Title: Block size doubles at each reward halving with max block size
>> of
>> > 32M
>> >
>> > Author: John Sacco <johnsock at gmail.com>
>> >
>> > Status: Draft
>> >
>> > Type: Standards Track
>> >
>> > Created: 2015-11-11
>> >
>> > Abstract
>> >
>> > Change max block size to 2MB at next block subsidy halving, and double
>> the
>> > block size at each subsidy halving until reaching 32MB.
>> >
>> > Copyright
>> >
>> > This proposal belongs in the public domain. Anyone can use this text
>> for any
>> > purpose with proper attribution to the author.
>> >
>> > Motivation
>> >
>> > 1. Gradually restores block size to the default 32 MB setting
>> originally
>> > implemented by Satoshi.
>> >
>> > 2. Initial increase to 2MB at block halving in July 2016 would have
>> > minimal impact to existing nodes running on most hardware and networks.
>> >
>> > 3. Long term solution that does not make enthusiastic assumptions
>> > regarding future bandwidth and storage availability estimates.
>> >
>> > 4. Maximum block size of 32MB allows peak usage of ~100 tx/sec by
>> year
>> > 2031.
>> >
>> > 5. Exercise network upgrade procedure during subsidy reward halving,
>> a
>> > milestone event with the goal of increasing awareness among miners and
>> node
>> > operators.
>> >
>> > Specification
>> >
>> > 1. Increase the maximum block size to 2MB when block 630,000 is
>> reached
>> > and 75% of the last 1,000 blocks have signaled support.
>> >
>> > 2. Increase maximum block size to 4MB at block 840,000.
>> >
>> > 3. Increase maximum block size to 8MB at block 1,050,000.
>> >
>> > 4. Increase maximum block size to 16MB at block 1,260,000.
>> >
>> > 5. Increase maximum block size to 32MB at block 1,470,000.
>> >
>> > Backward compatibility
>> >
>> > All older clients are not compatible with this change. The first block
>> > larger than 1M will create a network partition excluding not-upgraded
>> > network nodes and miners.
>> >
>> > Rationale
>> >
>> > While more comprehensive solutions are developed, an increase to the
>> block
>> > size is needed to continue network growth. A longer term solution is
>> needed
>> > to prevent complications associated with additional hard forks. It
>> should
>> > also increase at a gradual rate that retains and allows a large
>> distribution
>> > of full nodes. Scheduling this hard fork to occur no earlier than the
>> > subsidy halving in 2016 has the goal of simplifying the communication
>> > outreach needed to achieve consensus, while also providing a buffer of
>> time
>> > to make necessary preparations.
>> >
>> >
>> > _______________________________________________
>> > 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/20151113/f716f43a/attachment.html>

2023-06-07 19:42:41 CEST

- reply

📅 Original date posted:2015-10-05
📝 Original message:You are absolutely right and this is something I have often unsuccessfully
tried to explain as "disruption strategies". The problem is that most
people in the technical community assume good faith at all times, which
plays right into the frame required for disruption.
However, I would like to challenge your assumption of point 1 that that by
Mike making a rabble, it somehow makes CLTV deployment controversial. His
arguments have been refuted.
Mike has not presented anything convincing and history actually shows that
ISM works, and we have learned how to make it even more streamlined. We
know ISM has consensus because miners have accepted ISM for past softfork
rollouts.
Simply making a noise does not make something controversial. When it is
controversial, it is obvious and plain to see.
On Mon, Oct 5, 2015 at 4:56 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Some of the people on this mailing list are blindly discussing the
> technicalities of a soft/hard fork without realizing that is not Mike's
> main intention. At least I perceive (and maybe others too) something else
> is happening.
>
> Let me try to clarify: the discussion has nothing to do with technical
> arguments. I generally like more hard forks than soft forks (but I won't
> explain why because this is not a technical thread), but for CLTV this is
> quite irrelevant (but I won't explain why..), and I want CLTV to be
> deployed asap.
>
> Mike's intention is to criticize the informal governance model of Bitcoin
> Core development and he has strategically pushed the discussion to a
> dead-end where the group either:
>
> 1) ignores him, which is against the established criteria that all
> technical objections coming from anyone must be addressed until that person
> agrees, so that a change can be uncontroversial. If the group moves forward
> with the change, then the "uncontroversial" criteria is violated and then
> credibility is lost. So a new governance model would be required for which
> the change is within the established rules.
>
> 2) respond to his technical objections one after the other, on never
> ending threads, bringing the project to a standstill.
>
> As I don't want 2) to happen, then 1) must happen, which is what Mike
> wants. I have nothing for or against Mike personally. I just think Mike
> Hearn has won this battle. But having a more formal decision making process
> may not be too bad for Bitcoin, maybe it can actually be good.
>
> Best regards
> from a non-developer to my dearest developer friends,
> Sergio.
>
>
> _______________________________________________
> 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/20151005/a541ef59/attachment.html>

2023-06-07 19:42:41 CEST

- reply

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 6:26 PM, Tom Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> History has shown that for many decision making processes this doesn't
> work,
> and this argument has been made to Core.
> Until today this was essentially a rule that hurt the things that Mike was
> really passionate about.
> Today this hurts the things that some other devs are passionate about.
>
If you are referring to some of Mike's PRs that were either refused or
reverted, it was because they where substantial technical objections to
them. This isn't even in the same ballpark.
Surely you see the absurdity of arguing against soft forks after we
successfully used them already for BIP34 and BIP66?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/bc7c4a65/attachment.html>

2023-06-07 19:42:39 CEST

- reply

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 5:56 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> CLTV deployment is clearly controversial. Many developers other than me
> have noted that hard forks are cleaner, and have other desirable
> properties. I'm not the only one who sees a big question mark over soft
> forks.
>
No, that is not correct and you are distorting facts to fit your argument.
We have discussed the tradeoffs of each method in general, but that does
not make hard forks or soft forks controversial in an of itself.
There is technical consensus to roll out CLTV by ISM, and if somehow you
are right, it will come out during deployment in much the same way as your
recent attempt at rolling out a controversial hardfork.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/45f8c2cb/attachment.html>

2023-06-07 19:42:39 CEST

- reply

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 6:33 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I also agree with Mike that Core's requirement for unanimous consensus
> results in development grid lock and should be revisited.
>
There is no development gridlock. Look at the IRC logs for core-dev; look
at the pull requests; look a the merge history: Development is vibrant.
Developers are very active. You are manufacturing a crisis convenient to
your narrative, but it is far from the actual reality on the ground.
Please desist from this intellectual dishonesty and toxicity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20151005/4d591b1b/attachment.html>

2023-06-07 19:41:30 CEST

- reply

📅 Original date posted:2015-09-28
📝 Original message:On Mon, Sep 28, 2015 at 12:40 PM, Mike Hearn via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> There is no consensus. Now pick. Lose the requirement that everyone agree
> for consensus changes, and tell people you've done it. Change the spec. Or
> do nothing.
>
Of course there is good technical consensus for CLTV by IsSuperMajority()
in the same way as BIP66 was rolled out. I believe the only open question
is whether we have to account for XT's use of versionbits (because the
standard has not been finalised). One can take the view that it is a non
issue given the almost negligible number of BIP101 blocks, but it certainly
goes away if XT also merges BIP65/CLTV.
As for risks, I think we learned a lot from BIP66:
1. miners are now aware of the risks of SPV mining near activation and are
financially incentivised not to during that period.
2. As for SPV wallets need to handle awareness of the new blocks. BitcoinJ
can play a pivotal role: as far as I am aware if we'd thought about adding
handling to BitcoinJ before activation rather than after activation[1][2],
the SPV issues would have been mitigated for the vast majority who rely on
the library. To me, this particular issue highlights our collective failure
to communicate the necessity for additional SPV handling requirements and
other preparation the ecosystem should engage in during a soft fork. This
is something we should definitely add to the release notes for the next
soft fork and advertise widely. Certainly it MUST be well documented in the
BIP65 deployment section, which it is currently not.
Lastly your objections came across very strongly (at least to my
understanding) so I am curious: Peter stated Gavin is OK with adding CLTV
support to XT, and assuming that is the case, will you object to merging it
or similarly object to adding the necessary block handling to BitcoinJ?
[1]
https://github.com/bitcoinj/bitcoinj/commit/6f03669fbd6c368961a25dfd772751d1ca2a1b5b
[2]
https://github.com/bitcoinj/bitcoinj/commit/d3d11df6d71ff11cef2dc0caa8263daa641fe118
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150928/2d9c5e1d/attachment.html>

2023-06-07 19:41:26 CEST

- reply

📅 Original date posted:2015-09-27
📝 Original message:On Sun, Sep 27, 2015 at 7:50 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> 10) Waiting for nVersion bits and CHECKSEQUENCEVERIFY will significantly
> delay deployment of CLTV
>
> It's been proposed multiple times that we wait until we can do a single
> soft-fork with CSV using the nVersion bits mechanism.
>
> nVersion bits doesn't even have an implementation yet, nor has solid
> consensus been reached on the exact semantics of how nVersion bits
> should work.
Small correction, the suggestion is to aim to roll out CLTV+CSV together by
0.12 release, using IsSuperMajority() (or versionbits if it is ready by
then). If CSV is not ready by then, we'd just roll out CLTV.
However, the CSV related pull requests are ready for final review and if
that can happen soon I don't see why we wouldn't roll CLTV+CSV out together
before 0.12. A considerable amount of time, discussion and iterations have
occurred for the related PRs and I believe they are at the point of
consensus modulo final review before merging.
References:
Mempool-only sequence number constraint verification
https://github.com/bitcoin/bitcoin/pull/6312
Mempool-only CHECKSEQUENCEVERIFY
https://github.com/bitcoin/bitcoin/pull/6564
Mempool-only Median time-past as endpoint for lock-time calculations
https://github.com/bitcoin/bitcoin/pull/6566
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150927/81513026/attachment.html>

2023-06-07 19:40:52 CEST

- reply

📅 Original date posted:2015-09-18
📝 Original message:Urgh... Can we hardfork time? It's clearly in need of an upgrade...
On Fri, Sep 18, 2015 at 9:31 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Fri, Sep 18, 2015 at 8:27 PM, Matt Corallo via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Google Calendar is localized, but has an option to change the timezone
> > of an event, it just doesnt have UTC in its options. So, yes, we should
> > use something that observes DST in roughly the same way as everyone else
> > - CEST/PDT/EST/etc.
>
> uh. There is fairly little global consistency in DST usage. Lots of
> places do dst on different dates.
>
> So if it's in some DST timezone it's likely to move twice each change
> for some subset of the people who do it.
>
> E.g. europe and US end DST one week apart.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150918/09bbdbe3/attachment.html>

2023-06-07 19:40:51 CEST

- reply

📅 Original date posted:2015-09-18
📝 Original message:Google calendar is localised, so it doesn't matter. The problem with
quoting UTC anyway it the meeting times are going to change for those that
observe DST. It would be much better to quote an actual timezone of an
actual area so it will remain constant, like 1700 CEST, or 0900AM PDT for
example. Otherwise when the clocks change, what was a convenient meeting
time will become inconvenient for some.
On Fri, Sep 18, 2015 at 9:14 PM, Matt Corallo via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Generally in favor, but for practical purposes can we select a timezone
> that is available in Google Calendar? It appears it does not directly
> support UTC...
>
> On 09/18/15 01:07, Wladimir J. van der Laan via bitcoin-dev wrote:
> > Hello,
> >
> > At Monday's code sprint we had a good idea to schedule a regular
> developer meeting in #bitcoin-dev.
> >
> > Attendance is of course voluntary, but it may be good to have a time
> that many people are expected to be present and current issues can be
> discussed.
> >
> > Any preference for days/times?
> >
> > What about e.g. every week 15:00-16:00 UTC on Thursday?
> >
> > Wladimir
> > _______________________________________________
> > 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/20150918/c4455a41/attachment.html>

2023-06-07 19:40:18 CEST

- reply

📅 Original date posted:2015-09-15
📝 Original message:On Tue, Sep 15, 2015 at 4:26 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> The problem comes with the impact of an unfocused stream of refactors to
> key code.
>
> For example, there is much less long term developer impact if refactoring
> were _accelerated_, scheduled to be performed in a one-week sprint. There
> is a lot of breakage, yes, but after that week the average level of
> downstream patch breakage is significantly lower. A "rip the band-aid off
> quickly rather than slowly" approach.
>
My sentiments exactly...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150915/578098d2/attachment.html>

2023-06-07 19:40:15 CEST

- reply

📅 Original date posted:2015-09-15
📝 Original message:I also share a lot of Jeff's concerns about refactoring and have voiced
them several times on IRC and in private to Jorge, Wladamir and Greg. I
meant to do a write up but never got around to it. Jeff has quite
eloquently stated the various problems. I would like to share my thoughts
on the matter because we really do need to come up with a plan on how this
issue is dealt with.
Obviously, Bitcoin Core is quite tightly coupled at the moment and
definitely needs extensive modularisation. Such work will inevitably
require lots of bulk code moves and then finer refactoring. However, it
requires proper planning because there are lots of effects and consequences
for other people contributing to Core and also downstream projects relying
on Core:
1. Refactoring often causes other pull requests to diverge and require
rebasing. Continual refactoring can put PRs in "rebase hell" and puts a big
stress on contributors (many of whom are part time).
2. Version to version, Bitcoin Core changes significantly in structure. 0.9
to 0.10 is unrecognisable. 0.10 to 0.11 is even more so. This makes makes
it hard to follow release to release and the net result is less people
upgrade (especially think of miners trying to keep their patch sets working
while trying not to disrupt or risk their mining operations).
3. Continual refactoring increases risk: we're human, and mistakes will
slip through peer review. This is especially concerning with consensus
critical code and this makes it difficult to merge such refactoring often,
which of course exacerbates the problem.
The net negative consequence is it is harder to contribute to Core, harder
for the Core maintainers to merge and harder for downstream/dependent
projects/implementations to keep up.
Suggested Way Forward
---------------------------------
With the understanding that refactored code by definition must not change
behaviour. There are three major kinds of refactoring:
1. code moves (e.g. separating concerns into different files);
2. code style;
3. structural optimisation and consolidation (reducing LOC, separating
concerns, encapsulation etc).
Code moves(1) and CS(2) are easy to peer review and merge quickly. The
third kind(3) requires deeper analysis to ensure that while the code
changed, the behaviour (including any bugs) did not.
We must resist all temptation to fix bugs or tack on minor fixes and tweaks
during refactoring: pull requests should only be refactoring only, with no
net change to behaviour. Keeping discipline makes it much easier to verify
and peer review and this faster to merge.
With respect to Code moves and CS, I believe we should have a "refactoring
fortnight" where we so the bulk of code move-only refactoring plus CS where
necessary. This is by fat the most disruptive kind of change because it
widely affects other PRs mergeability. We should aim to get most of this
done in one go, so that it's not happening in dribs and drabs over months
and many releases. Once done, it gives everyone a good idea to the overall
new structure and where one can expect to find things in the future. The
idea here is to help orientation and not have to continuously hunt for
where things have moved to.
To be clear, I am strongly suggesting code move-only refactoring PRs not be
mixed with anything else. Same for CS changes. This makes the PRs extremely
easy to vet and thus quick to merge.
Towards this end, maybe there should be an IRC meeting to agree the initial
moves, then someone who has the stomach for it can get on and do it -
during that time, we do not merge anything else. We need to bite the bullet
and break the back out of code moves.
With regards to CS, I think we do need to get CS right, because a continual
dribble of CS changes also makes diffs between releases less easy to
follow. Much of CS checking can be automated by the continuous integration
so authors can get it right easily. It can be just like a Travis check.
With respect to the 3rd kind of refactoring, we need to set some standards
and goals and aim for some kind of consistency. Refactoring needs to fulfil
certain goals and criterion otherwise contributors will always find a
reason to fiddle over and over forever. Obvious targets here can be things
like proper encapsulation and separation of concerns.
Overall, refactoring should be merged quickly, but only on a schedule so it
doesn't cause major disruption to others.
Obviously the third kind of refactoring more complex and time consuming and
will need to occur over time, but it should happen in defined steps. As
Jeff said, one week a month, or maybe one month a release. In any case,
refactoring changes should be quickly accepted or rejected by the project
maintainer and not left hanging.
Finally, refactoring should *always* be uncontroversial because essentially
functionality is not changing. If functionality changes (e.g. you try to
sneak in a big fix or feature tweak "because it's small") the PR should be
rejected outright. Additionally, if we break down refactoring into the
three kinds stated above, peer review will be much more straightforward.
On Tue, Sep 15, 2015 at 5:10 AM, Jeff Garzik via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> [collating a private mail and a github issue comment, moving it to a
> better forum]
>
> On libconsensus
> ---------------
> In general there exists the reasonable goal to move consensus state
> and code to a specific, separate lib.
>
> To someone not closely reviewing the seemingly endless stream of
> libconsensus refactoring PRs, the 10,000 foot view is that there is a
> rather random stream of refactors that proceed in fits and starts
> without apparent plan or end other than a one sentence "isolate
> consensus state and code" summary.
>
> I am hoping that
> * There is some plan
> * We will not see a five year stream of random consensus code movement
> patches causing lots of downstream developer headaches.
>
> I read every code change in every pull request that comes into
> github/bitcoin/bitcoin with three exceptions:
> * consensus code movement changes - too big, too chaotic, too
> frequent, too unfocused, laziness guarantees others will inevitably
> ACK it without me.
> * some non-code changes (docs)
> * ignore 80% of the Qt changes
>
> As with any sort of refactoring, they are easy to prove correct, easy
> to reason, and therefore quick and easy to ACK and merge.
>
> Refactors however have a very real negative impact.
> bitcoin/bitcoin.git is not only the source tree in the universe.
> Software engineers at home, at startups, and at major companies are
> maintaining branches of their own.
>
> It is very very easy to fall into a trap where a project is merging
> lots of cosmetic changes and not seeing the downstream ripple effects.
> Several people complained to me at the conference about all the code
> movement changes breaking their own work, causing them to stay on
> older versions of bitcoin due to the effort required to rebase to each
> new release version - and I share those complaints.
>
> Complex code changes with longer development cycles than simple code
> movement patches keep breaking. It is very frustrating, and causes
> folks to get trapped between a rock and a hard place:
> - Trying to push non-trivial changes upstream is difficult, for normal
> and reasonable reasons (big important changes need review etc.).
> - Maintaining non-trivial changes out of tree is also painful, for the
> aforementioned reasons.
>
> Reasonable work languishes in constant-rebase hell, and incentivizes
> against keeping up with the latest tree.
>
>
> Aside from the refactor, libconsensus appears to be engineering in the
> dark. Where is any sort of plan? I have low standards - a photo of a
> whiteboard or youtube clip will do.
>
> The general goal is good. But we must not stray into unfocused
> engineering for a non-existent future library user.
>
> The higher priority must be given to having a source code base that
> maximizes the collective developers' ability to maintain The Router --
> the core bitcoin full node P2P engine.
>
> I recommend time-based bursts of code movement changes. See below;
> for example, just submit & merge code movement changes on the first
> week of every 2nd month. Code movement changes are easy to create
> from scratch once a concrete goal is known. The coding part is
> trivial and takes no time.
>
> As we saw in the Linux kernel - battle lessons hard learned - code
> movement and refactors have often unseen negative impact on downstream
> developers working on more complicated changes that have more positive
> impact to our developers and users.
>
>
> On Bitcoin development release cycles & process
> ------------------------------------------------------------------
>
> As I've outlined in the past, the Linux kernel maintenance phases
> address some of these problems. The merge window into git master
> opens for 1 week, a very chaotic week full of merging (and rebasing),
> and then the merge window closes. Several weeks follow as the "dust
> settles" -- testing, bug fixing, moving in parallel OOB with
> not-yet-ready development. Release candidates follow, then the
> release, then the cycle repeats.
>
> IMO a merge window approach fixes some of the issues with refactoring,
> as well as introduces some useful -developer discipline- into the
> development process. Bitcoin Core still needs rapid iteration --
> another failing of the current project -- and so something of a more
> rapid pace is needed:
> - 1st week of each month, merge changes. Lots of rebasing during this
> week.
> - remaining days of the month, test, bug fix
> - release at end of month
>
> If changes are not ready for merging, then so be it, they wait until
> next month's release. Some releases have major features, some
> releases are completely boring and offer little of note. That is the
> nature of time-based development iteration. It's like dollar cost
> averaging, a bit.
>
>
> And frankly, I would like to close all github pull requests that are
> not ready to merge That Week. I'm as guilty of this as any, but that
> stuff just languishes. Excluding a certain category of obvious-crap,
> pull requests tend to default to a state of either (a) rapid merging,
> (b) months-long issues/projects, (c) limbo.
>
> Under a more time-based approach, a better pull request process would be to
> * Only open pull requests if it's a bug fix, or the merge window is
> open and the change is ready to be merged in the developer's opinion.
> * Developers CC bitcoin-dev list to discuss Bitcoin Core-bound projects
> * Developers maintain and publish projects via their own git trees
> * Pull requests should be closed if unmerged after 7 days, unless it
> is an important bug fix etc.
>
> The problem with projects like libconsensus is that they can get
> unfocused and open ended. Code movement changes in particular are
> cheap to generate. It is low developer cost for the developer to
> iterate all the way to the end state, see what that looks like, and
> see if people like it. That end state is not something you would
> merge all in one go. I would likely stash that tree, and then start
> again, seek the most optimal and least disruptive set of refactors,
> and generate and merge those into bitcoin/bitcoin.git in a time-based,
> paced manner. Announce the pace ahead of time - "cosmetic stuff that
> breaks your patches will be merged 1st week of every second month"
>
> To underscore, the higher priority must be given to having a source
> code base and disciplined development process that maximizes the
> collective developers' ability to maintain The Router that maintains
> most of our network.
>
> Modularity, refactoring, cleaning up grotty code generates a deep
> seated happiness in many engineers. Field experience however shows
> refactoring is a never ending process which sometimes gets in the way
> of More Important Work.
> _______________________________________________
> 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/20150915/93989145/attachment-0001.html>

2023-06-07 19:39:22 CEST

- reply

📅 Original date posted:2015-09-04
📝 Original message:If you read between the lines of what was recently changed and why
(reducing to 2MB), it seems reasonable to assume BIP101's allowance
opens up some of the attack vector again.
On Fri, Sep 4, 2015 at 4:37 PM, Simon Liu via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Maybe grab some code from BIP101 ? It permits block messages > 2MB,
> while retaining the current limit of 2 MB imposed on other network
> messages. The 32 MB limit was patched a few months ago.
>
> Links to code:
>
> https://www.reddit.com/r/bitcoinxt/comments/3in5mm/psa_correction_to_btcchina_letter_which_states/
>
>
>
> On 09/04/2015 12:53 AM, Andy Chase via bitcoin-dev wrote:
>> The 32Mb limit is
>> here: https://github.com/bitcoin/bitcoin/blob/master/src/serialize.h#L25
>>
>> It's to keep the message size small enough that messages can be
>> serialized in memory.
>>
>> Jeff if you decide to lift the 32MB limit (you really should, unless
>> your plan is to potentially hard force another Blocksize discussion
>> again which might be okay). I suggest having the 32MB ceiling auto-raise
>> according to a exponential factor (1.5?) starting 1 year from now.
>>
>> Basically hard limit ceiling 2016-2017: 32 MB
>> Hard limit ceiling 2018+: 32*((currentYear-2018)*1.5) MB
>>
>> The factor could be 2 like BIP-101 but I imagine you will want to be
>> more conservative. The delay time could also be longer if you think it
>> will take longer to fix the message size issue across all implementations.
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 19:39:21 CEST

- reply

📅 Original date posted:2015-09-03
📝 Original message:Just use a 4-byte unsigned integer where the integer is the size in
bytes. It's concise and less complex (and less complex to implement).
There's no need for human readable strings here.
On Thu, Sep 3, 2015 at 5:35 PM, Jeff Garzik via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Take a look at the latest update:
>
> - swiped Tier Nolan verbiage, which I agree was usefully more clear
> - added 'M' suffix and removed 'V' from coinbase scriptSig
>
>
> On Thu, Sep 3, 2015 at 12:32 PM, jl2012 via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> 1. I think there is no need to have resolution at byte level, while
>> resolution at MB level is not enough. kB would be a better choice.
>>
>> 2. In my specification a v4 block without a vote is invalid, so there is
>> no need to consider absent or invalid votes
>>
>> 3. We should allow miners to explicitly vote for the status quo, so they
>> don't need to change the coinbase vote every time the size is changed. They
>> may indicate it by /BV/ in the coinbase, and we should look for the first
>> "/BVd*/" instead of "/BVd+/"
>>
>> 4. Alternatively, miners may vote in different styles: /BV1234567/,
>> /BV1500K/, /BV3M/. The first one means 1.234567MB, the second one is 1.5MB,
>> the last one is 3MB. The pattern is "/BV(\d+[KM]?)?/"
>>
>> Tier Nolan via bitcoin-dev 於 2015-09-03 07:59 寫到:
>>>
>>> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
>>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> *
>>>>
>>>> hardLimit floats within the range 1-32M, inclusive.
>>>
>>>
>>> Does the 32MB limit actually still exist anywhere in the code? In
>>> effect, it is re-instating a legacy limitation.
>>>
>>> The message size limit is to minimize the storage required per peer.
>>> If a 32MB block size is required, then each network input buffer must
>>> be at least 32MB. This makes it harder for a node to support a large
>>> number of peers.
>>>
>>> There is no reason why a single message is used for each block. Using
>>> the merkleblock message (or a different dedicated message), it would
>>> be possible to send messages which only contain part of a block and
>>> have a limited maximum size.
>>>
>>> This would allow receiving parts of a block from multiple sources.
>>>
>>> This is a separate issue but should be considered if moving past 32MB
>>> block sizes (or maybe as a later protocol change).
>>>
>>>> * Changing hardLimit is accomplished by encoding a proposed value
>>>> within a block's coinbase scriptSig.
>>>>
>>>> * Votes refer to a byte value, encoded within the pattern "/BVd+/"
>>>> Example: /BV8000000/ votes for 8,000,000 byte hardLimit. If there is
>>>> more than one match with with pattern, the first match is counted.
>>>
>>>
>>> Is there a need for byte resolution? Using MB resolution would use up
>>> much fewer bytes in the coinbase.
>>>
>>> Even with the +/- 20% rule, miners could vote for the nearest MB.
>>> Once the block size exceeds 5MB, then there is enough resolution
>>> anyway.
>>>
>>>> * Absent/invalid votes and votes below minimum cap (1M) are
>>>>
>>>> counted as 1M votes. Votes above the maximum cap (32M) are counted
>>>> as 32M votes.
>>>
>>>
>>> I think abstains should count for the status quo. Votes which are out
>>> of range should be clamped.
>>>
>>> Having said that, if core supports the change, then most miners will
>>> probably vote one way or another.
>>>
>>>> New hardLimit is the median of the followings:
>>>> min(current hardLimit * 1.2, 20-percentile)
>>>> max(current hardLimit / 1.2, 80-percentile)
>>>> current hardLimit
>>>
>>>
>>> I think this is unclear, though mathematically exact.
>>>
>>> Sort the votes for the last 12,000 blocks from lowest to highest.
>>>
>>> Blocks which don't have a vote are considered a vote for the status
>>> quo.
>>>
>>> Votes are limited to +/- 20% of the current value. Votes that are out
>>> of range are considered to vote for the nearest in range value.
>>>
>>> The raise value is defined as the vote for the 2400th highest block
>>> (20th percentile).
>>>
>>> The lower value is defined as the vote for the 9600th highest block
>>> (80th percentile).
>>>
>>> If the raise value is higher than the status quo, then the new limit
>>> is set to the raise value.
>>>
>>> If the lower value is lower than the status quo, then the new limit is
>>> set to the lower value.
>>>
>>> Otherwise, the size limit is unchanged.
>>>
>>> _______________________________________________
>>> 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
>

2023-06-07 19:39:19 CEST

- reply

📅 Original date posted:2015-09-03
📝 Original message:On Thu, Sep 3, 2015 at 3:34 PM, Jeff Garzik <jgarzik at gmail.com> wrote:
> A discussion of rolling out BIP 100 will not be avoided :)
>
> It is a hard fork; it would be silly to elide discussion of these key
> issues.
>
> I don't get the community's recent interest in avoiding certain topics.
It's not a matter of avoiding the subject, it's a whole separate
discussion and in the interests of efficient discussion, it is best
done separately. There's a whole BIP dedicated to the discussion of
consensus forks which you should probably give some input in also,
BIP99 [1]
Once we come to an agreement and can say "here's what we're doing
about blocksize, it will be X, or we'll raise by this algo", then we
can discuss the best way to implement the hard fork.
[1] https://github.com/bitcoin/bips/pull/181
>
>
>
> On Thu, Sep 3, 2015 at 7:20 AM, Btc Drak <btcdrak at gmail.com> wrote:
>>
>> We should avoid discussing actual hard fork/softfork deployment
>> methodologies when discussing blocksize proposals because deployment
>> is a separate issue. As a recent case in point, look at how BIP65
>> (CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.
>> That lead to a focused discussion of the functionality and relatively
>> quick inclusion.
>>
>> Deployment really is a separate issue than the mechanics of how BIP100
>> will function after activation.
>>
>> On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
>> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> > Some comments:
>> >
>> > The 75% rule is meaningless here. Since this is a pure relaxation of
>> > rules,
>> > there is no such thing as "invalid version 4 blocks"
>> >
>> > The implication threshold is unclear. Is it 95% or 80%?
>> >
>> > Softfork requires a very high threshold (95%) to "attack" the original
>> > fork.
>> > This makes sure that unupgraded client will only see the new fork.
>> > In the case of hardfork, however, the new fork is unable to attack the
>> > original fork, and unupgraded client will never see the new fork. The
>> > initiation of a hardfork should be based on its acceptance by the
>> > economic
>> > majority, not miner support. 95% is an overkill and may probably never
>> > accomplished. I strongly prefer a 80% threshold rather than 95%.
>> >
>> > As I've pointed out, using 20-percentile rather than median creates an
>> > incentive to 51% attack the uncooperative minority.
>> >
>> > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
>> >
>> > Having said that, I don't have a strong feeling about the use of
>> > 20-percentile as threshold to increase the block size. That means the
>> > block
>> > size is increased only when most miners agree, which sounds ok to me.
>> >
>> > However, using 20-percentile as threshold to DECREASE the block size
>> > could
>> > be very dangerous. Consider that the block size has been stable at 8MB
>> > for a
>> > few years. Everyone are happy with that. An attacker would just need to
>> > acquire 21% of mining power to break the status quo and send us all the
>> > way
>> > to 1MB. The only way to stop such attempt is to 51% attack the attacker.
>> > That'd be really ugly.
>> >
>> > For technical and ethical reasons, I believe the thresholds for increase
>> > and
>> > decrease must be symmetrical: increase the block size when the
>> > x-percentile
>> > is bigger than the current size, decrease the block size when the
>> > (100-x)-percentile is smaller than the current size. The overall effect
>> > is:
>> > the block size remains unchanged unless 80% of miners agree to.
>> >
>> > Please consider the use of "hardfork bit" to signify the hardfork:
>> >
>> >
>> > https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
>> >
>> > https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
>> >
>> > Or, alternatively, please combine the hardfork with a softfork. I'm
>> > rewriting the specification as follow (changes underlined):
>> >
>> > Replace static 1M block size hard limit with a floating limit
>> > ("hardLimit").
>> >
>> > hardLimit floats within the range 1-32M, inclusive.
>> >
>> > Initial value of hardLimit is 1M, preserving current system.
>> >
>> > Changing hardLimit is accomplished by encoding a proposed value within a
>> > block's coinbase scriptSig.
>> >
>> > Votes refer to a byte value, encoded within the pattern "/BV\d+/"
>> > Example:
>> > /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than
>> > one
>> > match with with pattern, the first match is counted.
>> > Absent/invalid votes and votes below minimum cap (1M) are counted as 1M
>> > votes. Votes above the maximum cap (32M) are counted as 32M votes.
>> > A new hardLimit is calculated at each difficult adjustment period (2016
>> > blocks), and applies to the next 2016 blocks.
>> > Calculate hardLimit by examining the coinbase scriptSig votes of the
>> > previous 12,000 blocks, and taking the 20th percentile and 80th
>> > percentile.
>> > New hardLimit is the median of the followings:
>> >
>> > min(current hardLimit * 1.2, 20-percentile)
>> > max(current hardLimit / 1.2, 80-percentile)
>> > current hardLimit
>> >
>> > version 4 block: the coinbase of a version 4 block must match this
>> > pattern:
>> > "/BV\d+/"
>> > 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,
>> > reject invalid version 4 blocks. (testnet4: 501 of last 1000)
>> > 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are
>> > version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of
>> > last
>> > 1000)
>> > Block version number is calculated after masking out high 16 bits (final
>> > bit
>> > count TBD by versionBits outcome).
>> >
>> > Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:
>> >> BIP 100 initial public draft:
>> >> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
>> >>
>> >> Emphasis on "initial" This is a starting point for the usual open
>> >> source feedback/iteration cycle, not an endpoint that Must Be This
>> >> Way.
>> >>
>> >>
>> >>
>> >> Links:
>> >> ------
>> >> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>> >>
>> >> _______________________________________________
>> >> 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
>> >
>
>

2023-06-07 19:39:17 CEST

- reply

📅 Original date posted:2015-09-03
📝 Original message:We should avoid discussing actual hard fork/softfork deployment
methodologies when discussing blocksize proposals because deployment
is a separate issue. As a recent case in point, look at how BIP65
(CHECKLOCKTIMEVERIFY) specifically avoided the issue of how to deploy.
That lead to a focused discussion of the functionality and relatively
quick inclusion.
Deployment really is a separate issue than the mechanics of how BIP100
will function after activation.
On Thu, Sep 3, 2015 at 8:57 AM, jl2012 via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Some comments:
>
> The 75% rule is meaningless here. Since this is a pure relaxation of rules,
> there is no such thing as "invalid version 4 blocks"
>
> The implication threshold is unclear. Is it 95% or 80%?
>
> Softfork requires a very high threshold (95%) to "attack" the original fork.
> This makes sure that unupgraded client will only see the new fork.
> In the case of hardfork, however, the new fork is unable to attack the
> original fork, and unupgraded client will never see the new fork. The
> initiation of a hardfork should be based on its acceptance by the economic
> majority, not miner support. 95% is an overkill and may probably never
> accomplished. I strongly prefer a 80% threshold rather than 95%.
>
> As I've pointed out, using 20-percentile rather than median creates an
> incentive to 51% attack the uncooperative minority.
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010690.html
>
> Having said that, I don't have a strong feeling about the use of
> 20-percentile as threshold to increase the block size. That means the block
> size is increased only when most miners agree, which sounds ok to me.
>
> However, using 20-percentile as threshold to DECREASE the block size could
> be very dangerous. Consider that the block size has been stable at 8MB for a
> few years. Everyone are happy with that. An attacker would just need to
> acquire 21% of mining power to break the status quo and send us all the way
> to 1MB. The only way to stop such attempt is to 51% attack the attacker.
> That'd be really ugly.
>
> For technical and ethical reasons, I believe the thresholds for increase and
> decrease must be symmetrical: increase the block size when the x-percentile
> is bigger than the current size, decrease the block size when the
> (100-x)-percentile is smaller than the current size. The overall effect is:
> the block size remains unchanged unless 80% of miners agree to.
>
> Please consider the use of "hardfork bit" to signify the hardfork:
>
> https://www.reddit.com/r/bitcoin_devlist/comments/3ekhg2/bip_draft_hardfork_bit_jl2012_at_xbthk_jul_23_2015/
>
> https://github.com/jl2012/bips/blob/master/hardforkbit.mediawiki
>
> Or, alternatively, please combine the hardfork with a softfork. I'm
> rewriting the specification as follow (changes underlined):
>
> Replace static 1M block size hard limit with a floating limit ("hardLimit").
>
> hardLimit floats within the range 1-32M, inclusive.
>
> Initial value of hardLimit is 1M, preserving current system.
>
> Changing hardLimit is accomplished by encoding a proposed value within a
> block's coinbase scriptSig.
>
> Votes refer to a byte value, encoded within the pattern "/BV\d+/" Example:
> /BV8000000/ votes for 8,000,000 byte hardLimit. If there is more than one
> match with with pattern, the first match is counted.
> Absent/invalid votes and votes below minimum cap (1M) are counted as 1M
> votes. Votes above the maximum cap (32M) are counted as 32M votes.
> A new hardLimit is calculated at each difficult adjustment period (2016
> blocks), and applies to the next 2016 blocks.
> Calculate hardLimit by examining the coinbase scriptSig votes of the
> previous 12,000 blocks, and taking the 20th percentile and 80th percentile.
> New hardLimit is the median of the followings:
>
> min(current hardLimit * 1.2, 20-percentile)
> max(current hardLimit / 1.2, 80-percentile)
> current hardLimit
>
> version 4 block: the coinbase of a version 4 block must match this pattern:
> "/BV\d+/"
> 70% rule: If 8,400 of the last 12,000 blocks are version 4 or greater,
> reject invalid version 4 blocks. (testnet4: 501 of last 1000)
> 80% rule ("Point of no return"): If 9,600 of the last 12,000 blocks are
> version 4 or greater, reject all version <= 3 blocks. (testnet4: 750 of last
> 1000)
> Block version number is calculated after masking out high 16 bits (final bit
> count TBD by versionBits outcome).
>
> Jeff Garzik via bitcoin-dev 於 2015-09-02 23:33 寫到:
>> BIP 100 initial public draft:
>> https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki [1]
>>
>> Emphasis on "initial" This is a starting point for the usual open
>> source feedback/iteration cycle, not an endpoint that Must Be This
>> Way.
>>
>>
>>
>> Links:
>> ------
>> [1] https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
>>
>> _______________________________________________
>> 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
>

2023-06-07 19:37:58 CEST

- reply

📅 Original date posted:2015-08-28
📝 Original message:On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> When discussing this with Matt Whitlock earlier we basically concluded the
> block size will never increase under this proposal do to a collective action
> problem. If a miner votes for an increase and nobody else does, the
> blocksize will not increase yet he will still have to pay the difficulty
> penalty.
>
> It may be in everyone's collective interest to raise the block size but not
> their individual interest.
It is clear from recent events that miners are willing to collaborate
together for the greater good of their industry. Miners have also
publicly shown support for raising the blocksize collaboratively.
Obviously, as transaction volume grows they want to collect as many
transaction fees as possible so if there isnt enough space in blocks,
they're going to vote for increases because it's in their collective
financial interests. The proposal specifically encourages
collaboration and hinders antisocial behaviour, and it specifically
encourages the blocksize to be raised according to demand without
neutering the fee market.

2023-06-07 19:37:54 CEST

- reply

📅 Original date posted:2015-08-29
📝 Original message:On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Ah, then my mistake. It seemed so similar to an idea that was proposed
> before on this mailing list:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
>
> that my mind just filled in the gaps. I concur -- having miners -- or any
> group -- vote on block size is not an intrinsically good thing. The the
> original proposal due to Greg Maxwell et al was not a mechanism for "voting"
> but rather a feedback control that made the maximum block size that which
> generated the most fees.
Mark and Jorge,
I am very glad you have brought up this particular objection because
it's something I thought about but was unclear if it was an opinion
that would be shared by others. I chose to omit it from the proposal
to see if it would come up during peer review.
I feel that giving miners a blank cheque to increase blocksize, by any
means, goes against a key design of bitcoin's security model. Full
nodes keep miners honest by ensuring by validating their blocks. Under
any voting-only scheme there is no way for full nodes to keep miners
in cheque because miner have free reign to increase the blocksize.
This problem can be solved by introducing a hard cap on blocksize. By
introducing an upper limit miners now have the freedom to increase
blocksize but only within defined parameters. Remember my proposal
allows blocksize to increase and decrease in such a way that miners
must collectively agree if they want the size to increase.
I believe the idea of a hard upper limit has become rather politicised
but is essential to the security model of bitcoin.
With respect to the flexicap idea where miners can create a larger
block by paying extra difficulty, I believe that proposal has a
critical flaw because, as Gavin pointed out, it makes it very
expensive (and risky) to include a few extra transactions. I believe
it suffers from tragedy of the commons because there is no incentive
for the mining community to reach consensus. Each and every block is
going to be a gamble, "should we include a few extra transactions at
the risk of losing the block?". Under my proposal miners can
collectively agree to change the blocksize. Let's say they want a 10%
increase, they can collude together to make that increase and once
reached, it remains until they want to change it again. Yet, the upper
hard limit keeps the ultimate control of the maximum block size
squarely in the hands of full nodes.
Whilst the exact number may be up for discussion, I would propose an
initial upper limit of 8MB, so under my proposal the blocksize would
be flexible between 1MB and 8MB.
An alternative methodology to voting in the coinbase would be to
change the vote to be the blocksize itself
1. miners pay extra difficulty to create a larger block.
2. every 2016 blocks the average or median of the last 2016 blocks is
calculated and becomes the new maximum blocksize limit.
This would retain incentive to collude to increase blocksize, as well
as the property of costing to increase while being free to propose
decrease.
It would still require an upper blocksize limit in order for full
nodes to retain control. Without an upper limit, any proposal is going
to break the security model as full nodes give up some oversight
control over miners.
Another way of looking at these ideas is we're raising blocksize hard
limit (to 8MB or whatever is decided), but making a soft of "softer"
or inner limit part of consensus. Such a concept is not really
departing from the current idea of a soft limit except to make it
consensus enforced. Obviously it's not identical, but I think you can
see the similarities.
Does that make sense?

2023-06-07 19:37:50 CEST

- reply

📅 Original date posted:2015-08-28
📝 Original message:I have received a lot of feedback on the original gist[1], reddit[2],
ML and IRC and have reworked the text somewhat.
I also request the BIP maintainer for a BIP number assignment
[1] https://gist.github.com/btcdrak/1c3a323100a912b605b5
[2] https://www.reddit.com/r/Bitcoin/comments/3ibia0/bipxx_consensus_based_block_size_retargeting/
Pull request: https://github.com/bitcoin/bips/pull/187
<pre>
BIP: XX
Title: Consensus based block size retargeting algorithm
Author: BtcDrak <btcdrak at gmail.com>
Status: Draft
Type: Standards Track
Created: 2015-08-21
</pre>
==Abstract==
A method of altering the maximum allowed block size of the Bitcoin protocol
using a consensus based approach.
==Motivation==
There is a belief that Bitcoin cannot easily respond to raising the
blocksize limit if popularity was to suddenly increase due to a mass adoption
curve, because co-ordinating a hard fork takes considerable time, and being
unable to respond in a timely manner would irreparably harm the credibility of
bitcoin.
Additionally, predetermined block size increases are problematic because they
attempt to predict the future, and if too large could have unintended
consequences like damaging the possibility for a fee market to develop
as block subsidy decreases substantially over the next 9 years; introducing
or exacerbating mining attack vectors; or somehow affect the network in unknown
or unpredicted ways. Since fixed changes are hard to deploy, the damage could be
extensive.
Dynamic block size adjustments also suffer from the potential to be gamed by the
larger hash power.
Free voting as suggested by BIP100 allows miners to sell their votes out of band
at no risk, and enable the sponsor the ability to manipulate the blocksize.
It also provides a cost free method or the larger pools to vote in ways to
manipulate the blocksize such to disadvantage or attack smaller pools.
==Rationale==
By introducing a cost to increase the block size ensures the mining community
will collude to increase it only when there is a clear necessity, and reduce it
when it is unnecessary. Larger miners cannot force their wishes so easily
because not only will they have to pay extra a difficulty target, then can be
downvoted at no cost by the objecting hash power.
Using difficulty as a penalty is better than a fixed cost in bitcoins because it
is less predictable.
==Specification==
The initial block size limit shall be 1MB.
Each time a miner creates a block, they may vote to increase or decrease the
blocksize by a maximum of 10% of the current block size limit. These votes will
be used to recalculate the new block size limit every 2016 blocks.
Votes are cast using the block's coinbase field.
The first 4 bytes of the coinbase field shall be repurposed for voting as an
unsigned long integer which will be the block size in bytes.
If a miner votes for an increase, the block hash must meet a difficulty target
which is proportionally larger than the standard difficulty target based on the
percentage increase they voted for.
Votes proposing decreasing the block size limit do not need to meet a higher
difficulty target.
Miners can vote for no change by voting for the current block size.
For blocks to be valid the blockhash must meet the required difficulty target
for the vote otherwise the block is invalid and will be rejected.
Every 2016 blocks, the block size limit will be recalculated by the median of
all votes in the last 2016 blocks. This will redefine the block size limit for
the next 2016 blocks.
Blocks that are larger than the calculated base block size limit are invalid and
will be rejected.
The base block size limit may not reduce below 1MB.
==Acknowledgements==
This proposal is based on ideas and concepts derived from the writings of
Meni Rosenfeld and Gregory Maxwell.
==Copyright==
This work is placed in the public domain.

2023-06-07 19:37:48 CEST

- reply

📅 Original date posted:2015-08-21
📝 Original message:I wanted to offer a potential way to adjust the block size limit in a
democratic way without making it easy to game. This is meant only as a
starting point for a general idea. Thresholds and exact figures and
the details of the algorithm are up for debate, and possibly some
formula based determination.
The living document is currently a gist available at
https://gist.github.com/btcdrak/1c3a323100a912b605b5
<pre>
BIP: XX
Title: Consensus based block size retargeting algorithm
Author: BtcDrak <btcdrak at gmail.com>
Status: Draft
Type: Standards Track
Created: 2015-08-21
</pre>
==Abstract==
A method of altering the maximum allowed block size of the Bitcoin
protocol using a consensus based approach.
==Motivation==
There is a perception that Bitcoin cannot easily respond to raising
the blocksize limit if popularity was to suddenly increase due to a
mass adoption curve, because co-ordinating a hard fork takes
considerable time, and being unable to respond in a timely manner
would irreparably harm the credibility of bitcoin.
Additionally, predetermined block size increases are problematic
because they attempt to predict the future, and if too large could
have unintended consequences like damaging the possibility for a fee
market to develop as block subsidy decreases substantially over the
next 9 years; introducing or exacerbating mining attack vectors; or
somehow affect the network in unknown or unpredicted ways. Since fixed
changes are hard to deploy, the damage could be extensive.
Dynamic block size adjustments also suffer from the potential to be
gamed by the larger hash power.
==Rationale==
By introducing a cost to increase the block size ensures the mining
community will collude to increase it only when there is a clear
necessity, and reduce it when it is unnecessary. Rogue miners cannot
force their wishes so easily because not only will they have to pay
extra a difficulty target, then can be downvoted at no cost by the
objecting hash power.
==Specification==
The initial "base block size limit" shall be 1MB.
Miners can vote for a block size increase by signalling the proposed
percentage increase of the "base block size limit" in the coinbase
field. For the vote to be considered valid the block they mine must
meets a difficulty target which is proportionally larger than the
standard difficulty target based on the percentage increase they voted
for. If a miner does not vote, or the vote is invalid, it shall be
counted as a vote for no change.
Miners may vote the size down by signalling in the coinbase field
without paying a difficulty penalty.
Every 2016 blocks, the maximum allowed block size will be recalculated
by the average of all votes in the last 2016 blocks, i.e. sum each
vote from each block and divide by 2016 then multiply by the base
block size limit. This will redefine the base block size limit for the
next 2016 blocks.
Blocks that are larger than the calculated base block size limit are
invalid and MUST be rejected.
The maximum change up or down each retargeting period shall be limited
to 10% of the base block size limit.
The maximum block size may not increase above 8MB.
Votes shall be cast by adding the following human readable multiplier
to the coinbase string “/BXn.nnn/” where valid votes would exist
between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10%
increase). “/BX1.000/” would be a vote for no change. Invalid votes
will be counted as a vote for no change: “/BX1.000/”.
==Acknowledgements==
This proposal is based on ideas and concepts derived from the writings
of Meni Rosenfeld and Gregory Maxwell.
==Copyright==
This work is placed in the public domain.

2023-06-07 19:36:59 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 2:24 PM, Tier Nolan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 19, 2015 at 2:15 PM, Btc Drak via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>> What problem am I missing if we just mask of the offending bits. For my own project which uses auxpow (and thus has weird nVersion), I also used the bitmasking method to get rid of auxpow version bits before making the standard integer comparisons to deploy BIP66 using IsSuperMajority():
>>
>> if ((block.nVersion & 0xff) >= 4 && CBlockIndex::IsSuperMajority(...)) { //...}
>
> What if version number 257 is used in the future? That would appear to be a version 1 block and fail the test.
To clarify this is the code example for how the same problem occurs
with auxpow bits when running a an IsSuperMajority() softfork and how
it's solved in that instance.
In our case for Bitcoin Core, option 2 we use nVersion=8, apply a
bitmask of 0xdffffff8 thus:
if ((block.nVersion & ~0x20000007) >= 4 &&
CBlockIndex::IsSuperMajority(...)) { //...}
With nVersion=8, but using comparison >=4 allows us to recover the
bit later, assuming we want it (otherwise we use version >=8).
This should, unless I am missing something, be forward compatible with
future softforks. My understanding was if "versionbits softfork" code
is not ready by the time we're ready for the deployment,
IsSuperMajority() would be acceptable; and this is how we could deploy
it in the wake of the XT developers' carelessness.

2023-06-07 19:36:59 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 11:31 AM, Jorge Timón <jtimon at jtimon.cc> wrote:
> I don't think just using version=4 for cltv and friends would be a
> problem if it wasn't for the XT/nonXT issue.
What problem am I missing if we just mask of the offending bits. For my own
project which uses auxpow (and thus has weird nVersion), I also used the
bitmasking method to get rid of auxpow version bits before making the
standard integer comparisons to deploy BIP66 using IsSuperMajority():
if ((block.nVersion & 0xff) >= 4 && CBlockIndex::IsSuperMajority(...))
{ //...}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/aeca027e/attachment.html>

2023-06-07 19:36:58 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 10:34 AM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Seems like 3 is something we want to do no matter what and therefore
> is the "most future-proof" solution.
> I wonder if I can help with that (and I know there's more people that
> would be interested).
> Where's the current "non-full" nVersion bits implementation?
> Why implement a "non-full" version instead of going with the full
> implementation directly?
There is a simple answer to this, convenience: versionbits has not been
implemented yet, and I believe the BIP is still in review stage. As it
seems likely the remaining locktime pull requests will be ready by or
before the next major release, we need a deployment method if versionbits
is not ready (which is unlikely because no-one appears to be working on it
at the moment). Pieter indicated he is OK with another IsSuperMajority()
rollout in the interim. Personally, I dont think we should let perfection
be the enemy of progress here because at the end of the day, the deployment
method is less important than the actual featureset being proposed.
That said, the features in the next soft fork proposal are all related and
best deployed as one featureset softfork, but moving forward, versionbits
seems essential to be able to roll out multiple features in parallel
without waiting for activation and enforcement each time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150819/abd890c2/attachment.html>

2023-06-07 19:36:49 CEST

- reply

📅 Original date posted:2015-08-21
📝 Original message:I was looking at this site recently and it's not very clear that by
clicking the name you get their opinion. I would make that a separate
column stated, Technical Opinion.
I think you need to include more of the developers/technical people,
Adam Back, Mark Friedenback, Jorge Timons, (all of who are core
developers). You need
Peter Todd is a core dev btw, as is thebluematt.
You need other experts, I would include Nick Szabo, Meni Rosenfeld,
Charlie Lee might be a good one. You should get the pools on there
too.
You're missing Mike Hearn of course.
My key is 0xE5D138F5E73A1AF2
On Wed, Aug 19, 2015 at 5:57 AM, Nicolas Dorier via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I created a small website which show a chart of your approvals about various
> BIPs (which you must fill by yourself with a signed pgp message)
>
> For each BIP, you can fill if you approve or not, and give comments. (HTML
> accepted, so you can link stuff you your posts)
>
> It would help the community a lot, so I hope you will do it !
> I'm open to add other important devs, big miners, or other proposal that I
> missed.
>
> Please, respond on BTC Talk or github. (I don't read the mailing anymore
> because of the spam :( )
>
> Link : http://bipsxdevs.azurewebsites.net/
> BtcTalk Topic : https://bitcointalk.org/index.php?topic=1156164
> Github : https://github.com/NicolasDorier/BIPxDevs
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

2023-06-07 19:36:18 CEST

- reply

📅 Original date posted:2015-08-17
📝 Original message:On Mon, Aug 17, 2015 at 10:59 AM, Patrick Strateman via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Nobody is going to click that...
I guess I am nobody. Here's a copy of the text:-
*Dynamically Controlled Bitcoin Block Size Max Cap
<http://upalc.com/maxblocksize.php>*
*Assumption*: This article is for those, who already understand the bitcoin
protocol and aware of the block size controversy. Details of the problem
statement can be found in BIP 100
<http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf>.
Satoshi's opinion regarding block size can be found here
<https://bitcointalk.org/index.php?topic=1347.msg15366#msg15366>. I will be
directly going into the solution without explaining the problem in details.
*Solution*: Difficulty changes at every 2016 block, i.e. at every 2016
block each full node does a calculation to find the next target. We will do
just another calculation here. Nodes will also calculate what % of blocks
in the last difficulty period is higher than 90% of the maximum block size,
which is 1 MB for now. If it is found that more than 90% blocks in the last
difficulty period is higher than 90% of the maximum block size, then double
the maximum block size. If not, then calculate what % of blocks in the last
difficulty period is less than 50% of the maximum block size. If it is
higher than 90%, then half the maximum block size. If none of the above
condition satisfies, keep the maximum block size as it is.
Please note that, while calculating the % of blocks, it is better to take
into account the first 2000 of the 2016, than the whole of 2016. This helps
to avoid the calculation mistake if some of the last few blocks get
orphaned.
*Reasoning*: This solution is derived directly from the indication of the
problem. If transaction volume increases, then we will naturally see bigger
blocks. On the contrary, if there are not enough transaction volume, but
maximum block size is high, then only few blocks may sweep the mempool.
Hence, if block size is itself taken into consideration, then maximum block
size can most rationally be derived. Moreover, this solution not only
increases, but also decreases the maximum block size, just like difficulty.
*Other Solutions of this Problem*:-
Making Decentralized Economic Policy
<http://gtf.org/garzik/bitcoin/BIP100-blocksizechangeproposal.pdf> - by
Jeff Garzik
Elastic block cap with rollover penalties
<https://bitcointalk.org/index.php?topic=1078521> – by Meni Rosenfeld
Increase maximum block size
<https://github.com/bitcoin/bips/blob/master/bip-0101.mediawiki> - by Gavin
Andresen
Block size following technological growth
<https://gist.github.com/sipa/c65665fc360ca7a176a6> - by Pieter Wuille
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
<https://lightning.network/lightning-network-paper.pdf> - by Joseph Poon &
Thaddeus Dryja
Please share your opinion regarding this solution below. For mail
communication, feel free to write me at bitcoin [at] upalc.com.
> On 08/17/2015 02:44 AM, Upal Chakraborty via bitcoin-dev wrote:
>
> I have tried to solve the maximum block size debate, depending on the
> previous block size calculation.
>
> Requesting for comment - http://upalc.com/maxblocksize.php
>
>
> _______________________________________________
> 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/20150817/9a6dca23/attachment.html>

2023-06-07 19:35:51 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 7:20 PM, Peter Todd <pete at petertodd.org> wrote:
> Normal GitHub users submitting pull-reqs to Bitcoin Core can't delete
> other users' comments on their own pull-reqs...
>
> IMO that's an abuse of the pull-req process, and in turn, Gavin
> Andresens's commit access rights for the Bitcoin Core repo.
For the avoidance of doubt here's the archive link of my comment
https://archive.is/omvSY#40% (call me paranoid)
and here's where he tells me he's censored my posts https://archive.is/vym6N#40%
> I think this should weigh in favor of Gavin Andresen not having commit
> privileges for the Bitcoin Core repository.
It's time.

2023-06-07 19:35:51 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:On Wed, Aug 19, 2015 at 5:53 PM, Adam Back via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> 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.
I would like to add for the record, I also warned Gavin of this in his
PR to Bitcoin Core, and also suggested a timeout which if
activation/enforcement did not occur within, hard fork deployment
would be cancelled. His response was to delete these from the PR
claiming thresholds were not relevant conversation in his PR and
belonged elsewhere (even though they had already been discussed
elsewhere).

2023-06-07 19:35:48 CEST

- reply

📅 Original date posted:2015-08-19
📝 Original message:I see no problem with Satoshi returning to participate in peer review.
Bitcoin development has long since migrated from a single authority figure
to a system of technical peer review consensus. What is more of a problem
is this list has degenerated to a generalised discussion forum where any
academic or technical debate is drowned out by noise.
I joined this list so I keep be abreast of bitcoin's technical development
and proposals. I am sure many ecosystem stakeholders and participants also
once used this list to keep abreast of technical developments and academic
research. It would be splendid indeed if we could return to some semblance
of decorum that once existed.
Do you think we could have a "bitcoin-discuss" list where specifically
non-technical discussion can happen leaving this list for more academic and
technical debate together with setting a clear mandate about what is on
topic for this list?
On Tue, Aug 18, 2015 at 12:52 PM, Micha Bailey via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> My interpretation is that he's saying Satoshi wouldn't be welcome to
> return as Satoshi, because whatever he did/said would inevitably end up
> being treated with authority, which shouldn't be the case.
>
>
> On Tuesday, August 18, 2015, Warren Togami Jr. via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I honestly don't understand your position, but I get the sense that you
>> are suggesting Satoshi wouldn't be welcome to return if he wanted to be
>> active in development again?
>>
>> Warren
>> On Aug 17, 2015 1:38 PM, "Oliver Egginger" <bitcoin at olivere.de> wrote:
>>
>>> Am 17.08.2015 um 21:03 schrieb Warren Togami Jr.:
>>> > This bitcoin-dev list restarted with an empty subscriber list on June
>>> > 21st, 2015. So whoever posted from satoshi at vistomail.com
>>> > <mailto:satoshi at vistomail.com> subscribed and verified the address
>>> > recently. Do you propose that we manually approve new subscribers to
>>> > prevent these kind of "abuses" as you put it?
>>>
>>> I would simply block the creators old email addresses. Easy with
>>> Mailman. I thought that would be a good and easy approach, but maybe I'm
>>> wrong.
>>>
>>> Some believes it is possible that the email could be genuine. Some say
>>> that only the content is important. I have closely followed. An
>>> interesting discussion. Thank you all so far.
>>>
>>> But let's say the poster would be the real Satoshi. Would we discuss his
>>> posting if he would not claim to be Satoshi? There are a lot of smart
>>> people on this list, which publish occasionally quite useful ideas. But
>>> much of this is hardly the subject of greater discussion. Especially not
>>> when it comes to the blocksize. On this subject almost everything has
>>> been already said. But not yet by everyone. Especially not by Satoshi.
>>>
>>> Satoshi would have a decisive influence on the community. I'm sure. To
>>> say it does not matter who's talking is maybe genteelly but a little bit
>>> remote from everyday life. Or not? Satoshi is the creator. What he says
>>> is in the newspaper and is perceived by all. If he says it's okay to do
>>> nothing as long as we stand together, then people have the courage to do
>>> maybe something dangerous or something wrong. Then people only follow
>>> their hearts. Otherwise they follow their fear. It is a paradox of the
>>> human nature that some type of Dictatorship can make you free. I say
>>> some type, not any type. Enough said.
>>>
>>> - oliver
>>>
>>>
> _______________________________________________
> 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/20150819/f49ea8d0/attachment.html>

2023-06-07 19:34:56 CEST

- reply

📅 Original date posted:2015-08-17
📝 Original message:Please note there is now a PR for this BIP[1] and also a pull request for
the opcode CHECKSEQUENCEVERIFY in Bitcoin Core[2].
[1] https://github.com/bitcoin/bips/pull/179
[2] https://github.com/bitcoin/bitcoin/pull/6564
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/364f36b8/attachment.html>

2023-06-07 19:34:53 CEST

- reply

📅 Original date posted:2015-08-13
📝 Original message:I have written the following draft BIP for a new opcode
CHECKSEQUENCEVERIFY by Mark Friedenbach, which introduces a form of
relative-locktime to Bitcoin's scripting language.
https://github.com/btcdrak/bips/blob/bip-checksequenceverify/bip-csv.mediawiki
<pre>
BIP: XX
Title: CHECKSEQUENCEVERIFY
Authors: BtcDrak <btcdrak at gmail.com>
Mark Friedenbach <mark at friedenbach.org>
Status: Draft
Type: Standards Track
Created: 2015-08-10
</pre>
==Abstract==
This BIP describes a new opcode (CHECKSEQUENCEVERIFY) for the Bitcoin
scripting system that in combination with BIP 68 allows execution
pathways of a script to be restricted based on the age of the output
being spent.
==Summary==
CHECKSEQUENCEVERIFY redefines the existing NOP3 opcode. When executed
it compares the top item on the stack to the inverse of the nSequence
field of the transaction input containing the scriptSig. If the
inverse of nSequence is less than the sequence threshold (1 << 31),
the transaction version is greater than or equal to 2, and the top
item on the stack is less than or equal to the inverted nSequence,
script evaluation continues as though a NOP was executed. Otherwise
the script fails immediately.
BIP 68's redefinition of nSequence prevents a non-final transaction
from being selected for inclusion in a block until the corresponding
input has reached the specified age, as measured in block heiht or
block time. By comparing the argument to CHECKSEQUENCEVERIFY against
the nSequence field, we indirectly verify a desired minimum age of the
the output being spent; until that relative age has been reached any
script execution pathway including the CHECKSEQUENCEVERIFY will fail
to validate, causing the transaction not to be selected for inclusion
in a block.
==Motivation==
BIP 68 repurposes the transaction nSequence field meaning by giving
sequence numbers new consensus-enforced semantics as a relative
lock-time. However, there is no way to build Bitcoin scripts to make
decisions based on this field.
By making the nSequence field accessible to script, it becomes
possible to construct code pathways that only become accessible some
minimum time after proof-of-publication. This enables a wide variety
of applications in phased protocols such as escrow, payment channels,
or bidirectional pegs.
==Specification==
Refer to the reference implementation, reproduced below, for the precise
semantics and detailed rationale for those semantics.
case OP_NOP3:
{
if (!(flags & SCRIPT_VERIFY_CHECKSEQUENCEVERIFY)) {
// not enabled; treat as a NOP3
if (flags & SCRIPT_VERIFY_DISCOURAGE_UPGRADABLE_NOPS) {
return set_error(serror, SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS);
}
break;
}
if (stack.size() < 1)
return set_error(serror, SCRIPT_ERR_INVALID_STACK_OPERATION);
// Note that unlike CHECKLOCKTIMEVERIFY we do not need to
// accept 5-byte bignums since any value greater than or
// equal to SEQUENCE_THRESHOLD (= 1 << 31) will be rejected
// anyway. This limitation just happens to coincide with
// CScriptNum's default 4-byte limit with an explicit sign
// bit.
//
// This means there is a maximum relative lock time of 52
// years, even though the nSequence field in transactions
// themselves is uint32_t and could allow a relative lock
// time of up to 120 years.
const CScriptNum nInvSequence(stacktop(-1), fRequireMinimal);
// In the rare event that the argument may be < 0 due to
// some arithmetic being done first, you can always use
// 0 MAX CHECKSEQUENCEVERIFY.
if (nInvSequence < 0)
return set_error(serror, SCRIPT_ERR_NEGATIVE_LOCKTIME);
// Actually compare the specified inverse sequence number
// with the input.
if (!CheckSequence(nInvSequence))
return set_error(serror, SCRIPT_ERR_UNSATISFIED_LOCKTIME);
break;
}
bool CheckSequence(const CScriptNum& nInvSequence) const
{
int64_t txToInvSequence;
// Fail under all circumstances if the transaction's version
// number is not set high enough to enable enforced sequence
// number rules.
if (txTo->nVersion < 2)
return false;
// Sequence number must be inverted to convert it into a
// relative lock-time.
txToInvSequence = (int64_t)~txTo->vin[nIn].nSequence;
// Sequence numbers under SEQUENCE_THRESHOLD are not consensus
// constrained.
if (txToInvSequence >= SEQUENCE_THRESHOLD)
return false;
// There are two types of relative lock-time: lock-by-
// blockheight and lock-by-blocktime, distinguished by
// whether txToInvSequence < LOCKTIME_THRESHOLD.
//
// We want to compare apples to apples, so fail the script
// unless the type of lock-time being tested is the same as
// the lock-time in the transaction input.
if (!(
(txToInvSequence < LOCKTIME_THRESHOLD && nInvSequence <
LOCKTIME_THRESHOLD) ||
(txToInvSequence >= LOCKTIME_THRESHOLD && nInvSequence >=
LOCKTIME_THRESHOLD)
))
return false;
// Now that we know we're comparing apples-to-apples, the
// comparison is a simple numeric one.
if (nInvSequence > txInvToSequence)
return false;
return true;
}
https://github.com/maaku/bitcoin/commit/33be476a60fcc2afbe6be0ca7b93a84209173eb2
==Example: Escrow with Timeout==
An escrow that times out automatically 30 days after being funded can be
established in the following way. Alice, Bob and Escrow create a 2-of-3
address with the following redeemscript.
IF
2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3
CHECKMULTISIGVERIFY
ELSE
<LOCKTIME_THRESHOLD + 30*24*60*60> CHECKSEQUENCEVERIFY DROP
<Alice's pubkey> CHECKSIGVERIFY
ENDIF
At any time funds can be spent using signatures from any two of Alice,
Bob or the Escrow.
After 30 days Alice can sign alone.
The clock does not start ticking until the payment to the escrow address
confirms.
==Reference Implementation==
A reference implementation is provided in the following git repository:
https://github.com/maaku/bitcoin/tree/checksequenceverify
==Deployment==
We reuse the double-threshold switchover mechanism from BIPs 34 and
66, with the same thresholds, but for nVersion = 4. The new rules are
in effect for every block (at height H) with nVersion = 4 and at least
750 out of 1000 blocks preceding it (with heights H-1000..H-1) also
have nVersion = 4. Furthermore, when 950 out of the 1000 blocks
preceding a block do have nVersion = 4, nVersion = 3 blocks become
invalid, and all further blocks enforce the new rules.
It is recommended that this soft-fork deployment trigger include other
related proposals for improving Bitcoin's lock-time capabilities, including:
[https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki BIP 65]:
OP_CHECKLOCKTIMEVERIFY,
[https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki BIP 68]:
Consensus-enforced transaction replacement signalled via sequence numbers,
and [https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki BIP XX]:
Median-Past-Time-Lock.
==Credits==
Mark Friedenbach invented the application of sequence numbers to
achieve relative lock-time, and wrote the reference implementation of
CHECKSEQUENCEVERIFY.
The reference implementation and this BIP was based heavily on work
done by Peter Todd for the closely related BIP 65.
BtcDrak authored this BIP document.
==References==
BIP 68: Consensus-enforced transaction replacement signalled via
sequence numbers
https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki
BIP 65: OP_CHECKLOCKTIMEVERIFY
https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
BIP XX: Median past block time for time-lock constraints
https://github.com/bitcoin/bips/blob/master/bip-00XX.mediawiki
HTLCs using OP_CHECKSEQUENCEVERIFY/OP_LOCKTIMEVERIFY and
revocation hashes
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-July/000021.html
==Copyright==
This document is placed in the public domain.

2023-06-07 19:33:41 CEST

- reply

📅 Original date posted:2015-08-10
📝 Original message:On Mon, Aug 10, 2015 at 12:55 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Gavin, I interpret the absence of response to these questions as a
> sign that everybody agrees that there's no other reason to increase
> the consensus block size other than to avoid minimum market fees from
> rising (above zero).
> Feel free to correct that notion at any time by answering the
> questions yourself.
> In fact if any other "big block size advocate" thinks there's more
> reason I would like to hear their reasons too.
Additionally, correct me if I am wrong, but the net effect from preventing
fees rising from zero would be to guarantee miners have no alternative
income from fees as block subsidy dries up and thus harm the incentives to
secure the chain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150810/1476e03a/attachment.html>

2023-06-07 17:49:21 CEST

- reply

2023-06-07 17:49:18 CEST

- reply

2023-06-07 17:49:15 CEST

- reply

2023-06-07 17:49:13 CEST

- reply

2023-06-07 17:48:24 CEST

- reply

📅 Original date posted:2015-08-21
📝 Original message:On Fri, Aug 21, 2015 at 11:55 AM, Yifu Guo via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> I like the intend of this attempt to bring more clarity to the blocksize
> debate, however it would be more help to make this a information site about
> the current outstanding BIPs and summarize their differences rather than
> voting mechanism.
> (ofcourse the author of the BIPs would "vote" for their own proposals.)
>
> It would be good to include supporting and counter statements regards to
> these BIPs on the site.
> in addition to highlight certain things like pools in china have voiced
> their opinion that increase should happen, and 8mb is something they are
> comfortable with, which is not directly related to a single BIP, but never
> the less relevant in this discussion.
I was rather surprised by the tweet from AntPool[1] today saying that
they support big blocks and would be prepared to upgrade to XT. Pools
have stated that they are willing to increase to a maximum of 8MB, but
upgrading to XT puts them on a schedule towards 8GB which is clearly
not what they have agreed to.
Do you have any insights into what's going on there?
Also do you have any insight into what Chinese pools would accept as a
compromise in terms of raising the blocksize limit?
Drak
[1] https://twitter.com/JihanWu/status/633288343338381314

2023-06-07 17:48:23 CEST

- reply

📅 Original date posted:2015-08-21
📝 Original message:On Fri, Aug 21, 2015 at 10:29 AM, Peter Todd via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> What might be valuable is to ask devs to explain what their threat models are, what should be at the root of their thinking about the blocksize.
That's exactly what the "Technical Opinion" column is for.

2023-06-07 17:48:22 CEST

- reply

📅 Original date posted:2015-08-21
📝 Original message:On Fri, Aug 21, 2015 at 6:10 AM, Nicolas Dorier via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
> Decision making is not the goal of this site, it is only a way to see
> various pros and cons of various devs on various proposals in a single
> place.
> This is for the community to have a coherent view about what you are talking
> about now spread into reddit/mailing/forums.
>
> If you did not analyzed a proposal yet, you don't have to fill out your
> opinion veto or approval.
> It is only to show what you would you "approve" and what you would "veto",
> after your analysis.
> Then point out all the discussions in the opinion section that lead you to
> your conclusion.
>
> You can change edit your position as you progress into your analysis and as
> new BIP get redacted.
> I'm eager to include the new proposals.
The most important part that developers should complete is the
"Technical Opinion" column section where they can explain their
general worldview, what their concerns are, how those concerns would
be alleviated. If one is undecided or does not have enough information
regarding each BIP then dont fill it out. That also helps signal the
level of consensus for a proposal.
As it stands at the moment, it's almost impossible to direct someone
at the opinion of a specific developer other than hunting down a few
gems scattered to the four corners of the universe. I tried recently
and it was simply impossible. At least with this system, specific BIPs
aside, we can easily see the view of each developer. I think most of
us can comment on BIP101 since the BIP appears non-negotiable.
The XT faction are easily winning the media war by obscuring rational
debate by high signal to noise ratio. Nicolas' solution means the most
important views expressed by each heavyweight will not get lost and
serve as a good reference point for everyone, including the media.
The site could be extended to include major stakeholders too like
major service providers (think exchanges, wallet providers etc) and
mining pools.

2023-06-07 17:48:21 CEST

- reply

2023-06-07 17:47:54 CEST

- reply

2023-06-07 17:47:32 CEST

- reply

2023-06-07 17:47:30 CEST

- reply

2023-06-07 17:47:24 CEST

- reply

📅 Original date posted:2015-08-17
📝 Original message:For the record I would like to share my technical analysis of the Satoshi
email which I wrote in a pastebin (http://pastebin.com/Ct5M8fa2) a few days
ago.
1. The email is the one used by Satoshi to announce Bitcoin in the first
place.
http://www.metzdowd.com/pipermail/cryptography/2008-October/014810.html
2. The email was not spoofed, it actually originated from vistomail's
server. The email headers show the email originated from 190.97.163.93 and
the SPF records show this as an authorised sender for the email. This does
not prove the account wasn't hacked of course, or that the account might
have expired and be re-registered by someone else (vistomail is a paid for
email provider).
3. While the email is not signed, and there are a number of PGP keys listed
on key servers for him (to vary addresses), he didnt sign any emails with
any PGP keys.
It is therefore not possible to outright dismiss the email's authenticity
as the email originates from an authentic source. The only questions is
whether the webmail service was hacked or commandeered somehow.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/14bc2afd/attachment.html>

2023-06-07 17:46:46 CEST

- reply

2023-06-07 17:45:48 CEST

- reply

2023-06-07 17:45:20 CEST

- reply

📅 Original date posted:2015-08-09
📝 Original message:I thought it's worth mentioning there is a specific Lightning Network
development mailing list at
http://lists.linuxfoundation.org/mailman/listinfo/lightning-dev and already
some pretty interesting explanations in the archives.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150809/73ecb74d/attachment-0001.html>

2023-06-07 17:39:32 CEST

- reply

📅 Original date posted:2015-06-21
📝 Original message:Thanks for all your hard work setting this up, and to everyone else
involved.
Drak
On Sun, Jun 21, 2015 at 10:29 PM, Warren Togami Jr. <wtogami at gmail.com>
wrote:
> Hi folks,
>
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> The move is now complete. The previous archive has been fully imported
> and new posts here will now be saved.
>
> *Greylisting Notice*
> Your first post to this list may be delayed by 5+ minutes due to
> Greylisting <https://en.wikipedia.org/wiki/Greylisting>. Subsequent posts
> should go through without delay. Contact Freenode #bitcoin-dev if you have
> any questions or concerns.
>
> *TODO*
>
> - LF will be upgrading Mailman soon to better handle posts from DKIM
> enforced domains.
> - There will be a few more config tweaks like auto-rejecting
> non-subscribed posts. Nobody has time to moderate this list, and mail
> silently disappearing into the moderation hold blackhole is worse than an
> instant reject message telling people to subscribe. Unfortunately, it is
> too dangerous to auto-reject spam ... those messages need to go into a
> blackhole to prevent bounce abuse.
>
> Warren Togami
>
>
>
> _______________________________________________
> 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/20150621/0a8bbc88/attachment.html>

2023-06-07 17:39:12 CEST

- reply

📅 Original date posted:2015-06-21
📝 Original message:Eric,
BitPay clearly do understand the risks of 0-conf. In case you were not
aware BitPay does not particularly "accept zero confirm transactions". When
a payment is seen on the network the payment screen reports the invoice has
been paid, but that's front-end user facing. On the back end it's marked as
paid but the API exposes the the confirmation status allowing the merchant
to make business decisions about when to progress to fulfilment. A good
example of this is Neteller (a sort of paypal variant) which allows one to
fund the account with fiat using Bitcoin, via Bitpay. When you pay the
bitpay invoice, your account is marked as payment pending until there are
some confirmations.
Coinbase does not expose the confirmation status and from what I understand
(not checked myself) they guarantee payment to merchants for 0-confirm,
regardless of whether they confirm or not.
I want to address something stated by Justus, that signing a payment
message and broadcasting somehow solidifies intent and going back on that
would be fraud. This seriously conflates cryptographic certainty with human
behaviour. For one, humans make mistakes all the time. We get tired, we get
distracted, we make copy paste errors. It's entirely possible on sends a
payment only to find it's been sent to the wrong address or the wrong
amount has been sent or the fee is wrong. Software may also misbehave
(Electrum for example has a weird UI glitch with fees where the specified
fee can be overwritten). r/bitcoin it littered with sad examples. What
ECDSA signing tells is that it was signed by your private key, but nothing
else. It does not say if *you* signed it, or that the message you signed
was correct.
On Sun, Jun 21, 2015 at 8:42 AM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>
> On Jun 20, 2015, at 11:45 PM, Jeff Garzik <jgarzik at bitpay.com> wrote:
>
> On Sat, Jun 20, 2015 at 5:54 PM, Eric Lombrozo <elombrozo at gmail.com>
> wrote:
>
>> but we NEED to be applying some kind of pressure on the merchant end to
>> upgrade their stuff to be more resilient
>>
>
> Can you be specific? What precise technical steps would you have BitPay
> and Coinbase do? We upgrade our stuff to... what exactly?
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc. https://bitpay.com/
>
>
> Thanks for asking *the* question, Jeff. We often get caught up in these
> philosophical debates…but at the end of the day we need something concrete.
>
> Even more important than the specific software you’re using is the
> security policy.
>
> If you must accept zero confirmation transactions, there are a few
> concrete things you can do to reduce your exposure:
>
> 1) limit the transaction amounts for zero confirmation transactions - do
> not accept them for very high priced goods…especially if they require
> physical shipping.
> 2) limit the total amount of unconfirmed revenue you’ll tolerate at any
> given moment - if the amount is exceeded, require confirmations.
> 3) give merchants of subscription services (i.e. servers, hosting, etc…)
> the ability to shut the user out if a double-spend is detected.
> 4) collect legal information on purchasers (or have the merchants collect
> this information) so you have someone to go after if they try to screw you
> 5) create a risk profile for users…and flag suspicious behavior (i.e.
> someone trying to purchase a bunch of stuff that totally doesn’t fit into
> their purchasing habits).
> 6) get insurance (although right now reasonably-priced insurance is
> probably pretty hard to obtain since statistics are generally of little
> use…we’re entering uncharted territory).
> 7) set up a warning system and a “panic” button so that if you start to
> see an attack you can immediately disable all zero confirmation
> transactions system-wide.
> 8) independently verify all inbound transactions and connect to multiple
> network nodes…check them against one another.
>
>
> As for software tools to accomplish these things, we can talk about that
> offline :)
>
>
> - Eric Lombrozo
>
>
>
>
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> 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/20150621/4abdd8ca/attachment.html>

2023-06-07 17:33:16 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 7:40 PM, Gavin Costin <slashdevnull at hotmail.com>
wrote:
> Can anyone opposed to this proposal articulate in plain english the worst
> case scenario(s) if it goes ahead?
>
> Some people in the conversation appear to be uncomfortable, perturbed,
> defensive etc about the proposal …. But I am not seeing specifics on why it
> is not a feasible plan.
>
See this response:
http://www.mail-archive.com/[email protected]/msg07462.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/7ec7417f/attachment.html>

2023-06-07 17:33:15 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 6:43 PM, Mike Hearn <mike at plan99.net> wrote:
>
> And I'll ask again. Do you have a *specific, credible alternative*?
> Because so far I'm not seeing one.
>
I think you are rubbing against your own presupposition that people must
find and alternative right now. Quite a lot here do not believe there is
any urgency, nor that there is an immanent problem that has to be solved
before the sky falls in.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/ae2e1450/attachment.html>

2023-06-07 17:33:06 CEST

- reply

📅 Original date posted:2015-05-07
📝 Original message:On Thu, May 7, 2015 at 10:25 AM, Mike Hearn <mike at plan99.net> wrote:
> What I don't see from you yet is a *specific and credible plan* that fits
> within the next 12 months and which allows Bitcoin to keep growing. Not
> some vague handwave like "let's all use the Lightning network" (which does
> not exist), or "let's do more research" (Gavin has done plenty of
> research), or "but what about the risks" (Bitcoin is full of risks). A
> plan, with dates attached, and a strong chance of actually being deployed
> in time.
>
Would you please explain where this 12 months timeframe comes from?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150507/55cd10b4/attachment.html>

2023-06-07 17:32:57 CEST

- reply

📅 Original date posted:2015-05-04
📝 Original message:On Mon, May 4, 2015 at 6:07 AM, Peter Todd <pete at petertodd.org> wrote:
> Matt Corallo brought up¹ the issue of OP_NOP scarcity on the mempool
> only CLTV pull-req²:
>
> "I like merging this, but doing both CLTV things in one swoop would be
> really nice. Certainly if we're gonna use one of the precious few
> OP_NOPs we have we might as well make it more flexible."
>
> [snip]
> That said, if people have strong feelings about this, I would be willing
> to make OP_CLTV work as follows:
>
> <nLockTime> 1 OP_CLTV
>
> Where the 1 selects absolute mode, and all others act as OP_NOP's. A
> future relative CLTV could then be a future soft-fork implemented as
> follows:
>
> <relative nLockTime> 2 OP_CLTV
>
> On the bad side it'd be two or three days of work to rewrite all the
> existing tests and example code and update the BIP, and (slightly) gets
> us away from the well-tested existing implementation. It also may
> complicate the codebase compared to sticking with just doing a Script
> v2.0, with the additional execution environment data required for v2.0
> scripts cleanly separated out. But all in all, the above isn't too big
> of a deal.
Adding a parameter to OP_CLTV makes it much more flexible and is the most
economic use of precious NOPs.
The extra time required is ok and it would be good to make this change to
the PR in time for the feature freeze.
Drak
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150505/677b8096/attachment.html>

2023-06-07 17:30:14 CEST

- reply

📅 Original date posted:2015-02-12
📝 Original message:On Thu, Feb 12, 2015 at 3:15 PM, Mike Hearn <mike at plan99.net> wrote:
> Peter argues that this is stable and makes unconfirmed transactions safe
>> because a fraudster can buy something, walk out of the shop, and broadcast
>> a double spend with a higher fee. But then the merchant can re-spend the
>> original payment back to themselves with an *even* higher fee than that.
>> Then the fraudster can re-spend their double spend with an *even* higher
>> fee than that, and so on back and forth, until *all* the money has been
>> spent to miner fees. Thus the merchant loses their goods but the fraudster
>> has still "paid" in some sense because they don't get the money either.
>>
>
> This argument makes no sense for two reasons.
>
> The first is that this setup means miners can steal arbitrary payments if
> they work together with the sender of the money. The model assumes this
> collaboration won't happen, but it will. Because no existing wallet has a
> "double spend this" button, to make the scheme work the dishonest miners
> must create and distribute such a wallet that implements the whole
> scorched-earth protocol. At that point it's easy for miners to reward the
> payment fraudster with some of the stolen money the merchant lost, meaning
> it now makes sense for the fraudster to always do this. The situation isn't
> stable at all.
>
> The second is that it incentivises competitors to engage in payment fraud
> against each other. A big rich coffee shop chain that is facing competition
> from a small, scrappy newcomer can simply walk into the new shop and buy
> things, then trigger the "scorched earth". Even with no miner
> collaboration, this means the big company is down the cost of the product
> *but* so is the little company who lost everything. Whoever can outspend
> the other wins.
>
I think that is a misdirection on your part. The point of replace-by-fee is
to make 0-confirms reliably unreliable. Currently people can "get away"
with 0-confirms but it's only because most people arent actively double
spending, and when they do it is for higher value targets. Double spend
attacks *are* happening a lot more frequently than is being admitted here,
according to Peter from work with various clients.
Like single address reuse, people have gotten used to something which is
bad. Generally accepting 0-conf is also a bad idea(tm) and instant
confirmation solutions should be sought elsewhere. There are already
interesting solutions and concepts: greenaddress for example, and
CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than
supporting and promoting risky 0-confirms, we need to spend time on better
alternative solutions that will work for everyone and not during the
honeymoon phase where attackers are fewer.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150212/13ef9edc/attachment.html>

2023-06-07 17:28:03 CEST

- reply

📅 Original date posted:2014-12-15
📝 Original message:This is a pretty good example about refactoring discipline as well as
premature/over optimisation.
We all want to see more modular code, but the first steps should just be to
relocate blocks of code so everything is more logically organised in
smaller files (especially for consensus critical code). Refactoring should
come in a second wave preferably after a stable release. Refactoring should
be in the pure sense, optimising code with absolutely no change in
behaviour.
When it comes to actual API changes, I think we need to be a lot more
careful and should be considered feature requests and get a lot more
scrutiny as we are essentially breaking backwards compatibility. #4890 was
pretty much merged with no discussion or thought yet other really simple
and uncontroversial PRs remain unmerged for months. A key question in the
case of EvalScript() would have been, "why are we passing txTo and nIn
here, and are there any future use cases that might require them? Why
should this be removed from the API and the entire method signature
changed?". BC breaks always need strong justification.
So I've expressed my concern a few times about the speed and frequency of
refactoring and also the way it's being done. I am not alone, as others not
directly connected with the Bitcoin Core project have also expressed
concerns about the number of refactorings "for the sake of refactoring",
especially of consensus critical code. Careful as we may be, we know from
history that small edge case bugs can creep in very easily and cause a lot
of unforeseen problems.
BtcDrak
On Mon, Dec 15, 2014 at 12:47 PM, Peter Todd <pete at petertodd.org> wrote:
>
> BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a
> few
> days ago and found a fairly large design change that makes merging it
> currently
> impossible. Pull-req #4890², specifically commit c7829ea7, changed the
> EvalScript() function to take an abstract SignatureChecker object,
> removing the
> txTo and nIn arguments that used to contain the transaction the script was
> in
> and the txin # respectively. CHECKLOCKTIMEVERIFY needs txTo to obtain the
> nLockTime field of the transaction, and it needs nIn to obtain the
> nSequence of
> the txin.
>
> We need to fix this if CHECKLOCKTIMEVERIFY is to be merged.
>
> Secondly, that this change was made, and the manner in which is was made,
> is I
> think indicative of a development process that has been taking significant
> risks with regard to refactoring the consensus critical codebase. I know I
> personally have had a hard time keeping up with the very large volume of
> code
> being moved and changed for the v0.10 release, and I know BtcDrak - who is
> keeping Viacoin up to date with v0.10 - has also had a hard time giving the
> changes reasonable review. The #4890 pull-req in question had no ACKs at
> all,
> and only two untested utACKS, which I find worrying for something that made
> significant consensus critical code changes.
>
> While it would be nice to have a library encapsulating the consensus code,
> this
> shouldn't come at the cost of safety, especially when the actual users of
> that
> library or their needs is still uncertain. This is after all a
> multi-billion
> project where a simple fork will cost miners alone tens of thousands of
> dollars
> an hour; easily much more if it results in users being defrauded. That's
> also
> not taking into account the significant negative PR impact and loss of
> trust. I
> personally would recommend *not* upgrading to v0.10 due to these issues.
>
> A much safer approach would be to keep the code changes required for a
> consensus library to only simple movements of code for this release, accept
> that the interface to that library won't be ideal, and wait until we have
> feedback from multiple opensource projects with publicly evaluatable code
> on
> where to go next with the API.
>
> 1) https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki
> 2) https://github.com/bitcoin/bitcoin/pull/4890
>
> --
> 'peter'[:-1]@petertodd.org
> 00000000000000001b18a596ecadd07c0e49620fb71b16f9e41131df9fc52fa6
>
>
> ------------------------------------------------------------------------------
> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
> from Actuate! Instantly Supercharge Your Business Reports and Dashboards
> with Interactivity, Sharing, Native Excel Exports, App Integration & more
> Get technology previously reserved for billion-dollar corporations, FREE
>
> http://pubads.g.doubleclick.net/gampad/clk?id=164703151&iu=/4140/ostg.clktrk
> _______________________________________________
> 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/20141215/d2a843f5/attachment.html>

2023-06-07 17:26:31 CEST

- reply

📅 Original date posted:2014-10-15
📝 Original message:On Wed, Oct 15, 2014 at 4:54 PM, Adam Back <adam at cypherspace.org> wrote:
> please not google groups *, I'd vote for sourceforge or other simple
> open list software over google groups.
>
Please not sourceforge.
> * 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.
Mailman is good enough...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20141015/df10eb73/attachment.html>