Steve Lee [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2019-10-23 to 2023-05-11
💬 Posted a total of 13 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-21 01:25:29

- reply

📅 Original date posted:2023-06-20
🗒️ Summary of this message: Electrum plans to implement BOLT-12 support in the coming months, but the author believes it may take years for it to become the dominant payment method on Lightning.
📝 Original message:
On Tue, Jun 20, 2023 at 6:17 AM Thomas Voegtlin <thomasv at electrum.org>
wrote:
>
>
> We have not implemented BOLT-12 yet in Electrum. Would you care to
> describe whether bundled payments already would work with the current
> specification, or whether they would require changes to BOLT-12? We
> are going to implement BOLT-12 support in Electrum in the coming
> months, and I would be happy to help here.
>
>
Fantastic news!
> I believe that it will take years *after it is merged*, until BOLT-12
> actually becomes the dominant payment method on Lightning. OTOH, if
> this feature was adopted in BOLT-11, I think it could be deployed much
> faster.
>
>
Why do you think it will be adopted faster? History has shown that any
upgrade requiring wallets to change takes years even if it is a small
change to an existing design. For example, despite only requiring a tiny
change, there is still not widespread bech32m support [1]. Bech32/native
segwit support also took years.
[1] http://whentaproot.com/
>
> cheers,
>
> Thomas
>
>
>
>
>
> On 15.06.23 11:01, Bastien TEINTURIER wrote:
> > Hi Thomas,
> >
> > First of all, I'd like to highlight something that may not be obvious
> > from your email, and is actually pretty important: your proposal
> > requires *senders* to be aware that the payment will lead to a channel
> > creation (or a splice) on the *receiver* end. In particular, it requires
> > all existing software used by senders to be updated. For this reason, I
> > think extending Bolt 12 (which requires new sender code anyway) makes
> > more sense than updating Bolt 11.
> >
> > I see only three strategies to provide JIT liquidity (by opening a new
> > channel or making a splice, I'll only use the open channel case below
> > for simplicity):
> >
> > 1. Ask receiver for the preimage and a fee, then open a channel and
> > push the HTLC amount minus the fee
> > 2. Open a channel, then forward the HTLC amount minus a fee
> > 3. Pre-pay fee, then open a channel and forward the whole HTLC amount
> > on that channel
> >
> > What is currently deployed on the network is 1) and 2), while you're
> > proposing 3). Both 1) and 2) have the advantages that the sender doesn't
> > need to be aware that JIT liquidity is happening, and doesn't need to do
> > anything special for that payment, which is the main reason those
> > strategies were chosen.
> >
> > If all you're concerned about is trust and regulation, solution 2) works
> > fine as long as the mempool isn't empty: if the user doesn't release the
> > preimage after you've opened the channel, you should just blacklist that
> > channel, reject payments made to it, and double-spend it whenever you
> > have another on-chain transaction to make (and use 1 sat/byte for JIT
> > liquidity transactions). Even if the mempool is empty, if your LSP has
> > transactions to make at every block, it's likely that it will succeed
> > at double-spending the faulty channel, and thus won't lose anything.
> >
> > But I agree that this only works when coupled with 0-conf. If we're not
> > using 0-conf anymore, pre-paying fees would make more sense. But we will
> > likely keep on using 0-conf at least until Bolt 12 is deployed, so it
> > seems more reasonable to include this new feature in Bolt 12 rather than
> > Bolt 11, since all implementations are actively working on this?
> >
> > Cheers,
> > Bastien
> >
> > Le jeu. 15 juin 2023 à 10:52, Thomas Voegtlin <thomasv at electrum.org> a
> > écrit :
> >
> >> Hello Matt,
> >>
> >> I think it is not too late to add a new feature to BOLT-11. In any
> >> case, the belief that BOLT-11 is ossified should not be a reason to
> >> make interactive something that fundamentally does not require more
> >> interactivity than what BOLT-11 already offers. Technical decisions
> >> should be dictated by technical needs, and I am a minimalist when it
> >> comes to adding new messages to protocols.
> >>
> >> I believe that two major implementations have an incentive to support
> >> this proposal (although I cannot speak for them):
> >> - Lightning Labs could potentially offer their Loop service to
> >> non-LND users.
> >> - ACINQ would be able to open channels to Phoenix users without
> >> requesting the preimage first. This would put them on the safe side
> >> of the upcoming MICA regulation; I cannot emphasize enough how
> >> important that is.
> >>
> >> In addition, you could certainly decide to support that feature in
> >> LDK, and I can speak for Electrum :-)
> >>
> >> It is the first time I suggest a change to the Lightning protocol, and
> >> what I am proposing is really a tiny change. All we need is a new
> >> invoice feature, that describes the prepayment of a fee using a
> >> different preimage. This feature does not need to be set on all
> >> invoices, and it could be made optional during a transition period.
> >>
> >> Here is how that feature could possibly made optional:
> >> - a new feature bit is defined, BUNDLE_PREPAYMENT
> >> - two extra fields are defined: prepayment_amount, prepayment_hash
> >> - if the sender does not support BUNDLE_PREPAYMENT and the feature is
> >> optional, it ignores the new fields
> >> - if the sender support BUNDLE_PREPAYMENT:
> >> - sender sends (amount - prepayment_amount) with payment_hash
> >> - sender sends prepayment_amount with prepayment_hash
> >>
> >> The decision to make this feature required or optional remains with
> >> the service provider. I can see how submarine swap providers who are
> >> already exposed to the mining fee griefing attack could decide to make
> >> it optional for a transition period.
> >>
> >> cheers,
> >> Thomas
> >>
> >>
> >> Regarding your question (a) about the distinction between splice-out
> >> and submarine swaps: Submarine swaps make it possible to add receiving
> >> capacity to a channel.
> >>
> >>
> >>
> >>
> >> On 14.06.23 19:28, Matt Corallo wrote:
> >>> I think the ship has probably sailed on getting any kind of new
> >> interoperable change in to BOLT-11.
> >>>
> >>> We already can't get amount-less BOLT-11 invoices broadly supported,
> >> rolling out yet another new incompatible version of BOLT-11 and
> expecting
> >> the entire ecosystem to support it doesn't seem all that likely.
> >>>
> >>> If we're working towards specifying some "standard" way of doing swaps,
> >> (a) I'd be curious to understand why the need isn't obviated by
> splice-out,
> >> and (b) why it shouldn't be built on OMs so you can do it more
> privately.
> >>>
> >>> Matt
> >>>
> >>> On 6/13/23 1:10 AM, Thomas Voegtlin wrote:
> >>>> Good morning list,
> >>>>
> >>>> I would like to propose an extension to BOLT-11, where an invoice can
> >> contain two bundled payments, with distinct preimages and amounts.
> >>>>
> >>>> The use case is for services that require the prepayment of a mining
> >> fee in order for a non-custodian exchange to take place:
> >>>> - Submarine swaps
> >>>> - JIT channels
> >>>>
> >>>> In both cases, the service provider receives a HTLC for which they do
> >> not have the preimage, have to send funds on-chain (to the channel or
> >> submarine swap funding address), and wait for the client to reveal the
> >> preimage when they claim the payment. Because there is no guarantee that
> >> the client will actually claim the payment, the service providers need
> to
> >> ask prepayment of mining fees.
> >>>>
> >>>> In the case of submarine swaps, services that use dedicated client
> >> software, such as Loop by Lightning Labs, can ask for a prepayment,
> because
> >> their software can handle it (this is called "no show penalty" on the
> Loop
> >> website). However, competitors who do require a dedicated wallet, not
> such
> >> as the Boltz exchange, cannot do that. Their website shows an invoice to
> >> the user, whose wallet that is agnostic about the swap, and it would be
> >> unpractical for them to show two invoices to be paid simultaneously.
> This
> >> creates a situation where Boltz is vulnerable to DoS attacks, where the
> >> attacker forces them to pay on-chain fees.
> >>>>
> >>>> In the case of JIT channels, providers who want to protect themselves
> >> against this mining fee attack need to ask the preimage of the main
> payment
> >> before they open the channel. I believe this is what Phoenix does
> (although
> >> their pay-to-open service is not open-source, so I cannot really check).
> >> The issue is that a service that asks for the preimage first becomes
> >> custodian. From a legal perspective, it does not matter whether they
> open
> >> the channel immediately after receiving the preimage, the ordering of
> >> events makes their service custodian. In Europe, such a service will
> fall
> >> within the European MICA regulation. Competitors who refuse to offer
> >> custodian services, such as Electrum, are excluded from that game.
> >>>>
> >>>> In order to solve that, it would be beneficial to bundle the
> prepayment
> >> and the main payment in the same BOLT-11 invoice.
> >>>>
> >>>> The semantics of bundled payments is as follows:
> >>>> - 1. the BOLT-11 invoice contains two preimages and two amounts:
> >> prepayment and main payment.
> >>>> - 2. the receiver should wait until all the HTLCs of both payments
> >> have arrived, before they fulfill the HTLCs of the pre-payment. If the
> main
> >> payment does not arrive, they should fail the pre-payment with a MPP
> >> timeout.
> >>>> - 3. once the HTLCs of both payments have arrived, the receiver
> >> fulfills the HTLCs of the prepayment, and they broadcast their on-chain
> >> transaction. Note that the main payment can still fail if the sender
> never
> >> reveal the preimage of the main payment.
> >>>>
> >>>> Of course, nothing in my proposal prevents the service provider from
> >> stealing the pre-payment, but that is already the case today.
> >>>>
> >>>> I believe this proposal would level the field in terms of competition
> >> between lightning service providers. Currently, you need to use a
> dedicated
> >> client in order to use Loop, and competitors who do not have an
> established
> >> user base running a dedicated client are exposed to the mining fee
> attack.
> >> I also believe that ACINQ would benefit from this, because it would
> make it
> >> possible for them to make their pay-to-open service fully
> non-custodian. My
> >> understanding is that in its current form, the 'pay-to-open' service
> used
> >> by Phoenix will fall into the scope of the European MICA regulation,
> which
> >> they should consider as a serious issue.
> >>>>
> >>>> Finally, I believe that such a change should be implemented in
> BOLT-11,
> >> and not using BOLT-12 or onion messages. Indeed, my proposal does not
> >> require the exchange of new messages. Some of the initial feedback I
> >> received was that this is a use case for BOLT-12 or OM, but I think that
> >> this is making things unnecessarily complicated. We should not add new
> >> messages when things can be done in a non-interactive way.
> >>>>
> >>>> Cheers,
> >>>> ThomasV
> >>>> _______________________________________________
> >>>> Lightning-dev mailing list
> >>>> Lightning-dev at lists.linuxfoundation.org
> >>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >>
> >> --
> >> Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin /
> Germany
> >> Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
> >> Geschäftsführer: Thomas Voegtlin
> >> _______________________________________________
> >> Lightning-dev mailing list
> >> Lightning-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >>
> >
>
> --
> Electrum Technologies GmbH / Paul-Lincke-Ufer 8d / 10999 Berlin / Germany
> Sitz, Registergericht: Berlin, Amtsgericht Charlottenburg, HRB 164636
> Geschäftsführer: Thomas Voegtlin
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230620/df9efe13/attachment-0001.html>

