Hi alicexbt
The vulnerability reporting process requires communication and resolution via a
small group of individuals [0] rather than through open collaboration between
any contributors on the repo. There are clearly examples where the process is
critically needed, the most obvious past
i agree 100%. effective communication is challenging, especially in an
environment like this. that being said, alicexbt is probably right that
we
- probably need a well written spec, RFC-style perhaps
- need more anon or nym maintainers where the online reputation isn't
trivially linked to
On 5/11/23 04:02, vjudeu via bitcoin-dev wrote:
Every transaction paying "fee > sum" can be replaced by N transactions
paying "fee <= sum", where the sum of all fees will be the same.
These N transactions will generally have a lower feerate than the
original, and the lowest feerate of the N
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
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
Regardless of the submitter's rationale, it is easy to work around any rule
that denies mempool inclusion based on fee proportion: if you have plenty,
add inputs from your own wallet and return to yourself; if not, borrow them
and return to the lender, maybe with interest.
On Thu, May 11, 2023 at
Thanks for this Andrew.
> 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.
Some individuals who will stay anonymous and who were more familiar with
Vasil's work
if we forget about backward compatibility and the impact of other types of
transactions, then the following two options would be possible:
a) allocate only up to 10% of the space in the block for non-standard
transactions - then all senders of non-standard transactions will compete
with each other
Another use case for paying more fees than outputs is to incentivize
honest mining when Bitcoin is under a state-level censorship attack.
If it's really important to me that my transaction goes through, I
might be willing to set a fee at 99x the output value. It's the only
way bitcoin could work
On 5/9/23 09:32, Erik Aronesty via bitcoin-dev wrote:
obviously it's easy enough to evade if every non-economic user simply > keeps enough bitcoin around and sends it back to himself > > so
maybeit's a useless idea? but maybe that's enough of a hassle to stop >
people (it certainly breaks
Erik,
I'm curious about what you believe to be "non-economic" txs. As far as I
can tell, any transaction included in the blockchain is economically
motivated by the very evidence of fees paid. That said, for the sake of
argument if we assume that there exists a category of information that
Concept ACK,
The only way we can hope to have productive discussion is to minimize the
amount of effort spent in miscommunication especially that which arises
from unclear terminology. Which exact words refer to which meanings is
somewhat arbitrary, (look at math, particularly abstract math), but
On Thu, 11 May 2023 at 13:12, AdamISZ wrote:
>
> A sidebar, but it immediately brings it to mind: the canonical adaptor
> based swap, you can do it with only one half being multisig like this,
> right? Alice can encrypt the single-key signature for her payment to Bob,
> with the encryption key
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
> confused. the rule was "cannot pay a fee > sum of outputs with
> consideration of cpfp in the mempool"
> your example is of someone paying a fee "< sum" which wouldn't be blocked
Every transaction paying "fee > sum" can be replaced by N transactions paying
"fee <= sum", where the sum of
Hi Lloyd,
> Yes but suppose you do *not* create another signature adaptor or otherwise on
> m. Since you've only generated one adaptor signature on m and no other
> signatures on m there is no possibility that a signature on m that appears
> under your key would not reveal y to you. This is an
confused. the rule was "cannot pay a fee > sum of outputs with
consideration of cpfp in the mempool"
your example is of someone paying a fee "< sum" which wouldn't be blocked
note: again, i'm not a fan of this, i like the discussion of "bitcoin as
money only" and using fee as a lever to do
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
> 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
19 matches
Mail list logo
