Oliver Petruzel [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-08-27 to 2017-06-03
💬 Posted a total of 8 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 18:02:20

- reply

📅 Original date posted:2017-06-03
📝 Original message:>>2.1MB capacity in August via segwit, with 4MB weight, and 4.2MB capacity
in December with 8MB<<
I'm not sure how many people to not of the draft BIP I submitted to the
list in early April. It was essentially a combination of Gavin's BIP 109,
Adam's 2-4-8 idea, and something I added to SegWit that I call "Discount
Governing."
It basically takes the idea of gradual increases one step farther: a
gradual increase of both the Total weight and SegWit discount rate over a
period of X years (a schedule of Flag Day + X blocks increases).
Would this be something that some in the dev community might consider
if/when SegWit is combined with a block increase?
Original draft here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/
2017-April/013984.html
Ollie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170603/e570a003/attachment.html>

2023-06-07 18:02:19

- reply

📅 Original date posted:2017-06-02
📝 Original message:>>>Take a quick look at the COOP proposal...it gets us to 4mb blocks in 4
years....gradually, no massive fee swings.<<<
How is that captured in the COOP BIP? I can see Luke's 2MB cap referenced
in the BIP, but I don't see anything in the text that would indicate a
gradual increase of any sort.
As someone who has previously written a BIP draft to accomplish a gradual
increase with SegWit, I'd be very interested in seeing what approach
they've chosen.
Ollie
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170602/6b040040/attachment.html>

2023-06-07 18:01:59

- reply

📅 Original date posted:2017-05-29
📝 Original message:>>if the community wishes to adopt (by unanimous consensus) a 2 MB block
size hardfork, this is probably the best way to do it right now... Legacy
Bitcoin transactions are given the witness discount, and a block size limit
of 2 MB is imposed.<<
The above decision may quickly become very controversial. I don't think it's
what most users had/have in mind when they discuss a "2MB+SegWit" solution.
With the current 1MB+SegWit, testing has shown us that normal usage results
in ~2 or 2.1MB blocks.
I think most users will expect a linear increase when Base Size is
increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
With normal usage, the expected results would then be ~4 or 4.2MB blocks.
Am I missing something here, or does Luke's suggested 2MB cap completely
nullify that expected linear increase? If so, why? What's the logic behind
this decision?
I'd love to be armed with a good answer should my colleagues ask me the
same obvious question, so thank you ahead of time!
Respectfully,
Oliver Petruzel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170529/069bfb26/attachment.html>

2023-06-07 17:59:27

- reply

📅 Original date posted:2017-04-06
📝 Original message:> > One of the things going for us here is that Bitmain has been keeping
ASICBOOST
> > from their own customers - as far as we know they haven't been sharing
it, and
> > thus they're the only ones you can actually use it.
> >
> > So while we're pissing off Bitmain in disabling it, we wouldn't be
affecting
> > anyone else.
> >
> > Equally, mining is a zero-sum game: if no-one can use ASICBOOST, miners
are in
> > the same position as before. ASICBOOST is only relevant to miners like
Bitmain
> > who have access to it while other miners don't.
Peter -
Do we know that for a fact, though? What evidence or intelligence do we
have to indicate Bitmain itself is the only entity using the covert boost?
A few possibilities:
1. They could have already shared it with a limited number of strategic
partners;
2. They could have offered to share it with various parties in exchange for
something (money, support for BU, etc); or
3. They could provide the custom firmware/software to select parties as a
direct response to this disclosure -- which would enhance their defenses
against a soft fork.
4. They could share the firmware/software with EVERY owner of their
equipment in a last-ditch defense against a soft fork. (after all, some
advantage over other equipment manufacturers is still better than no
advantage, right?)
Assumptions could lead to failure, so these are just some things to keep in
mind.
Respectfully,
Oliver
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170406/eb744e90/attachment.html>

2023-06-07 17:59:27

- reply

2023-06-07 17:59:09

- reply

📅 Original date posted:2017-04-05
📝 Original message:Evening all,
The following BIP submission summarizes an idea that I've been tossing
around for the last year. I understand that there may be nuances to SegWit
and current consensus layer mechanisms that I may not fully understand, so
please do not hesitate to shred the following text to pieces (I can handle
it, I promise!).
Please note that this BIP assumes failure of the current softfork version
of SegWit to activate in November -- something that I personally do not
wish to see(!). However, given the real possibility of that happening, or
perhaps just some newfound willingness (by "the community") to support a
hardfork in lieu of a stalemate, I figure now is as good a time as any to
share the idea in black and white.
I would really appreciate any/all feedback from the dev community on the
technical merits (read: feasibility) of the idea. I would especially
appreciate feedback from the SegWit developers who designed the current
implementation in 0.14, as they likely have the most intimate knowledge of
SegWit's nuances, and the entire BIP below would likely rely on their
willingness to develop a hardfork version.
Nothing in this BIP is set in stone -- including all values and timelines
-- but, I do hope the following text effectively captures the gist of the
idea, and I do thank you ahead of time for your consideration of the
proposal.
Respectfully,
Oliver Petruzel
-------------------------------------------------------------------------------
BIP: TBD
Layer: Consensus (hard fork)
Title: Base Size Increase and Segregated Witness with Discount Governors
(SW-DGov) Hardfork
Author: Oliver Petruzel <opetruzel at gmail.com>
Comments-Summary: No comments yet.
Comments-URI:
Status: Draft
Type: Standards Track
Created: 2017-04-05
License: PD
Abstract
This BIP proposes a method of combining an immediate base size increase to
2MB and a hardfork version of Segregated Witness (SegWit). The SegWit
portion of the hardfork will leverage Discount Governors to control (or
“govern”) the pace of the increase over a period of 145,152 blocks
(approximately three (3) years).
Motivation
Given the possibility of the current softfork version of SegWit failing to
activate in November 2017, this BIP aims to provide a hardfork alternative
that would provide every user in the ecosystem with the fixes and changes
they need to move forward with other great projects, while also tightly
controlling the rate at which the total weight of blocks increases during
the next three years. The predictable nature of the increases will provide
miners, full node operators, and other users of the system with the ability
to plan their development, resources, and operations accordingly. The
fixed nature of the increases will also allow all full nodes to maintain a
fixed set of rules for block validity (consensus).
Specification
The following changes will be made to the client:
* An immediate increase of base size to 2,000,000 bytes (perhaps leveraging
code changes similar to those described in BIP 109).
· A hardfork version of SegWit that maintains all of the fixes present in
the softfork version, including (but not limited to):
- Fix for the Malleability issue
- Linear scaling of sighash operations
- Signing of input values
- Increased security for multisig via pay-to-script-hash (P2SH)
- Script versioning
- Reducing UTXO growth
- Moving towards a single combined block limit
* In addition to those fixes listed above, the hardfork version of SegWit
will include the following:
- Rather than using the fixed (75%) Discount found in the softfork version
of SegWit, the hardfork version will leverage Discount Governing to control
the pace of total block weight increases over a three (3) year period of
time. The use of Discount Governors will allow a steady increase over that
period from an immediate 2MB to 8MB total. There are several ways these
increases can be handled – either by hardcoding the scheduled increases in
the initial hardfork, or perhaps using subsequent softforks (additional
input/discussion needed on the best way to handle the increases.
- Example increase schedule: +12.5% every 24,192 blocks (roughly every six
(6) months). The increases would cap at the same 75% Discount rate found
in the current softfork version of SegWit.
- Each time the Discount increases – every 24,192 blocks -- the Total Block
Weight value would also increase to appropriately compensate for the added
Discount.
Rationale
This hardfork employs a simple flag day deployment based on the median
timestamp of previous blocks. Beyond this point, supporting nodes will not
accept blocks with original rules. This ensures a deterministic and
permanent departure with the original rules.
The use of Discount Governors to control the pace of the increase will
result in a predictable and stable increase over the period of three (3)
years.
If, at any time, the increases present problems for the network -- such as
centralization concerns, negative impacts on the fee market(s), or other
unforeseen problems -- a softfork could be leveraged to halt the increases.
The pace of the increases is described using the following table:
Time -- Base Size (bytes) -- Total Discount -- Total Block Weight (bytes)
Flag Day (FD) -- 2,000,000 -- 0.00% -- 2,000,000
FD+24,192 Blocks -- 2,000,000 -- 12.5% -- 2,285,715
FD+48,384 Blocks -- 2,000,000 -- 25.0% -- 2,666,667
FD+72,576 Blocks -- 2,000,000 -- 37.5% -- 3,200,000
FD+96,768 Blocks -- 2,000,000 -- 50.0% -- 4,000,000
FD+120,960 Blocks -- 2,000,000 -- 62.5% -- 5,333,334
FD+145,152 Blocks -- 2,000,000 -- 75.0% -- 8,000,000
Based on the above, the "effective blocksize increase," or the number of
transactions per block, will also scale with each Discount increase.
Compatibility
This proposal requires a hardfork that does not maintain compatibility with
previous clients and rules for consensus. It should not be deployed
without widespread consensus.
Wallet software and other applications will also need to be upgraded to
maintain compatibility.
The hardfork Flag Day will need to be coordinated/determined during the
development and testing stages for the hardfork – estimated at 9-12 months
to ensure a safe rollout of the hardfork to all network participants.
Reference implementation
TBD
Copyright
This document is placed in the public domain.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170405/a8eeaf5b/attachment.html>

2023-06-07 17:39:23

- reply

📅 Original date posted:2015-09-03
📝 Original message:I agree with Simon's sentiments for question #1, and was actually going to
pose the same question. Non-votes seem like they may poison the well
mathematically, and counting them anyway seems to encourage a lack of
participation at a time when miners really need to be very much involved.
Since we're handing them even more control over the ecosystem with this
BIP, it would be nice to ensure they (all miners) seriously consider their
impact and role on a regular basis.
I'm curious why we couldn't/shouldn't simply drop the non-votes. (There may
be a great reason that I can't think of, but it's eluding me... LOL)
That said, I don't see any issue with counting votes from outside of the
range as the maximum/minimum accordingly (Simon's question #2). In fact,
such votes would be very interesting (worthy of further discussion) if they
begin to lean heavily in either direction.
V/r,
Oliver
On Sep 3, 2015 3:41 PM, "Simon Liu via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Jeff,
>
> Thoughts on this part of the proposal:
>
> "Absent/invalid votes are counted as votes for the current hardLimit.
> Out of range votes are counted as the nearest in-range value."
>
> 1. Why should an absent vote be considered a vote for the status quo? A
> non-voter should have zero impact on the result.
>
> 2. Why should out of range votes be counted? They're an invalid vote, a
> spoiled ballot as such, and thus it would be better if they were discarded.
>
> Regards,
> Simon
>
>
> On 09/02/2015 08:33 PM, Jeff Garzik via bitcoin-dev wrote:
> > BIP 100 initial public
> > draft: https://github.com/jgarzik/bip100/blob/master/bip-0100.mediawiki
> >
> > Emphasis on "initial" This is a starting point for the usual open
> > source feedback/iteration cycle, not an endpoint that Must Be This Way.
> >
> >
> >
> >
> > _______________________________________________
> > 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/20150903/1ab14fff/attachment.html>

2023-06-07 17:38:46

- reply

📅 Original date posted:2015-08-31
📝 Original message:>>>I would be OK with $100 transaction fee
Unless you're relying upon some hypothetical hyper-inflation of the USD,
how does one accept or justify such fees given the title (and intentions)
of Satoshi's own white paper and corresponding software?
I believe the key words "cash system" must be kept in mind throughout all
of these discussions and developments, or else we risk turning Bitcoin into
something other than cash.
Bitcoin will no longer be a P2P cash system if the fees make transactions
prohibitively expensive for all but the wealthiest of individuals and
corporations.
I understand that a careful balance must be struck between (measurable?)
decentralization and Bitcoin's use as an actual cash system; however, those
who are willing to annihilate the latter to maintain ONLY the former must
at least be honest with everyone that they really don't care if Bitcoin
becomes something entirely different than Satoshi's original invention and
intention.
Call it a necessary transformation or reinvention, and by a new name, if
you will; because, with exorbitant fees, it may no longer be accurate or
appropriate to call it Bitcoin: A Peer-to-peer Electronic CASH System.
Respectfully,
Oliver
On Aug 30, 2015 2:38 AM, "Adam Ritter via bitcoin-dev" <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I don't really see any problem with the paper:
> All it states is that having the assumption that miners don't
> centralize, transaction fees don't go to zero even without the
> blocksize limit. I think we can accept this as a nice academic
> research, and I believe that it's true.
> Still, it doesn't have anything that is practical for me as an user of
> the Bitcoin network (I use it for storing long-term purchase value, as
> most of the people who I know): it doesn't help me if I still need to
> pay transaction fees after the blocksize limit is gone. My (and other
> users') main concern is about centralization, which has nothing to do
> with transaction fees. I would be OK with $100 transaction fee as
> well, as long as the network is fair and secure (which comes from
> decentralization).
> _______________________________________________
> 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/20150831/d557c458/attachment-0001.html>

2023-06-07 17:38:19

- reply

📅 Original date posted:2015-08-27
📝 Original message:>>>But money is attached to life and not liberty
I can't truly express in this email exactly how much I personally disagree
with that statement/belief because I don't think the dev mailing list is
the appropriate forum for such philosophical discussions.
I will say this, though: I think you've missed much of the point of Bitcoin
-- which "monetary or economic liberty" might perfectly describe -- and, I
sincerely hope that proposals such as yours never gain ANY traction in this
community.
As far as I'm concerned, your ideas are the antithesis of this entire
experiment.
I'd be glad to have this discussion over a beer and hookah any time, but I
won't take up any more space or time with it here.
Oliver
PS: sorry everyone! I just couldn't let this one go without comment... I'll
go back to my usual lurking and learning now. :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150827/ccb73df4/attachment.html>

2023-06-07 17:38:19

- reply