2023-06-08 01:21:22

- reply

📅 Original date posted:2023-05-11
🗒️ Summary of this message: Effective communication is key to persuading others, and the communication styles of some Bitcoin developers may need reflection. Adding maintainers requires a better process.
📝 Original message:I don't see any reason to be antagonistic in your responses.
One piece of advice I'd offer to you and Michael is to consider whether
your responses are effective. To persuade other people it takes more than
making good points or being right, but you need to find a communication
style and communication path that is effective. My observation is that your
styles need reflection.
On Thu, May 11, 2023 at 10:15 AM alicexbt via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Andrew,
>
> We can take a look at how previous maintainers were added to see how this
> has played out in the past.
>
>
> Can we learn something from past?
>
> Bitcoin's initial release was in 2009 with one developer and few others
> experimenting with it. It is considered decentralized in 2023 however we
> have 99% of nodes using bitcoin core, 5 developers deciding what's merged
> or not and this includes some trying to implement their ideas without soft
> fork using mempool policies.
>
> We need better process to add maintainers. I am disappointed with the way
> last last pull request was merged. It says more about maintainers and
> leader Michael Ford. If you are so scared about opinions on a pull request
> why not just make him maintainer without pull request?
>
> Maybe you will understand this if your PR to add maintainer was kept open
> for 4 months.
>
> /dev/fd0
> floppy disk
>
>
> Sent with Proton Mail <https://proton.me/> secure email.
>
> ------- Original Message -------
> On Thursday, May 11th, 2023 at 2:54 AM, Andrew Chow via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
>
>
> The decision process for adding a new maintainer was according to the IRC
> meeting that the maintainers decided privately there was a need for a
> maintainer “who understood our interfaces and modularization efforts well”
> and that ryanofsky was a “good fit for that”. I don’t know whether this was
> decided in a private IRC channel or was decided at the recent in person
> Core Dev meeting. Regardless, many have had no input into the discussion on
> what kind of maintainer the project needs going forward and it seems the
> maintainers do not want to discuss that aspect of the decision.
>
> Since the project began, the decision to seek out and then add a
> maintainer has always been made by existing maintainers. When the
> maintainers feel that there is a need for additional maintainers, they may
> have an open call for volunteers, or may have a candidate already in mind
> and suggest that specific person for maintainership. Contributors generally
> are not consulted in the decision to seek a new maintainer as they would
> not know whether there are things that are being overlooked or that there
> is maintainership load that needs to be distributed. Even so, it wouldn't
> be appropriate to add a maintainer if many contributors disagreed with it,
> just as with any other PR.
>
> We can take a look at how previous maintainers were added to see how this
> has played out in the past. I think our modern concept of maintainers with
> nominal scopes began in 2015 with Jonas Schnelli. Both Jonas Schnelli and
> Marco Falke were simply announced by Wladimir. There was no public
> discussion, and some IRC logs refer to private emails between the them and
> the current maintainers at that time. After that, meshcollider was added as
> a maintainer after a public "call for maintainers" where a recurring topic
> for a while was finding a maintainer for the wallet. He had volunteered to
> do it by contacting Wladimir privately before it was discussed during an
> IRC meeting and then on Github. Fanquake was added as a maintainer during a
> CoreDev event in Amsterdam during a discussion initiated and led by the
> maintainers. This was also "private" insofar as the discussion was limited
> to those in attendance, although there was some opportunity for public
> discussion in the PR opened on Github. For myself, it was also initially
> private as I messaged Wladimir to volunteer for it after meshcollider
> stepped down. There was some discussion on IRC and on Github, but it was
> also obvious that many already expected me to be the wallet maintainer
> after meshcollider. Hebasto was added with basically no fanfare or
> discussion - the only mention I can find is the PR itself. My understanding
> is that the maintainers asked him he wanted to do it before the PR was
> opened. Glozow was nominated to be a maintainer by some of the current
> maintainers, and her nomination was really the first time that there was
> significant public discussion about it.
>
> Of the past 7 maintainer additions, 5 were nominations/announcements from
> the current maintainers, one was volunteering following an actual "call for
> maintainer", and one was an obvious successor. It's obvious and common
> sense that the maintainers decide when they need help shouldering the load,
> and then find somebody to help them. There was and always will be some
> level of private communication prior to any public announcement of the
> nomination or volunteering of a maintainer. It doesn't make sense to
> blindside somebody with a nomination without talking to them beforehand.
> The fact that most of these were non-controversial speaks to how well the
> maintainers were considering their nominations before publicly announcing
> them.
>
> It's also clear that we have been moving towards more open discussion
> about maintainership and who should be maintainers. The process is
> fundamentally more public than it was previously. We now have public
> discussion with contributors about the merits of a person, even if that
> results in said person not becoming a maintainer. Over time, there's been
> more public participation in the PRs and on IRC meetings when maintainer
> nominations are brought up. We have nominations as topics during meetings
> now when they occur. The PRs to add keys are left open for longer to get
> more discussion.
>
> Ultimately, if you disagree with how the project operates, then you are
> free to leave and start your own fork that is run in a way that you think
> is appropriate. This is open source software, no one is beholden to you,
> and no one is required to do anything.
>
> ***
>
> Since you are intent on discussing and re-litigating the decision about
> Vasil, I will agree that we (the maintainers) could have done a better job
> of communicating. However we stand by the decision that was made in the
> end, and we did have a chat with him about it during CoreDev.
>
> It really boils down to three things: 1) we did not ask for a P2P
> maintainer, 2) some of those who have reviewed Vasil's work expressed
> discomfort with him being a maintainer, and 3) some contributors and
> maintainers were uncomfortable with his responses about how he would merge
> things. You repeatedly insist that it's only the current maintainers who
> blocked Vasil, but that is not the case. There were concerns brought up by
> other contributors that contributed to the decision to ultimately NACK his
> nomination.
>
> One of the justifications for blocking Vasil Dimov as a new maintainer
> despite many initial ACKs from maintainers (including Andrew Chow) and long
> term contributors was according to Andrew [2]:
>
> To be honest, my initial ACK was given without knowing enough information.
> It was given when he was mostly a name that showed up in my notification
> emails, and his work had seemed to be fine with me. At that time, I did not
> think we had a need for a P2P maintainer, but I also did not think that
> having one would be harmful. However I later spoke to a few others
> privately who were more familiar with Vasil's work and they had told me
> that they were not comfortable with Vasil being P2P maintainer.
>
> “Maintainers inherently need to look at the things that everyone else has
> already looked at, if only to give it a final once over before merging (but
> hopefully, an actual review, not just looking it over).”
>
>
> I follow the Bitcoin Core repo pretty closely and I haven’t seen ryanofsky
> do this any more than Vasil does. This is not a criticism of ryanofsky,
> just as I wouldn’t use it as a criticism for Vasil. It would get pretty
> annoying if everyone who wasn’t a maintainer posted an ACK once many long
> term contributors had already ACKed to display supposed “desired maintainer
> traits”. Especially if you are essentially just ACKing that others have
> done the work to review the PR and you just want to get your ACK on it to
> increase your ACK count without doing a fraction of what previous reviewers
> have done.
>
> This opinion was formed not from observing his behavior towards ACK'ing,
> but rather from his responses to questions about reviewing, in addition to
> thoughts shared by other contributors.
>
> From having received plenty of reviews from ryanofsky, I can certainly say
> that his reviews are in depth. He has pointed out subtle bugs, asks
> questions about very low level details, and has well reasoned critiques and
> discussions about design decisions. His reviews are high quality, and he's
> not afraid of being the first person to ACK a pr, the last person to ACK
> it, or the person to prevent one from being merged even when it already has
> a few ACKs. We also had a separate discussion with ryanofsky about his
> approaches to reviewing and merging.
>
> “I also want to mention that the people who have become maintainers in the
> past have had this kind of maintainer attitude towards review prior to
> becoming a maintainer”
>
>
> Assuming ryanofsky hasn’t had this maintainer attitude in the past (again
> not a criticism from me at least) does this mean this was a reason to block
> Vasil but not a reason to block ryanofsky? That seems inconsistent to me.
>
> I don't know why you assume the ryanofsky hasn't had this maintainer
> attitude? Your claim of inconsistency stems from this assumption that
> ryanofsky doesn't have a maintainer attitude, but I would argue that he
> does, as I mentioned above. The idea of adding him as a maintainer has been
> floated around before, although never really seriously proposed until now,
> AFAIK.
>
> When you’re anointed you don’t need to meet requirements but when you’re
> blocked these requirements will be used to block your addition as a new
> maintainer?
>
> It seems obvious to me that when the current maintainers approach and
> nominate a contributor to be a maintainer that that person already meets
> these requirements. I don't know why you would assume bad faith in that
> someone who isn't qualified would be nominated by the current maintainers.
> It's quite frustrating that you seem to just jump straight to the negative
> conclusion rather than considering that there might be actual reasons based
> on the merits of the person.
>
> On a more positive note there does seem to be more energy and momentum for
> collaboration and open communication on the project since I discussed
> communication in a previous post [3]. Hopefully this will continue. It
> doesn’t address my concerns on maintainers and ultimately merge decisions
> but it definitely seems to me to be a step in a positive direction for the
> project.
>
> Don't take credit for what you didn't do. The group-wide effort to move
> towards public discussion again is the result of a discussion that was had
> at CoreDev. Many cited your behavior as a primary reason to stop discussing
> things publicly, with things such as dragging project meta discussions onto
> the mailing list and twitter. These have invited abuse towards maintainers
> and contributors, which in turn makes them takes those discussions to more
> private settings. People feel like they're getting sealioned by you (and a
> few others) when they post publicly, and so they have stopped doing so.
>
>
> Andrew
>
>
> _______________________________________________
> 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/20230511/fa7ff9bb/attachment-0001.html>

