Alphonse Pace [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2017-03-07 to 2017-05-08
💬 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:00:56

- reply

📅 Original date posted:2017-05-08
📝 Original message:Sergio,
I'm not sure what the data you present has to do with the discount. A 75%
discount prevents witness spam precisely because it is 75%, nothing more.
The current usage simply gives a guideline on how much capacity is gained
through a particular discount. With the data you show, it would imply that
those blocks, with SegWit used where possible, would result in blocks of
~1.8MB.
On Mon, May 8, 2017 at 5:42 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I have processed 1000 blocks starting from Block #461653.
>
> I computed several metrics, including the supposed size of witness data
> and non-witness data (onchain), assuming all P2SH inputs/outputs are
> converted to P2PWSH and all P2PKH inputs/outputs are converted to P2WPKH.
>
> This takes into account that other types of transactions will not be
> modified by Segwit (e.g. OP_RETURN outputs, or P2PK). This analysis doesn't
> take into account that LN transactions may affect the current state,
> increasing the segwit/nosegwit ratio.
>
> Among a lot of information, I've got the following real world results...
>
> acMainChainSpace =352608924
> acSegwitSpace =599400403
> Ratio segwit/nosegwit=1.6999
>
> This implies that the 75% that discount is not the best option to prevent
> witness spam in a block of 4 MB, as stated in https://segwit.org/why-a-
> discount-factor-of-4-why-not-2-or-8-bbcebe91721e.
>
> The non-witness data weight factor should not be 4 but 2.35. The closest
> integer value is 2, which leads to a 50% witness discount.
>
> The Bitcoinj source code is available for anyone to review. I encourage
> anyone to re-compute this with another utility to cross-check. Maybe
> Antoine Le Calvez (p2sh.info) would like to double-check.
>
>
>
>
>
>
> _______________________________________________
> 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/20170508/eda3ff72/attachment.html>

2023-06-07 18:00:13

- reply

📅 Original date posted:2017-04-20
📝 Original message:A WTXID commitment would (likely) need to be a UASF.
On Wed, Apr 19, 2017 at 11:17 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The "UASF movement" seems a bit premature to me - I doubt UASF will be
> necessary if a WTXID commitment is tried first. I think that should be
> first-efforts focus.
>
> On Sat, Apr 15, 2017 at 2:50 PM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Sat, Apr 15, 2017 at 1:42 PM, Mark Friedenbach via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> triggering BIP141 activation, and therefore not enabling the new
>>> consensus rules on already deployed full nodes. BIP148 is making an
>>> explicit choice to favor dragging along those users which have upgraded to
>>> BIP141 support over those miners who have failed to upgrade.
>>>
>>
>> I do not follow the argument that a critical design feature of a
>> particular "user activated soft fork" could be that it is users don't need
>> to be involved. If the goal is user activation I would think that the
>> expectation would be that the overwhelming majority of users would be
>> upgrading to do it, if that isn't the case, then it isn't really a user
>> activated softfork-- it's something else.
>>
>>
>>> On an aside, I'm somewhat disappointed that you have decided to make a
>>> public statement against the UASF proposal. Not because we disagree -- that
>>> is fine -- but because any UASF must be a grassroots effort and
>>> endorsements (or denouncements) detract from that.
>>>
>>
>> So it has to be supported by the public but I can't say why I don't
>> support it? This seems extremely suspect to me.
>>
>>
>>
>> _______________________________________________
>> 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/20170420/311c5641/attachment.html>

2023-06-07 17:58:13

- reply

📅 Original date posted:2017-03-28
📝 Original message:His demand (not suggestion) allows it without any safeguards.
>This patch must be in the immediate next release of Bitcoin Core.
That is not a suggestion.
Wang - still waiting on the details of this meeting. In the spirit of
openness, I think you ought to share with the community what kind of secret
meetings are happening.
On Tue, Mar 28, 2017 at 3:43 PM, Tom Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tuesday, 28 March 2017 21:56:49 CEST Paul Iverson via bitcoin-dev wrote:
> > It is clear that, spam aside, blocks are getting full and we need
> increase
> > them soon. What I don't like about your proposal is it forces all node
> > operators to implicitly accept larger blocks in 2020, even maybe against
> > their will. 32 MB blocks might result in a loss of decentralization, and
> > it might be too difficult to coordinate for small blocks before it's too
> > late.
>
> The suggestion was not to produce 32MB blocks, so your fear here is
> unfounded.
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> 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/20170328/a84076b1/attachment.html>

2023-06-07 17:58:08

- reply

📅 Original date posted:2017-03-28
📝 Original message:Juan,
I suggest you take a look at this paper:
http://fc16.ifca.ai/bitcoin/papers/CDE+16.pdf It may help you form
opinions based in science rather than what appears to be nothing more than
a hunch. It shows that even 4MB is unsafe. SegWit provides up to this
limit.
8MB is most definitely not safe today.
Whether it is unsafe or impossible is the topic, since Wang Chun proposed
making the block size limit 32MiB.
Wang Chun,
Can you specify what meeting you are talking about? You seem to have not
replied on that point. Who were the participants and what was the purpose
of this meeting?
-Alphonse
On Tue, Mar 28, 2017 at 12:33 PM, Juan Garavaglia <jg at 112bit.com> wrote:
> Alphonse,
>
>
>
> In my opinion if 1MB limit was ok in 2010, 8MB limit is ok on 2016 and
> 32MB limit valid in next halving, from network, storage and CPU perspective
> or 1MB was too high in 2010 what is possible or 1MB is to low today.
>
>
>
> If is unsafe or impossible to raise the blocksize is a different topic.
>
>
> Regards
>
>
>
> Juan
>
>
>
>
>
> *From:* bitcoin-dev-bounces at lists.linuxfoundation.org [mailto:
> bitcoin-dev-bounces at lists.linuxfoundation.org] *On Behalf Of *Alphonse
> Pace via bitcoin-dev
> *Sent:* Tuesday, March 28, 2017 2:24 PM
> *To:* Wang Chun <1240902 at gmail.com>; Bitcoin Protocol Discussion <
> bitcoin-dev at lists.linuxfoundation.org>
> *Subject:* Re: [bitcoin-dev] Hard fork proposal from last week's meeting
>
>
>
> What meeting are you referring to? Who were the participants?
>
>
>
> Removing the limit but relying on the p2p protocol is not really a true
> 32MiB limit, but a limit of whatever transport methods provide. This can
> lead to differing consensus if alternative layers for relaying are used.
> What you seem to be asking for is an unbound block size (or at least
> determined by whatever miners produce). This has the possibility (and even
> likelihood) of removing many participants from the network, including many
> small miners.
>
>
>
> 32MB in less than 3 years also appears to be far beyond limits of safety
> which are known to exist far sooner, and we cannot expect hardware and
> networking layers to improve by those amounts in that time.
>
>
>
> It also seems like it would be much better to wait until SegWit activates
> in order to truly measure the effects on the network from this increased
> capacity before committing to any additional increases.
>
>
>
> -Alphonse
>
>
>
>
>
>
>
> On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> I've proposed this hard fork approach last year in Hong Kong Consensus
> but immediately rejected by coredevs at that meeting, after more than
> one year it seems that lots of people haven't heard of it. So I would
> post this here again for comment.
>
> The basic idea is, as many of us agree, hard fork is risky and should
> be well prepared. We need a long time to deploy it.
>
> Despite spam tx on the network, the block capacity is approaching its
> limit, and we must think ahead. Shall we code a patch right now, to
> remove the block size limit of 1MB, but not activate it until far in
> the future. I would propose to remove the 1MB limit at the next block
> halving in spring 2020, only limit the block size to 32MiB which is
> the maximum size the current p2p protocol allows. This patch must be
> in the immediate next release of Bitcoin Core.
>
> With this patch in core's next release, Bitcoin works just as before,
> no fork will ever occur, until spring 2020. But everyone knows there
> will be a fork scheduled. Third party services, libraries, wallets and
> exchanges will have enough time to prepare for it over the next three
> years.
>
> We don't yet have an agreement on how to increase the block size
> limit. There have been many proposals over the past years, like
> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
> on. These hard fork proposals, with this patch already in Core's
> release, they all become soft fork. We'll have enough time to discuss
> all these proposals and decide which one to go. Take an example, if we
> choose to fork to only 2MB, since 32MiB already scheduled, reduce it
> from 32MiB to 2MB will be a soft fork.
>
> Anyway, we must code something right now, before it becomes too late.
> _______________________________________________
> 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/20170328/70199439/attachment.html>

2023-06-07 17:58:01

- reply

📅 Original date posted:2017-03-28
📝 Original message:What meeting are you referring to? Who were the participants?
Removing the limit but relying on the p2p protocol is not really a true
32MiB limit, but a limit of whatever transport methods provide. This can
lead to differing consensus if alternative layers for relaying are used.
What you seem to be asking for is an unbound block size (or at least
determined by whatever miners produce). This has the possibility (and even
likelihood) of removing many participants from the network, including many
small miners.
32MB in less than 3 years also appears to be far beyond limits of safety
which are known to exist far sooner, and we cannot expect hardware and
networking layers to improve by those amounts in that time.
It also seems like it would be much better to wait until SegWit activates
in order to truly measure the effects on the network from this increased
capacity before committing to any additional increases.
-Alphonse
On Tue, Mar 28, 2017 at 11:59 AM, Wang Chun via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I've proposed this hard fork approach last year in Hong Kong Consensus
> but immediately rejected by coredevs at that meeting, after more than
> one year it seems that lots of people haven't heard of it. So I would
> post this here again for comment.
>
> The basic idea is, as many of us agree, hard fork is risky and should
> be well prepared. We need a long time to deploy it.
>
> Despite spam tx on the network, the block capacity is approaching its
> limit, and we must think ahead. Shall we code a patch right now, to
> remove the block size limit of 1MB, but not activate it until far in
> the future. I would propose to remove the 1MB limit at the next block
> halving in spring 2020, only limit the block size to 32MiB which is
> the maximum size the current p2p protocol allows. This patch must be
> in the immediate next release of Bitcoin Core.
>
> With this patch in core's next release, Bitcoin works just as before,
> no fork will ever occur, until spring 2020. But everyone knows there
> will be a fork scheduled. Third party services, libraries, wallets and
> exchanges will have enough time to prepare for it over the next three
> years.
>
> We don't yet have an agreement on how to increase the block size
> limit. There have been many proposals over the past years, like
> BIP100, 101, 102, 103, 104, 105, 106, 107, 109, 148, 248, BU, and so
> on. These hard fork proposals, with this patch already in Core's
> release, they all become soft fork. We'll have enough time to discuss
> all these proposals and decide which one to go. Take an example, if we
> choose to fork to only 2MB, since 32MiB already scheduled, reduce it
> from 32MiB to 2MB will be a soft fork.
>
> Anyway, we must code something right now, before it becomes too late.
> _______________________________________________
> 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/20170328/ce012e4a/attachment.html>

2023-06-07 17:57:50

- reply

📅 Original date posted:2017-03-26
📝 Original message:As a user, I would far prefer a split over any kind of mandatory change
that would drastically harm the ecosystem. Many users feel the same way.
Level 3 is a pure attack on users who do not conform to your beliefs.
Please do not put words in people's mouths claiming they wouldn't prefer a
split when many would. If you wish to fork off, please do so responsibly.
-Alphonse
On Sun, Mar 26, 2017 at 2:05 PM, Peter R via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hello Alex,
>
> Thank you for the thoughtful reply.
>
> Surely you are aware that what you are proposing is vastly different from
> the way soft forks have historically worked.
>
>
> Yes, it is different. It’s different because the future network upgrade
> to larger blocks includes a loosening of the consensus ruleset whereas
> previous upgrades have included a tightening of the rule set. (BTW—this is
> not my proposal, I am describing what I have recently learned through my
> work with Bitcoin Unlimited and discussions with miners and businesses).
>
> With a tightening of the rule set, a hash power minority that has not
> upgraded will not produce a minority branch; instead they will simply have
> any invalid blocks they produce orphaned, serving as a wake-up call to
> upgrade.
>
> With a loosening of the consensus rule set, the situation is different: a
> hash power minority that has not upgraded will produce a minority branch,
> that will also drag along non-upgraded node operators, leading to potential
> confusion. The idea behind orphaning the blocks of non-upgraded miners was
> to serve as a wake-up call to upgrade, to reduce the chances of a minority
> chain emerging in the first place, similar to what happens automatically
> with a soft-forking change. If one's worry is a chain split, then this
> seems like a reasonable way to reduce the chances of that worry
> materializing. The Level 3 anti-split protection takes this idea one step
> further to ensure that if a minority branch does emerge, that transactions
> cannot be confirmed on that branch.
>
> First of all, the bar for miners being on the new chain is extremely high,
> 95%.
>
>
> I’m very confident that most people do NOT want a split, especially the
> miners. The upgrade to larger blocks will not happen until miners are
> confident that no minority chain will survive.
>
> Second of all, soft forks make rule restrictions on classes of
> transactions that are already non-standard so that any non-upgraded miners
> are unlikely to be including txs in their blocks which would violate the
> new rules and should not have their blocks orphaned even after the fork.
>
>
> I agree that the soft-fork mechanism usually works well. I believe this
> mechanism (or perhaps a modified version of it) to increase the block size
> limit will likewise work well. All transactions types that are currently
> valid will be valid after the upgrade, and no new types of transactions are
> being created. The “block-size-limit gene" of network nodes is simply
> evolving to allow the network to continue to grow in the way it has always
> grown. (If you’re interested, here is my talk at Coinbase where I discuss
> this: https://www.youtube.com/watch?v=pWnFDocAmfg)
>
> Finally, soft forks are designed to only be used when there is a very wide
> community consensus and the intention is not to overrule anyone's choice to
> remain on the old rules but to ensure the security of nodes that may have
> neglected to upgrade. Obviously it is impossible to draw a bright line
> between users who intentionally are not upgrading due to opposition and
> users that are just being lazy. But in the case of a proposed BU hard fork
> it is abundantly clear that there is a very significant fraction, in fact
> likely a majority of users who intentionally want to remain on the old
> rules.
>
>
> My read is completely different. I still have never talked with a person
> in real life who doesn’t want the block size limit to increase. Indeed, I
> have met people who worry that Bitcoin Unlimited is “trying to take
> over”—and thus they are worried for other reasons—but this couldn’t be
> further from the truth. For example, what most people within BU would love
> to see is a simple patch to Bitcoin Core 0.14 that allows node operators to
> adjust the size of blocks their nodes will accept, so that these node
> operators can follow consensus through the upgrade if they choose to.
>
> This is not a fight about “Core vs. BU”; Bitcoin’s future is one of
> “genetic diversity” with multiple implementations, so that a bug in one
> doesn’t threaten the network as a whole. To me it seems this is largely a
> fight about whether node operators should be easily able to adjust the size
> of blocks their nodes accept. BU makes it easy for node operators to
> accept larger blocks; Core doesn’t believe users should have this power
> (outside of recompiling from source, which few users can do).
>
> As a Bitcoin user I find it abhorrent the way you are proposing to
> intentionally cripple the chain and rules I want to use instead of just
> peacefully splitting.
>
>
> Once again, this is not my proposal. I am writing about what I have come
> to learn over the past several weeks. When I first heard about these
> ideas, I was initially against them too. They seemed harsh and merciless.
> It wasn’t until I got out their and started talking to more people in the
> community that the rationale started to make sense to me: the biggest
> concern people had was a chain split!
>
> So I guess the “ethics” here depend on the lens through which one is
> looking. People who believe that an important outcome of the upgrade to
> larger blocks is to avoid a blockchain split may be more favourable to
> these ideas than people who want the upgrade to result in a split (or are
> OK with a split), as it sounds like you do (is this true that you’d rather
> split than accept blocks with more than 1,000,000 bytes of transaction
> information in them? Sorry if I misunderstood).
>
> But if one's intention is to split and not follow the majority hash power
> when blocks become larger, then why not change the proof-of-work? This
> would certainly result in a peaceful splitting, as you said you desire.
>
> Best regards,
> Peter R
>
>
>
>
> On Sat, Mar 25, 2017 at 3:28 PM, Peter R via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> One of the purported benefits of a soft-forking change (a tightening of
>> the consensus rule set) is the reduced risk of a blockchain split compared
>> to a loosening of the consensus rule set. The way this works is that
>> miners who fail to upgrade to the new tighter ruleset will have their
>> non-compliant blocks orphaned by the hash power majority. This is a strong
>> incentive to upgrade and has historically worked well. If a minority
>> subset of the network didn’t want to abide by the new restricted rule set,
>> a reasonable solution would be for them to change the proof-of-work and
>> start a spin-off from the existing Bitcoin ledger (
>> https://bitcointalk.org/index.php?topic=563972.0).
>>
>> In the case of the coming network upgrade to larger blocks, a primary
>> concern of both business such as Coinbase and Bitpay, and most miners, is
>> the possibility of a blockchain split and the associated confusion, replay
>> risk, etc. By applying techniques that are known to be successful for
>> soft-forking changes, we can likewise benefit in a way that makes a split
>> less likely as we move towards larger blocks. Two proposed techniques to
>> reduce the chances of a split are:
>>
>> 1. That miners begin to orphan the blocks of non-upgraded miners once a
>> super-majority of the network hash power has upgraded. This would serve as
>> an expensive-to-ignore reminder to upgrade.
>>
>> 2. That, in the case where a minority branch emerges (unlikely IMO),
>> majority miners would continually re-org that minority branch with empty
>> blocks to prevent transactions from confirming, thereby eliminating replay
>> risk.
>>
>> Just like after a soft forking change, a minority that does not want to
>> abide by the current ruleset enforced by the majority could change the
>> proof-of-work and start a spin-off from the existing Bitcoin ledger, as
>> suggested by Emin.
>>
>> Best regards,
>> Peter R
>>
>>
>> > On Mar 25, 2017, at 9:12 AM, CANNON via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>> >
>> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote:
>> >> I don't know what "Time is running short I fear" stands for and when
>> 50%
>> >> is supposed to be reached
>> >
>> > -----BEGIN PGP SIGNED MESSAGE-----
>> > Hash: SHA512
>> >
>> > On 03/24/2017 07:00 PM, Aymeric Vitte wrote: > I don't know what
>> > "Time is running short I fear" stands for and when 50% > is supposed
>> > to be reached
>> >
>> > According to current hashrate distribution tracking site coin.dance,
>> > very likely within less than four weeks according to current hashrate
>> > takeover rate.
>> >
>> > While a fork is very likely, that I dont really fear because worst
>> > case scenario is that bitcoin still survives and the invalid chain
>> > becomes an alt. My fear is the centralized mining power being used
>> > to attack the valid chain with intentions on killing it. [1]
>> >
>> > Shouldn't this 50% attack they are threatening be a concern? If it
>> > is a concern, what options are on the table. If it is not a concern
>> > please enlightent me as to why.
>> >
>> >
>> > [1] Source:
>> > https://www.reddit.com/r/Bitcoin/comments/6172s3/peter_rizun
>> _tells_miners_to_force_a_hard_fork_by/
>> >
>> > Text:
>> >
>> > The attack quoted from his article:
>> > https://medium.com/@peter_r/on-the-emerging-consensus-regard
>> ing-bitcoins-block-size-limit-insights-from-my-visit-with-2348878a16d8
>> >
>> > [Level 2] Anti-split protection Miners will orphan the
>> > blocks of non-compliant miners prior to the first larger block
>> > to serve as a reminder to upgrade. Simply due to the possibility
>> > of having blocks orphaned, all miners would be motivated to
>> > begin signalling for larger blocks once support definitively
>> > passes 51%. If some miners hold out (e.g., they may not be
>> > paying attention regarding the upgrade), then they will begin
>> > to pay attention after losing approximately $15,000 of revenue
>> > due to an orphaned block.
>> >
>> > [Level 3] Anti-split protection In the scenario where Levels
>> > 1 and 2 protection fails to entice all non-compliant miners to
>> > upgrade, a small-block minority chain may emerge. To address the
>> > risk of coins being spent on this chain (replay risk), majority
>> > miners will deploy hash power as needed to ensure the minority
>> > chain includes only empty blocks after the forking point. This
>> > can easily be accomplished if the majority miners maintain a
>> > secret chain of empty blocks built off their last empty
>> > block publishing only as much of this chain as necessary
>> > to orphan any non-empty blocks produced on the minority chain.
>> >
>> >
>> >
>> >
>> > - --
>> > Cannon
>> > PGP Fingerprint: 2BB5 15CD 66E7 4E28 45DC 6494 A5A2 2879 3F06 E832
>> > Email: cannon at cannon-ciota.info
>> >
>> > NOTICE: ALL EMAIL CORRESPONDENCE NOT SIGNED/ENCRYPTED WITH PGP SHOULD
>> > BE CONSIDERED POTENTIALLY FORGED, AND NOT PRIVATE.
>> > If this matters to you, use PGP.
>> > -----BEGIN PGP SIGNATURE-----
>> >
>> > iQIcBAEBCgAGBQJY1pbaAAoJEAYDai9lH2mwOO0QANOWqGzPNlifWguc+Y5UQxQM
>> > eAiztAayQBoAyLcFE7/qdtSNlUxbIAHG17fM+aNkehjYH2oN5ODJ+j7E2Yt6EoUH
>> > h5t8MLhNRG/YGF1hJK8Io940EmdcjuNmohiZvrjIqEOYggmLU3hR6J4gsuGsQQhu
>> > gY3sMS/TtT+gZNH8w53ePGrsVhuQR7yEMMr91/vM4+Q5abpwqLeYLnslaZDcd3XK
>> > VB9vyyK08r34J1GQt/H4UvTvGs28MFKBkvueA/Sfyvnrih7+WSQLuSvhiFr+cW1B
>> > TmSVYrB2DzyHN27jDCI2ty3ryNE4PMYcaeLfI2TTbsD/MuVU5lK0kM/1JajP4eRj
>> > j+P03OipuQiy/dNU63w0Uka2PbdKhDC13hVtK/ttBbNppbjnGeB9PYSJCzOpInGw
>> > NwAyz0rVS/llGsdctcII7Z6AUMGuJXzsosY8vjUroU+KFRDqIbDfC53sH7DaPh7u
>> > YawwId5S5RnZsAGCUJ+qNcg0s728J1eDjofN291IS5sOKMzpI7KhaOhFxjnk1MpN
>> > ZAlQeTlvG+sAdn61QMQK1NbFt0km+jcqyVh0+L01yB0K4VDi1YFJaSBOaYUELBXa
>> > 8a6WhZf5nrl5UIpH7rRcPzzqchcdYczy5VRZp2UsU+HYeqLXlcN0a03yPpVQik9S
>> > /T93MuZgmvSCry5MlccA
>> > =R71g
>> > -----END PGP SIGNATURE-----
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev at lists.linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
>
> _______________________________________________
> 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/20170326/88bf8628/attachment-0001.html>

2023-06-07 17:57:17

- reply

📅 Original date posted:2017-03-16
📝 Original message:This unnecessarily complicates transaction selection for miners by
introducing a second (and possibly third if I understand your proposal
correctly) dimension to try to optimize.
See: https://en.wikipedia.org/wiki/Bin_packing_problem
Segwit already solves this exact issue by replacing block size with block
weight, so I fail to see how this proposal would make any improvements
without introducing significant complications.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170316/e9a79d33/attachment.html>

2023-06-07 17:57:06

- reply

📅 Original date posted:2017-03-07
📝 Original message:I fail to see how any non-mining user can attack a miner. The worst they
can do is refuse to buy their coinbase transaction. Do you believe that
users are obligated to buy coins from miners? If not, then all miners are
voluntarily choosing a set of rules to enforce and a set of policy to mine.
>Don’t be mistaken; a hash-minority attacking the hash-majority is in actual
fact an attack upon Bitcoin as a whole.
Can you outline how a minority of hash rate can attack a majority? Users
are free to follow tighter rules than before, or they may reject it. The
majority of hash rate can continue the old rules or not. Where is the
attack? I see a disagreement being resolved peacefully through unilateral
separation.
>If this were possible then next year we’d see governments try to push
through changes in the same UASF way. I’m very happy that UASFs can’t work
because that would be the end of Bitcoin's freedom and decentralized nature.
Governments would be much more equipped to simply go directly to the miners
to enforce this for them - why even bother with millions of distributed
miners when you can knock on a few doors and get your policy?
>If the majority of the users are hostile and reject blocks that the miners
create, or change the POW, then what the miners bring to the table is also
removed.
I don't understand how users can be hostile to Bitcoin. Users are
Bitcoin. Everyone else serves the users. All participants are voluntary
and can choose to participate or not. Where is the attack or hostility?
-Alphonse
On Tue, Mar 7, 2017 at 3:17 AM, Tom Zander via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev
> wrote:
> > What you're describing is a hashpower activated soft fork to censor
> > transactions, in response to a user activated soft fork that the majority
> > of hashpower disagrees with.
>
> It is incorrect to say that censoring of transactions is what Edmund
> suggested. It's purely about the form they take, you can re-send the
> transaction in a different form with the same content and they go through.
> Hence, not transaction censoring.
>
> I do believe the point that Edmund brought up is a very good one, the idea
> that a set of users can force the miners to do something is rather silly
> and
> the setup that a minority miner fraction can force the majority to do
> something is equally silly. This is because the majority mining hashpower
> can fight back against this attack upon them.
>
> Don’t be mistaken; a hash-minority attacking the hash-majority is in actual
> fact an attack upon Bitcoin as a whole.
> If this were possible then next year we’d see governments try to push
> through changes in the same UASF way. I’m very happy that UASFs can’t work
> because that would be the end of Bitcoin's freedom and decentralized
> nature.
>
> > It is always possible for a majority of hashpower to censor transactions
> > they disagree with. Users may view that as an attack, and can always
> > respond with a POW hard fork.
>
> I definitely welcome that approach.
>
> The result would be that you have two chains, but also you ensure that the
> chain that the miners didn’t like will no longer be something they can
> mine.
> Not even the minority set of miners that like the softfork can mine on it.
> This is a win-win and then the market will decide which one will "win".
>
> > Bitcoin only works if the majority of hashpower is not hostile to the
> > users.
>
> This goes both ways, miners both generate value (in the form of security)
> and they take value (in the form of inflation).
> If the majority of the users are hostile and reject blocks that the miners
> create, or change the POW, then what the miners bring to the table is also
> removed.
> Bitcoin would lose the security and in the short term even the ability to
> mine blocks every 10 minutes.
>
> So, lets correct your statement a little;
> «Bitcoin only works when the majority of the hashpower and the (economic)
> majority of the users are balanced in power and have their goals
> aligned.»
>
> --
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel
> _______________________________________________
> 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/20170307/042228f6/attachment.html>