> As a result, there are incentives structure distorted and critical
inefficiencies/vulnerabilities (e.g. misallocation of block space,
blockspace value destruction, disincentivized simple transaction,
centralization around complex transactions originators).
Can you please describe the mechanism
I also think that good archives are extremely important. Far more important
than being a medium of discussion is capturing all of that discussion for
posterity. An unbelievable amount of knowledge capital has been built up in
the mailing list over the years and given that Bitcoin is a system that
There is an open question as to whether or not we should figure out a way
to price space in the UTXO set. I think it is fair to say that given the
fact that the UTXO set space remains unpriced that we actually have no way
to determine whether some of these transactions are spam or not. The UTXO
Hi Antoine,
Thank you for the effort you've put towards this. I generally agree that a
smooth functioning Lightning Network is of greater importance than advanced
contracting capabilities. However, as I dive deeper into some of the more
ambitious goals for LN development I am learning that a
Good day Yuri,
This is a very cool idea. After reviewing the repository it seems that
there lacks a BIP style specification for this, so it is possible that some
of my takeaways may not be correct but I figured I'd comment with some
observations anyway. Feel free to correct me where I've made a
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
> The PoW security of Bitcoin benefits all Bitcoin users, proportional to
the
value of BTC they hold; if Bitcoin blocks aren't reliably created the value
of
*all* BTC goes down. It doesn't make sense for the entire cost of that
security
to be paid for on a per-tx basis. And there's a high chance
> will never be justifiable simply because you and some of your friends
think it is totally cool and might make more people like you or give your
friends funding.
100%
But while the OP may have given less than ideal reasons for things like
covenants, it does not broadly characterize the reasons
> One must also analyze all the covenants that one *could* author using a
primitive
So as I've been contemplating this more, I'm realizing that a calculus of
covenants themselves may not make as much sense as a broader calculus of
Bitcoin transactions as a whole. I think this comment that you
> > > To me the most scary one is visacoin, specially seeing what happened
in canada and other places lately and the general censorship in the west,
the supposed war on "misinformation" going on (really a war against truth
imo, but whatever) it's getting really scary. But perhaps someone else can
cuss for exhaustion here in the list.
>
> I don't think flagging transactions would be a good method to measure this
> sort of thing. You are handing important technical discussions into the
> hands of those who have no idea about the subject.
>
> Felipe.
>
> On Tue, A
Hi all,
Alongside the debate with CTV right now there's a second debate that was
not fully hashed out in the activation of Taproot. There is a lot of
argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
etc. A significant reason for the breakdown in civility around this debate
ony Towns wrote:
> On Mon, Apr 25, 2022 at 10:11:45AM -0600, Keagan McClelland via
> bitcoin-dev wrote:
> > > Under *any* other circumstance, when they're used to activate a bad
> soft
> > > fork, speedy trial and bip8 are the same. If a resistance method works
> &
Hi AJ,
> Under *any* other circumstance, when they're used to activate a bad soft
fork, speedy trial and bip8 are the same. If a resistance method works
against bip8, it works against speedy trial; if it fails against speedy
trial, it fails against bip8.
IIRC one essential difference between ST
Good day Michael,
> and discuss working on an additional release that if run may ultimately
reject blocks that signal for CTV.
This seems silly to me.
The structure of CTV is imbuing an OP_NOP with script semantics. Resisting
changes that don't affect you is not consistent with the ideals of
> But whether or not it is a basic principle of general software
engineering kind of misses the point. Security critical software clearly
isn't engineered in the same way as a new social media app. Bugs are easily
reverted in a new social media app.On top of that we aren't just dealing
with
> That is in fact true of Proof of Work as well. If a colluding coalition
of miners with more than 50% of the hashrate want to censor transactions,
they absolutely can do that by orphaning blocks that contain transactions
they want to censor. This is not different in proof of stake.
This power
> Premise: There is a healthy exchange market for PoS Coin X with tens of
thousands of participants bidding to buy and sell the coin for other
currencies on the market.
The difference here though is that Proof of Stake allows the quorum of coin
holders to block the exchange of said coins if they
>One needs a cost/benefit analysis, not just an account of the cost. For
example, if PoW could do calculations that are otherwise useful (maybe
solve a queue of standardized math-jobs, such as climate simulations) there
would be more benefit, or, let's say the data storage in proof-of-space is
A few things jump out at me as I read this proposal
First, deriving the hardness from capex as opposed to opex switches the
privilege from those who have cheap electricity to those who have access to
chip manufacturers/foundries. While this is similarly the case for Bitcoin
ASICS today, the
In principle the idea of making your transactions not mineable except by
miners who follow some particular practice is something that can and should
be discussed. For instance, it could help give economic signals for future
soft forks such that users can declare preference in a costly, sybil
To reiterate some of the points here. My problem with proof of stake is
twofold.
1. It requires permission of coin holders to enter into the system. This is
not true of proof of work. You may even attempt (though not successfully) a
proof of work with pencil and paper and submit the block from a
LORD HIS EXCELLENCY,
This isn't different with Taproot either. When you spend a P2SH output you
reveal the script. In Taproot you reveal the portion of the script that is
relevant to allowing you to spend it. There is no value to specifying the
other possible conditions that could have moved the
The assumption of malice on the part of those of us supporting a UASF is
tragic and frankly ridiculous. Many of us backed off of the effort the
second that this Speedy Trial solution was proposed in order to dislodge
the gridlock on the LOT value. I can't say for certain that 100% of those
working
> A large portion of BTC is already mined through AWS servers and non-asic
specific hardware anyways. A majority of them would benefit from a hybrid
proof, and the fact that it is hybrid in that manner wouldn't
disenfranchise currently optimized mining entities as well.
My instincts tell me that
It is important to understand that it is critical for the work to be
"useless" in order for the security model to be the same. If the work was
useful it provides an avenue for actors to have nothing at stake when
submitting a proof of work, since the marginal cost of block construction
will be
As one of the folks that prefers LOT=true I can certainly attest to the
fact that at least some of us would be willing to do a flag day activation
instead. As far as I'm concerned, flag day does not give a very small
percentage of the user base (5-10% of minerz) the ability to veto a change
that
> Personally I consider this counterproductive. Apart from the complexity,
it’s not healthy. And the chain grows linearly with storage cost falling
exponentially, leading to a straightforward conclusion.
The motivation for this change is not to encourage full archival nodes to
prune, but to make
Hi all,
I've been thinking for quite some time about the problem of pruned nodes
and ongoing storage costs for full nodes. One of the things that strikes me
as odd is that we only really have two settings.
A. Prune everything except the most recent blocks, down to the cache size
B. Keep
I wanted to follow up on what Jeremy and others are saying regards finding
consensus on LOT. I've seen a few other opinions saying that finding
consensus on the LOT value is far more important than what the LOT value
actually is. This makes sense because if 100% of economic activity is
running the
Hi all,
I think it's important for us to consider what is actually being considered
for activation here.
The designation of "soft fork" is accurate but I don't think it adequately
conveys how non-intrusive a change like this is. All that taproot does
(unless I'm completely missing something) is
I was just looking into the conventions around this yesterday! It seems
like this proposal is mostly just formalizing stuff that is already a tacit
standard. I'm glad to see that someone is documenting it somewhere more
"official".
It appears consistent with
> It should be therefore a top priority to make the UX of connecting my
mobile LN client to my home full node extremely easy, so that centralised
services can't improve much on that step. Especially if I already run a
full node.
For what it's worth, this is a main research area for us at Start9
> The RPC interface in Bitcoin Core, and others, is not great for this
> because it exposes a lot of functionality that isn't necessary and
> introduces risks.
This is actually somewhat my point. If the RPC interface was good for this
and *didn't* introduce risks, we could just use that and be
I think that one of the solutions here is to have light clients choose
their full node tethers explicitly. Even if you think it is unrealistic to
have everyone run their own node (fwiw, I don’t), there is still a trust
model where you can pick your trusted source.
This way you could have many
Hi Antoine,
Consensus capture by miners isn't the only concern here. Consensus capture
by any subset of users whose interests diverge from the overall consensus
is equally damaging. The scenario I can imagine here is that the more light
clients outpace full nodes, the more the costs of security
37 matches
Mail list logo