2023-06-08 01:21:20

- reply

📅 Original date posted:2023-05-10
🗒️ Summary of this message: A Core contributor expressed concern over the process for blocking Vasil as a maintainer and the potential inconsistency in reasons for blocking future maintainers.
📝 Original message:I see it was merged since my original post. I agree that is a very short
window of time. In particular, if a long-time Core contributor wasn't able
to attend the in-person meeting or last week's IRC meeting, they'd have had
to really been on the ball.
On Wed, May 10, 2023 at 10:22 AM Michael Folkson <
michaelfolkson at protonmail.com> wrote:
> > Blocking Vasil was discussed on a similar GitHub PR. Whether or not one
> agrees or disagrees, the same process is being used. Anyone can NACK and
> give a reason for Russ as well.
>
> With respect Steve the process for Vasil was keeping Vasil's PR open for
> up to 5 months with zero NACKs and two maintainers refusing to engage on
> why it wasn't being merged or what it needed for it to be merged. Followed
> by a later justification for blocking it that they've refused to discuss
> whether it applies to Russ.
>
> The process for Russ was the maintainers deciding privately there was a
> need for a maintainer "who understood our interfaces and modularization
> efforts well" and his PR was merged within 2 days.
>
> If that's the same process to you I don't know what to say. We have
> different perspectives on what constitutes a decision process.
>
> (I'm sure this is clear but just to reiterate in case it isn't none of
> this is a criticism of Russ.)
>
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> ------- Original Message -------
> On Wednesday, May 10th, 2023 at 17:36, Steve Lee <steven.j.lee at gmail.com>
> wrote:
>
> Blocking Vasil was discussed on a similar GitHub PR. Whether or not one
> agrees or disagrees, the same process is being used. Anyone can NACK and
> give a reason for Russ as well.
>
> On Wed, May 10, 2023 at 8:55 AM Michael Folkson <
> michaelfolkson at protonmail.com> wrote:
>
>> Hi Steve
>>
>> > Isn't this as simple as anyone (in particular Core project
>> contributors) can express their view in this PR?
>> https://github.com/bitcoin/bitcoin/pull/27604
>>
>> Nope. The extent to which the rationale for blocking Vasil as a
>> maintainer applies or doesn't apply to ryanofsky (or future potential
>> maintainers) isn't discussed. From now on the precedent is proposed
>> maintainers can be blocked for unknown and/or potentially inconsistent
>> reasons by the existing maintainers.
>>
>> Thanks
>> Michael
>>
>> --
>> Michael Folkson
>> Email: michaelfolkson at protonmail.com
>> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>>
>> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>>
>> ------- Original Message -------
>> On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>> Isn't this as simple as anyone (in particular Core project contributors)
>> can express their view in this PR?
>> https://github.com/bitcoin/bitcoin/pull/27604
>>
>> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>>>> > Essentially my concern is going forward current maintainers will
>>>> > decide which proposed new maintainers to add and which to block.
>>>>
>>>> This is how a large percentage of organizations are run. The current
>>>> members of a board or other governance group choose who will become a
>>>> new board member.
>>>>
>>>
>>> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of
>>> independent contributors merging different pull requests or patches. The
>>> github controls are merely because that is how github works. There is also
>>> a secondary issue of people tending to confuse Bitcoin Core with the
>>> bitcoin protocol in general:
>>> https://blog.lopp.net/who-controls-bitcoin-core/
>>>
>>> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>>>
>>> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>>>
>>> - Bryan
>>> https://twitter.com/kanzure
>>> _______________________________________________
>>> 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/20230510/b5e0c073/attachment-0001.html>

2023-06-08 01:21:19

- reply

📅 Original date posted:2023-05-09
🗒️ Summary of this message: The discussion on the Bitcoin Core project's governance continues, with concerns raised about the selection of new maintainers.
📝 Original message:Isn't this as simple as anyone (in particular Core project contributors)
can express their view in this PR?
https://github.com/bitcoin/bitcoin/pull/27604
On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>> > Essentially my concern is going forward current maintainers will
>> > decide which proposed new maintainers to add and which to block.
>>
>> This is how a large percentage of organizations are run. The current
>> members of a board or other governance group choose who will become a
>> new board member.
>>
>
> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of
> independent contributors merging different pull requests or patches. The
> github controls are merely because that is how github works. There is also
> a secondary issue of people tending to confuse Bitcoin Core with the
> bitcoin protocol in general:
> https://blog.lopp.net/who-controls-bitcoin-core/
> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>
> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>
> - Bryan
> https://twitter.com/kanzure
> _______________________________________________
> 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/20230509/6a00e388/attachment-0001.html>

2023-06-08 01:21:19

- reply

📅 Original date posted:2023-05-10
🗒️ Summary of this message: The process of blocking maintainers on GitHub PRs is being discussed, with concerns raised about potentially inconsistent reasons for blocking proposed maintainers.
📝 Original message:Blocking Vasil was discussed on a similar GitHub PR. Whether or not one
agrees or disagrees, the same process is being used. Anyone can NACK and
give a reason for Russ as well.
On Wed, May 10, 2023 at 8:55 AM Michael Folkson <
michaelfolkson at protonmail.com> wrote:
> Hi Steve
>
> > Isn't this as simple as anyone (in particular Core project
> contributors) can express their view in this PR?
> https://github.com/bitcoin/bitcoin/pull/27604
>
> Nope. The extent to which the rationale for blocking Vasil as a maintainer
> applies or doesn't apply to ryanofsky (or future potential maintainers)
> isn't discussed. From now on the precedent is proposed maintainers can be
> blocked for unknown and/or potentially inconsistent reasons by the existing
> maintainers.
>
> Thanks
> Michael
>
> --
> Michael Folkson
> Email: michaelfolkson at protonmail.com
> GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F
>
> Learn about Bitcoin: https://www.youtube.com/@portofbitcoin
>
> ------- Original Message -------
> On Wednesday, May 10th, 2023 at 03:44, Steve Lee via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Isn't this as simple as anyone (in particular Core project contributors)
> can express their view in this PR?
> https://github.com/bitcoin/bitcoin/pull/27604
>
> On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
>>> > Essentially my concern is going forward current maintainers will
>>> > decide which proposed new maintainers to add and which to block.
>>>
>>> This is how a large percentage of organizations are run. The current
>>> members of a board or other governance group choose who will become a
>>> new board member.
>>>
>>
>> Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of
>> independent contributors merging different pull requests or patches. The
>> github controls are merely because that is how github works. There is also
>> a secondary issue of people tending to confuse Bitcoin Core with the
>> bitcoin protocol in general:
>> https://blog.lopp.net/who-controls-bitcoin-core/
>> https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
>>
>> https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427
>>
>> - Bryan
>> https://twitter.com/kanzure
>> _______________________________________________
>> 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/20230510/6bf5a3f0/attachment-0001.html>

2023-06-08 01:20:21

- reply

📅 Original date posted:2023-04-01
🗒️ Summary of this message: Alicexbt argues that inscriptions/NFTs do not affect the fungibility of Bitcoin and should be allowed without changing consensus rules.
📝 Original message:"want bitcoin to be money and money means different things for people in
this world"
I interpreted your above statement to mean that to some people,
inscriptions/NFTs are money. That is what I was responding to.
On Fri, Mar 31, 2023 at 9:26 AM alicexbt <alicexbt at protonmail.com> wrote:
> Hi Steve and Bitcoin Developers,
>
> I have created a new thread as requested by one of the developers. I
> respect him and the readers of this list.
>
> > "want bitcoin to be money and money means different things for people in
> this world"
>
> > I think we can all agree that a property of money is fungibility, and by
> its very definition NFTs are not fungible and thus not money.
>
> Inscriptions do not affect fungibility of bitcoin:
>
> - There is no token standard being used. These are just sats being
> considered as inscription in an external protocol or explorer. Bitcoin
> nodes do not consider them as something special.
> - Users can always sell those inscribed sats or UTXO as normal bitcoin on
> bisq or any exchange.
> - They can use different amounts for it using tools like
> https://raritygarden.inscribetheplanet.com/ which is created by super
> testnet who is active dev in bitcoin and ln.
> - Inscribed sats are different from Ethereum tokens because they will
> never go to zero and you can always consolidate lot of them to use as
> normal bitcoin.
>
> Bitcoin fungibility is anyways debatable and I cannot change anything
> about it even though working on a coinjoin implmentation as some post mix
> UTXOs are censored on some exchanges and its easy to identify them. Some
> coinjoin implementation themselves work with chain analysis companies to
> censor inputs used for rounds.
>
> Ordinals theory is a parallel universe in which some users believe in and
> they have been trying to learn how bitcoin works. Example: I did call with
> someone this evening to explain how PSBT and multisig works who never used
> bitcoin before
>
> Developers are interested to build things and they have tried to create
> BIP, DEX, look for libraries, ask questions, projects implementing PSBT etc.
>
> I do not live in first world country and do not attend bitdevs but always
> wanted bitcoin to be here. I have tried my best but failed. Please let
> people do what they want with bitcoin without changing consensus rules. It
> will help Bitcoin.
>
> /dev/fd0
> floppy disk guy
>
> Sent with Proton Mail secure email.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230401/6d4351f9/attachment.html>

2023-06-08 01:20:05

- reply

📅 Original date posted:2023-03-29
🗒️ Summary of this message: The writer wants Bitcoin to be money, but NFTs are not fungible and thus not money. Parasitical use cases of the blockchain should be made less feasible.
📝 Original message:"want bitcoin to be money and money means different things for people in
this world"
I think we can all agree that a property of money is fungibility, and by
its very definition NFTs are not fungible and thus not money.
On Wed, Mar 29, 2023 at 4:56 PM alicexbt via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Zac,
>
> Let me share what those parasites achieved:
>
> - Fees paid: 150 BTC
> - Lot of users and developers trying bitcoin that either never tried or
> gave up early in 2013-15
> - Mempools of nodes of being busy on weekends and got lots of transactions
> - PSBT became cool and application devs are trying their best to use it in
> different ways
> - Some developers exploring taproot and multisig
> - AJ shared things how covenants could help in fair, non-custodial,
> on-chain auction of ordinals that is MEV resistant although I had shared it
> earlier which involves more steps:
> https://twitter.com/1440000bytes/status/1634368411760476161
> - Investors exploring about funding projects
> - Bitcoin more than Bitcoin and people excited about it
>
> We can have difference of opinion, however I want bitcoin to be money and
> money means different things for people in this world. Please respect that
> else it will become like Linux, something used by 1% of world.
>
> /dev/fd0
> floppy disk guy
>
> Sent with Proton Mail secure email.
>
> ------- Original Message -------
> On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>
> > I’m not sure why any effort should be spent on theorizing how new
> opcodes might be used to facilitate parasitical use cases of the blockchain.
> >
> > If anything, business models relying on the ability to abuse the
> blockchain as a data store must be made less feasible, not more.
> >
> > Zac
> >
> >
> > On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> > > On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via
> bitcoin-dev wrote:
> > > > I think there are perhaps four opcodes that are interesting in this
> class:
> > > >
> > > > idx sPK OP_FORWARD_TARGET
> > > > -- sends the value to a particular output (given by idx), and
> > > > requires that output have a particular scriptPubKey (given
> > > > by sPK).
> > > >
> > > > idx [...] n script OP_FORWARD_LEAF_UPDATE
> > > > -- sends the value to a particular output (given by idx), and
> > > > requires that output to have almost the same scriptPubKey as this
> > > > input, _except_ that the current leaf is replaced by "script",
> > > > with that script prefixed by "n" pushes (of values given by [...])
> > > >
> > > > idx OP_FORWARD_SELF
> > > > -- sends the value to a particular output (given by idx), and
> > > > requires that output to have the same scriptPubKey as this input
> > > >
> > > > amt OP_FORWARD_PARTIAL
> > > > -- modifies the next OP_FORWARD_* opcode to only affect "amt",
> > > > rather than the entire balance. opcodes after that affect the
> > > > remaining balance, after "amt" has been subtracted. if "amt" is
> > > > 0, the next OP_FORWARD_* becomes a no-op.
> > >
> > > The BIP 345 draft has been updated [0] [1] and now pretty much defines
> > > OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE
> above,
> > > and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despite
> > > that, for this email I'm going to continue using the OP_FORWARD_*
> > > naming convention.
> > >
> > > Given the recent controversy over the Yuga labs ordinal auction [2],
> > > perhaps it's interesting to consider that these proposed opcodes come
> > > close to making it possible to do a fair, non-custodial, on-chain
> auction
> > > of ordinals [3].
> > >
> > > The idea here is that you create a utxo on chain that contains the
> ordinal
> > > in question, which commits to the address of the current leading
> bidder,
> > > and can be spent in two ways:
> > >
> > > 1) it can be updated to a new bidder, if the bid is raised by at least
> > > K satoshis, in which case the previous bidder is refunded their
> > > bid; or,
> > >
> > > 2) if there have been no new bids for a day, the current high bidder
> > > wins, and the ordinal is moved to their address, while the funds
> > > from their winning bid are sent to the original vendor's address.
> > >
> > > I believe this can be implemented in script as follows,
> > > assuming the opcodes OP_FORWARD_TARGET(OP_VAULT_RECOVER),
> > > OP_FORWARD_LEAF_UPDATE(OP_VAULT), OP_FORWARD_PARTIAL (as specced
> above),
> > > and OP_PUSHCURRENTINPUTINDEX (as implemented in liquid/elements [4])
> > > are all available.
> > >
> > > First, figure out the parameters:
> > >
> > > * Set VENDOR to the scriptPubKey corresponding to the vendor's address.
> > > * Set K to the minimum bid increment [5].
> > > * Initially, set X equal to VENDOR.
> > > * Initially, set V to just below the reserve price (V+K is the
> > > minimum initial bid).
> > >
> > > Then construct the following script:
> > >
> > > [X] [V] [SSS] TOALT TOALT TOALT
> > > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > > DEPTH NOT IF
> > > 0 10000 FORWARD_PARTIAL
> > > 0 FROMALT FORWARD_TARGET
> > > 1 [VENDOR] FWD_TARGET
> > > 144
> > > ELSE
> > > FROMALT SWAP TUCK FROMALT
> > > [K] ADD GREATERTHANOREQUAL VERIFY
> > > 1 SWAP FORWARD_TARGET
> > > DUP FORWARD_PARTIAL
> > > 0 ROT ROT
> > > FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> > > 0
> > > ENDIF
> > > CSV
> > > 1ADD
> > >
> > > where "SSS" is a pushdata of the rest of the script ("TOALT TOALT TOALT
> > > .. 1ADD").
> > >
> > > Finally, make that script the sole tapleaf, accompanied by a NUMS point
> > > as the internal public key, calculate the taproot address corresponding
> > > to that, and send the ordinal to that address as the first satoshi.
> > >
> > > There are two ways to spend that script. With an empty witness stack,
> > > the following will be executed:
> > >
> > > [X] [V] [SSS] TOALT TOALT TOALT
> > > -- altstack now contains [SSS V X]
> > > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > > -- this input is the first, so the ordinal will move to the first
> > > output
> > > DEPTH NOT IF
> > > -- take this branch: the auction is over!
> > > 1 [VENDOR] FWD_TARGET
> > > -- output 1 gets the entire value of this input, and pays to
> > > the vendor's hardcoded scriptPubKey
> > > 0 10000 FORWARD_PARTIAL
> > > 0 FROMALT FORWARD_TARGET
> > > -- we forward at least 10k sats to output 0 (if there were 0 sats,
> > > the ordinal would end up in output 1 instead, which would be a
> > > bug), and output 0 pays to scriptPubKey "X"
> > > 144
> > > ELSE .. ENDIF
> > > -- skip over the other branch
> > > CSV
> > > -- check that this input has baked for 144 blocks (~1 day)
> > > 1ADD
> > > -- leave 145 on the stack, which is true. success!
> > >
> > > Alternatively, if you want to increase the bid you provide a stack with
> > > two items: your scriptPubKey and the new bid [X' V']. Execution this
> > > time looks like:
> > >
> > > [X] [V] [SSS] TOALT TOALT TOALT
> > > -- stack contains [X' V'], altstack now contains [SSS V X]
> > > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > > -- this input is the first, so the ordinal will move to the first
> > > output
> > > DEPTH NOT IF ... ELSE
> > > -- skip over the other branch (without violating minimalif rules)
> > > FROMALT SWAP TUCK FROMALT
> > > -- stack contains [X' V' X V' V], altstack contains [SSS]
> > > [K] ADD GREATERTHANOREQUAL VERIFY
> > > -- check V' >= V+K, stack contains [X' V' X]
> > > 1 SWAP FORWARD_TARGET
> > > -- output 1 pays to X (previous bidder's scriptPubKey), and the
> > > entire value of this input goes there; stack contains [X' V']
> > > DUP FORWARD_PARTIAL
> > > -- execute "V' FORWARD_PARTIAL", stack contains [X' V']
> > > 0 ROT ROT
> > > -- stack contains [0 X' V']
> > > FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> > > -- execute "0 X' V' SSS 3 SSS FORWARD_LEAF_UPDATE" which checks
> > > that output 0 spends at least V' satoshis back to the same
> > > script (because that's how we defined SSS), except the first
> > > three pushes (previously X V SSS) are replaced by X' V' SSS.
> > > 0
> > > ENDIF
> > > CSV
> > > -- "0 CSV" requires nSequnce to be set, which makes the tx rbf'able,
> > > which hopefully makes it harder to pin
> > > 1ADD
> > > -- ends with 1 on the stack; success!
> > >
> > > (The "SSS n SSS FORWARD_LEAF_UPDATE" construct is more or less a quine,
> > > ie a program that outputs its own source code)
> > >
> > > I think that script is about 211 witness bytes, with an additional 40
> > > witness bytes for X'/V', so when making a bid, your tx would be
> > > something like:
> > >
> > > tx header, 10vb
> > > input 0: 103vb for the old bid including witness and control block
> > > input 1: 58vb for a taproot key path spend
> > > output 0: 43vb for the new bid
> > > output 1: 43vb for your change
> > >
> > > for a total of about 257vb -- slightly larger than a regular 2-in-2-out
> > > transaction, but not terribly much. Mostly because input 0 doesn't
> require
> > > a signature -- it's size is effectively 6 pubkeys: X, X' VENDOR twice,
> > > and the script code twice, along with a little extra to encode the
> > > various numbers (10000, 144, K, V, V').
> > >
> > > This approach seems pretty "MEV" resistant: you pay fees via input 1 if
> > > your bid succeeds; if it doesn't, you don't pay any fees. A potential
> > > scalper might want to put in an early low ball bid, then prevent
> > > higher bidders from winning the auction, take control of the ordinal,
> > > and resell it later, but unless they can prevent another miner from
> > > mining alternative bids for 144 blocks, they will fail at that. The bid
> > > is fixed by the bidder and committed to by the signature on input 1, so
> > > frontrunning a bid can't do anything beyond invalidate the bid
> entirely.
> > >
> > > Obviously, this is a pretty limited auction mechanism in various ways;
> > > eg maybe you'd rather specify K as a percentage than an absoute
> increment;
> > > maybe you'd like to have the auction definitely finish by some
> particular
> > > time; maybe you'd like to be able to have the auction be able to
> continue
> > > above 21.47 BTC (2**31 sats); maybe you'd like to do a dutch auction
> > > rather than an english auction. I think you can probably do all those
> > > things with this set of opcodes and clever scripting, though it
> probably
> > > gets ugly.
> > >
> > > I don't think this is easily extensible to taro or rgb style assets,
> > > as rather than being able to ensure the asset is transferred by
> > > controlling the input/output positions, I think you'd need to build
> > > up merkle trees and do point tweaks beyond what's supported by
> > > OP_FORWARD_LEAF_UPDATE/OP_VAULT. Of course, without something like
> > > OP_PUSHCURRENTINPUTINDEX I don't think you could do it for ordinals
> > > either.
> > >
> > > Cheers,
> > > aj
> > >
> > > [0]
> https://github.com/bitcoin/bips/blob/7f747fba82675f28c239df690a07b75529bd0960/bip-0345.mediawiki
> > >
> > > [1] https://twitter.com/jamesob/status/1639019107432513537
> > >
> > > [2]
> https://cointelegraph.com/news/scammers-dream-yuga-s-auction-model-for-bitcoin-nfts-sees-criticism
> > >
> > > [3] Inscriptions remain a wasteful way of publishing/committing
> > > to content, however!
> > >
> > > [4]
> https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md
> > >
> > > [5] Setting K too low probably invites griefing, where a bidder may be
> > > able to use rbf pinning vectors to prevent people who would be willing
> > > to bid substantially higher from getting their bid confirmed on
> > > chain.
> > > _______________________________________________
> > > 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/20230329/6f8c48f0/attachment-0001.html>

2023-06-08 01:02:14

- reply

📅 Original date posted:2022-01-13
📝 Original message:That's a good point. Agree!
On Thu, Jan 13, 2022 at 10:54 AM Alex Schoof <alex.schoof at gmail.com> wrote:
> > I also don't see why Alex or anyone should be denied the opportunity to
> comment on future soft forks or anything about bitcoin. Alex should have no
> more or less right to participate and his comments should be judged on
> their merit, just like yours and mine.
>
> I think the concern is something like: "I disagree with a board member of
> the defense fund about [insert contentious issue]. If I disagree with them
> publicly (especially if there are clear economic implications in that
> disagreement), am I putting myself at risk in the future where I won't be
> able to get support from the fund because I spoke out against a board
> member?" That kind of concern can be mitigated through policy and
> governance, but is the kind of thing you want to tackle before it becomes
> an issue.
>
> Cheers,
>
> (a different) Alex
>
> On Thu, Jan 13, 2022 at 1:49 PM Steve Lee via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I think the word "The" is important. The title of the email and the name
>> of the fund is Bitcoin Legal Defense Fund. It is "a" legal defense fund;
>> not THE Bitcoin Legal Defense Fund. There is room for other funds and
>> strategies and anyone is welcome to create alternatives.
>>
>> I also don't see why Alex or anyone should be denied the opportunity to
>> comment on future soft forks or anything about bitcoin. Alex should have no
>> more or less right to participate and his comments should be judged on
>> their merit, just like yours and mine.
>>
>> On Thu, Jan 13, 2022 at 9:37 AM Prayank via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Hi Jack,
>>>
>>>
>>> > The main purpose of this Fund is to defend developers from lawsuits
>>> regarding their activities in the Bitcoin ecosystem, including finding and
>>> retaining defense counsel, developing litigation strategy, and paying legal
>>> bills. This is a free and voluntary option for developers to take advantage
>>> of if they so wish. The Fund will start with a corps of volunteer and
>>> part-time lawyers. The board of the Fund will be responsible for
>>> determining which lawsuits and defendants it will help defend.
>>>
>>> Thanks for helping the developers in legal issues. Appreciate your
>>> efforts and I understand your intentions are to help Bitcoin in every
>>> possible way.
>>>
>>>
>>> Positives that I see in this initiative:
>>>
>>> 1.Developers don't need to worry about rich scammers and can focus on
>>> development.
>>>
>>> 2.Financial help for developers as legal issues can end up in wasting
>>> lot of time and money.
>>>
>>> 3.People who have misused courts to affect bitcoin developers will get
>>> better response that they deserve.
>>>
>>>
>>> I had few suggestions and feel free to ignore them if they do not make
>>> sense:
>>>
>>> 1.Name of this fund could be anything and 'The Bitcoin Legal Defense
>>> Fund' can be confusing or misleading for newbies. There is nothing official
>>> in Bitcoin however people believe things written in news articles and some
>>> of them might consider it as an official bitcoin legal fund.
>>>
>>> 2.It would be better if people involved in such important funds do not
>>> comment/influence soft fork related discussions. Example: Alex Morcos had
>>> some opinions about activation mechanism during Taproot soft fork IIRC.
>>>
>>>
>>>
>>> --
>>> Prayank
>>>
>>> A3B1 E430 2298 178F
>>> _______________________________________________
>>> 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
>>
>
>
> --
>
>
> Alex Schoof
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220113/269236cd/attachment-0001.html>

2023-06-08 01:02:13

- reply

📅 Original date posted:2022-01-13
📝 Original message:I think the word "The" is important. The title of the email and the name of
the fund is Bitcoin Legal Defense Fund. It is "a" legal defense fund; not
THE Bitcoin Legal Defense Fund. There is room for other funds and
strategies and anyone is welcome to create alternatives.
I also don't see why Alex or anyone should be denied the opportunity to
comment on future soft forks or anything about bitcoin. Alex should have no
more or less right to participate and his comments should be judged on
their merit, just like yours and mine.
On Thu, Jan 13, 2022 at 9:37 AM Prayank via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi Jack,
>
>
> > The main purpose of this Fund is to defend developers from lawsuits
> regarding their activities in the Bitcoin ecosystem, including finding and
> retaining defense counsel, developing litigation strategy, and paying legal
> bills. This is a free and voluntary option for developers to take advantage
> of if they so wish. The Fund will start with a corps of volunteer and
> part-time lawyers. The board of the Fund will be responsible for
> determining which lawsuits and defendants it will help defend.
>
> Thanks for helping the developers in legal issues. Appreciate your efforts
> and I understand your intentions are to help Bitcoin in every possible way.
>
>
> Positives that I see in this initiative:
>
> 1.Developers don't need to worry about rich scammers and can focus on
> development.
>
> 2.Financial help for developers as legal issues can end up in wasting lot
> of time and money.
>
> 3.People who have misused courts to affect bitcoin developers will get
> better response that they deserve.
>
>
> I had few suggestions and feel free to ignore them if they do not make
> sense:
>
> 1.Name of this fund could be anything and 'The Bitcoin Legal Defense Fund'
> can be confusing or misleading for newbies. There is nothing official in
> Bitcoin however people believe things written in news articles and some of
> them might consider it as an official bitcoin legal fund.
>
> 2.It would be better if people involved in such important funds do not
> comment/influence soft fork related discussions. Example: Alex Morcos had
> some opinions about activation mechanism during Taproot soft fork IIRC.
>
>
>
> --
> Prayank
>
> A3B1 E430 2298 178F
> _______________________________________________
> 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/20220113/bd8698a1/attachment.html>

2023-06-07 20:21:22

- reply

📅 Original date posted:2019-10-23
📝 Original message:Hello everyone,
The schnorr/taproot/tapscript BIPs are ready for review at this point, and
we want to get as much in-depth review from as broad a range of people as
we can before we go further on implementation/deployment. Reviewing the
BIPs is hard in two ways: not many people are familiar with reviewing BIPs
in the first place, and there are a lot of concepts involved in the three
BIPs for people to get their heads around.
This is a proposal <https://github.com/ajtowns/taproot-review> for a
structured review period. The idea is that participants will be given some
guidance/structure for going through the BIPs, and at the end should be
able to either describe issues with the BIP drafts that warrant changes, or
be confident that they’ve examined the proposals thoroughly enough to give
an “ACK” that the drafts should be formalised and move forwards into
implementation/deployment phases.
Benefits of participating:
* Deeply understand schnorr and taproot
* Be a stakeholder in Bitcoin consensus development
* Support/safeguard decentralisation of Bitcoin protocol development
* Have fun!
If you are interested in participating, please sign up here
<https://forms.gle/stnJvHQHREdkaxkS8 >.
Special thanks to AJ Towns for doing most of the heavy lifting to get this
going!
Steve
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20191023/e864c58e/attachment.html>