Hi John,Honest is a misnomer, which is underpinning the concept. There is nothing dishonest about such payments. The downside is that the payer forgoes anonymity relative to the miner, but this is not dishonest, nor is mining one’s own transactions (where the represented “fee” implies nothing).
The fees paid to mine the set of transactions in a given block are known only to the miner that produced the block. Assuming that tx inputs less outputs represents an actual economic force is an error.eOn Dec 22, 2023, at 09:24, jlspc via bitcoin-dev wrote:Hi Antoine,
Thanks for your thoughtful
> -Original Message-
> From: Anthony Towns
> Subject: Re: [bitcoin-dev] Packaged Transaction Relay
> > > > > > Protocol cannot be defined on an ad-hoc basis as a "courtesy"
> > > > > BIPs are a courtesy in the first place.
> > > > I suppose if you felt that you were the authority then
On Sat, Oct 08, 2022, Anthony Towns via bitcoin-dev wrote:
> > > > Protocol cannot be defined on an ad-hoc basis as a "courtesy"
> > > BIPs are a courtesy in the first place.
> > I suppose if you felt that you were the authority then this would be
> > your perspective.
>
> You seem to think that
> From: Anthony Towns
> On Wed, Oct 05, 2022 at 09:32:29PM -0700, Eric Voskuil via bitcoin-dev
wrote:
> > Protocol cannot be defined on an ad-hoc basis as a "courtesy"
>
> BIPs are a courtesy in the first place.
I suppose if you felt that you were the autho
>> ...sendaddrv2 messages are only sent to nodes advertising version 70016 or
>> later (same as wtxidrelay)
> I don’t see this constraint in BIP155. Do you mean that addrv2 support was
> released in Core at the same time as wtxidrelay, or that it is an
> undocumented version constraint
>> [Regarding bandwidth waste: I've pointed out in years past that
>> breaking the Bitcoin versioning scheme creates a requirement that any
>> unknown message type be considered valid. Up until a recently-deployed
>> protocol change, it had always been possible to validate messages by
>> type. I
> Hi,
>
> Thanks for sharing your thoughts on packaged transaction relay.
Hello, thanks for the reply.
>> The sole objective, as expressed in the OP proposal, is to:
>> "Propagate transactions that are incentive-compatible to mine, even
>> if they don't meet minimum feerate alone."
>
> I
Thanks again for the feedback. Comments inline.
> On Sep 27, 2022, at 02:29, alicexbt wrote:
>
> Hi Eric,
>
>
>> If by "range" you mean a connected tx subgraph, I don't see why not. But
>> note that nodes only operate over signed txs. PSBT is a wallet workflow.
>
> Matt Corallo mentioned
_return policy. "non-standard"
txs are perfectly valid but get stuck very easily. I'll reiterate, any policy
beyond what is published via the protocol will cause the above problems.
e
> /dev/fd0
>
> [1]: https://bitcoinops.org/en/topics/package-relay/
> [2]: https://githu
If there’s no block reward, there’s no Bitcoin, so that’s moot. But setting
that aside. The business model of the state is to preserve the reward it
obtains from its own money. This is the reason for currency controls, which are
common.
e
> On Jul 20, 2022, at 03:17, Peter via bitcoin-dev
>
> On Jul 18, 2022, at 14:14, Erik Aronesty via bitcoin-dev
> wrote:
>
>
>>
>> subsidy to directly tie miner revenue to the total value of Bitcoin
>> makes it not exactly how we want to incentivise a service that keeps
>>
>
> again, this is meaningless. if the fees aren't enough to
> On Jul 10, 2022, at 07:17, alicexbt wrote:
> Hi ZmnSCPxj,
>
>
>> Thus, we should instead prepare for a future where the block subsidy must be
>> removed, possibly before the existing schedule removes it, in case a
>> majority coalition of miner ever decides to censor particular
In Bitcoin we use the term “supply“ as a reference to the number of coins
minted. This colloquialism is commonly conflated with the economic concept of
supply, and then injected into a supply/demand relation as if it had the same
applicability. Economically supply refers to desire to sell,
Yet you posted several links which made that specific correlation, to which I
was responding.
Math cannot prove how much coin is “lost”, and even if it was provable that the
amount of coin lost converges to the amount produced, it is of no consequence -
for the reasons I’ve already pointed
To clarify, price inflation is not caused by market production. Attributing the
observed lack of inflation (eg fee %) to loss is an assumed relation.
Even if the amount of loss was known (which it is not), there remains an
assumption in the correlation of non-lost coins to price. Demand
> Due to lost coins, a tail emission/fixed reward actually results in a stable
> money supply. Not an (monetarily) inflationary supply.
This observation is not a proof of lost coins, that is an assumption. It is the
provable consequence of market, as opposed to monopoly, production.
Without a performance requirement there is no reason you can’t store the BIP39
words in any order you want. So it’s certainly possible, just brute force the
recovery. If you have less than a second vs. a few days then it’s a different
question.
e
> On Jul 7, 2022, at 18:48, Bram Cohen via
ogy, that provide
>>> > security.
>>>
>>> Yes, and these forces don't prevent double-spend / 51% attacks if the
>>> amounts involved are greater than the incentives.
>>>
>>> In addition to "utility", lowering the block size could he
essure and double-spend security while
> reducing the burden on node operators.
>
> Changes to inflation are, very likely, off the table.
>
>
>
>> On Thu, Jul 7, 2022 at 12:24 PM Eric Voskuil via bitcoin-dev
>> wrote:
>>
>>
>> > On Jul 7, 202
> On Jul 7, 2022, at 07:13, Peter Todd via bitcoin-dev
> wrote:
>
> On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev
> wrote:
>> Billy,
>>
>> Proof of work and the difficulty adjustment function solve literally
>> everything you are talking about already.
>
>
> On Jun 21, 2022, at 12:28, Keagan McClelland via bitcoin-dev
> wrote:
>
>
> > 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
Hi Suhas/Gloria,
Good questions. I've started a new thread because it became something else...
Various ideas about packaging seem to be focused on the idea of an atomic
message that is gossiped around the network like a transaction or block. From
my perspective that seems to create a set of
> From: bitcoin-dev On
Behalf
> Of Anthony Towns via bitcoin-dev
> Sent: Wednesday, May 25, 2022 11:56 AM
> So the other thing is what happens if the peer announcing packages to us
is
> dishonest?
>
> They announce pkg X, say X has parents A B C and the fee rate is garbage.
But
> actually X has
The set of txs is the graph. Anything else would just reproduce the tx graph
which must be traversed in any case.
Similarly the set of txs is the fee, the sigops, the size, and the weight. The
only information required by packaging is the association of the txs with each
other for the purpose
Good evening ZmnSCPxj,
Sorry for the long delay...
> Good morning e,
>
> > Good evening ZmnSCPxj,
> >
> > For the sake of simplicity, I'll use the terms lender (Landlord), borrower
> > (Lessor), interest (X), principal (Y), period (N) and maturity (height
> > after N).
> >
> > The lender in
Good evening ZmnSCPxj,
For the sake of simplicity, I'll use the terms lender (Landlord), borrower
(Lessor), interest (X), principal (Y), period (N) and maturity (height after N).
The lender in your scenario "provides use" of the principal, and is paid
interest in exchange. This is of course
It looks like you are talking about lending where the principal return is
guaranteed by covenant at maturity. This make the net present value of the loan
zero.
e
> On May 3, 2022, at 11:03, Chris Belcher via bitcoin-dev
> wrote:
>
> Hello ZmnSCPxj,
>
> Such a system will have to be
> > Even if it is not needed, it is kind of "free" if you take transaction size
> > into account
>
> But it would require an on-chain transaction. We don't want 6 billion people
> to have to send an on-chain transaction all in the same week in order to
> register their preference on
> On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev
> wrote:
>
>
>> Dear Bitcoin Developers,
>
>> -When I contacted bitInfoCharts to divide the first interval of addresses,
>> they kindly did divided to 3 intervals. From here:
>>
> On Feb 1, 2022, at 00:32, Bram Cohen wrote:
>
>> On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil wrote:
>>
>>
On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev
wrote:
>>> Is it still verboten to acknowledge that RBF is normal behavior and
>>> disallowing it is the feature,
> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev
> wrote:
…
> Is it still verboten to acknowledge that RBF is normal behavior and
> disallowing it is the feature, and that feature is mostly there to appease
> some people's delusions that zeroconf is a thing? It seems a bit overdue
> BIP8 is also BIP9 based, and ST is its own thing that's neither BIP8 nor
> BIP9, so characterization one way or another is moot IMO.
For a selective definition of “based” you can draw any conclusion you desire.
However I was very clear, as was Luke, and the history on this issue is equally
> -Original Message-
> From: Luke Dashjr
> Sent: Tuesday, January 18, 2022 2:10 PM
> To: e...@voskuil.org
> Cc: 'Bitcoin Protocol Discussion'
> Subject: Re: [bitcoin-dev] CTV BIP review
>
> On Tuesday 18 January 2022 22:02:24 e...@voskuil.org wrote:
> > The only material distinction
I won't comment on CTV at this point, but these comments on BIP9 and BIP8
deserve a response, given the intense obfuscation below.
The only material distinction between BIP9 and BIP8 is that the latter may
activate without signaled support of hash power enforcement.
As unenforced soft forks are
Agree ZmnSCPxj
Hi lisa,
I'm all for removing it from memory. :) Did that a while ago. We just call it
the transaction pool.
There will always be unconfirmed transactions floating around (even just from
reorgs). Best to store them somewhere. Disk is cheap, block distribution (e.g.
compact)
Switching pools has always been possible. But the largest pool is the most
profitable, and centralized pools are easily controlled. Decoupling selection
without decoupling payout is an engineering change without a pooling pressure
change.
e
> On Sep 6, 2021, at 10:01, David A. Harding wrote:
It doesn’t centralize payment, which ultimately controls transaction selection
(censorship).
e
> On Sep 6, 2021, at 08:25, David A. Harding via bitcoin-dev
> wrote:
>
> On Wed, Sep 01, 2021 at 11:46:55PM -0700, Billy Tetrud via bitcoin-dev wrote:
>> How would you compare this to Stratum v2?
All reasonable.
e
> Okay, it seems to me that what you are saying is something like this:
>
> > Proof-of-reserves would (partially) work for a "pure" warehousing service
> (i.e. user pays some fee, service keeps money and provides proofs that
> money is kept).
> > However, "pure" warehousing is
> Good morning e,
Good afternoon Z.
> > Any expectation of interest implies borrowing, in other words, a loan to
> the bank.
>
> Perhaps this is the key point of contention?
I'm not sure, but from my observations it's long been a point of confusion in
Bitcoiner understanding of banking.
discussing these things honestly.
I'm not interested in allowing flawed concepts to be perpetuated without
question. This is just a drain on capital that could be put to much better use.
How many times have I heard the oxymoron "full reserve banking", and how much
capital has been b
> On Jul 9, 2021, at 10:44, Billy Tetrud wrote:
>
> > there is an unsupportable leap being made here
>
> You think that because you're misinterpreting me. I'm in no way claiming that
> any solvent company can prove it, I'm simply claiming that any company can
> prove that they have bitcoin
> On Jul 7, 2021, at 01:20, Billy Tetrud via bitcoin-dev
> wrote:
> But people can certainly pull their money out of companies that can't show
> solvency.
As I pointed out previously there is an unsupportable leap being made here
between a vault (money warehouse) and any company (including
> you should check out some of the earlier work done here:
>
> https://github.com/olalonde/proof-of-solvency#assets-proofNothing in this
Nothing here refutes what I have said. Furthermore it relies on the
assumption that all assets and liabilities are provable. This is clearly
prohibitive.
>
> @Eric
> Auditability Fallacy
>
> > A solvency audit requires simultaneous (atomic) proof of both the full
> > amount of the asset held by a custodian and the securities issued against
> > it.
>
> > in the case where the security is issued on a distinct public chain the
> > atomicity
https://github.com/libbitcoin/libbitcoin-system/wiki/Auditability-Fallacy
> On Jul 5, 2021, at 21:54, ZmnSCPxj wrote:
>
> Good morning Billy,
>
>
>>
>>> The two participants in the channel can sign a plaintext containing their
>>> node pubkeys and how much each owns
>>
>> Sure, but even
If only one could prove that he won’t get into a boating accident.
e
> On Jul 5, 2021, at 16:26, ZmnSCPxj via bitcoin-dev
> wrote:
>
> Good morning Billy,
>
>> I wonder if there would be some way to include the ability to prove balances
>> held on the lightning network, but I suspect that
> On Jun 30, 2021, at 05:45, Zac Greenwood wrote:
>
>
> Eric,
>
> > A million nodes saying a transaction is invalid does nothing to enforce
> > that knowledge
>
> It does. Nodes disregard invalid transactions and invalid blocks as if they
> never existed. It is not possible for any party
A million nodes saying a transaction is invalid does nothing to enforce that
knowledge.
An economic node is a person who refuses to accept invalid money. A node only
informs this decision, it cannot enforce it. That’s up to people.
And clearly if one is not actually accepting bitcoin for
> From: Jorge Timón
>> "Soft forks aren’t compatible without miner enforcement"
> Compatible with what?
There is a good summary of what is meant by this term in BIP141:
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki
"Backward compatibility
As a soft fork, older software will
Hi Prayank,
> So majority hash power not following the consensus rules can result in chain
> split?
Any two people on different rules implies a chain split. That’s presumably why
rule changes are called forks. There is no actual concept of “the rules” just
one set of rules or another.
All good questions.
> Is the goal here to do what the economic majority wants, or some other group?
> If so, do you think we have an accurate way of measuring what the economic
> majority wants?
It’s important that people understand that “economic” does not refer to people
interested
t;>> Developers obviously care about bitcoin and have an incentive (personal
>> >>>> and probably financial) to do it right. And miners have both an
>> >>>> incentive to keep the system healthy, as well as an incentive to mine on
>> >>>&g
t;>>> I have not objected to anyone splitting. As I said, a split is always
>>>>> possible, and of course has been done on a large scale. It is only the
>>>>> misleading statements about inherent soft fork “compatibility” and the
>>>>> implicat
try to avoid
> such a split.
> Users decide the rules, not miners nor developers.
>
>> On Sun, Jun 27, 2021 at 12:05 AM Eric Voskuil via bitcoin-dev
>> wrote:
>>
>> Ultimately there is only one answer to this question. Get majority hash
>> power support.
Ultimately there is only one answer to this question. Get majority hash power
support.
Soft fork enforcement is the same act as any other censorship enforcement, the
difference is only a question of what people want. Given that there is no
collective “we”, those wants differ. Bitcoin resolves
For some definitions of “block”.
Without majority hash power support, activation simply means you are off on a
chain split. Anyone can of course split off from a chain by changing a rule
(soft or otherwise) at any time, so this is a bit of an empty claim.
Nobody can stop a person from
https://github.com/libbitcoin/libbitcoin-system/wiki/Efficiency-Paradox
https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Memory-Fallacy
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://github.com/libbitcoin/libbitcoin-system/wiki/Proof-of-Stake-Fallacy
> On May 7, 2021, at 15:50, SatoshiSingh via bitcoin-dev
> wrote:
>
> Hello list,
>
> I am a lurker here and like many of you I worry about the energy usage of
> bitcoin mining. I understand a lot mining happens
You may activate any time you want.
e
From: bitcoin-dev On Behalf Of
Claus Ehrenberg via bitcoin-dev
Sent: Wednesday, April 7, 2021 6:42 AM
To: Rusty Russell ; Bitcoin Protocol Discussion
Subject: Re: [bitcoin-dev] March 23rd 2021 Taproot Activation Meeting Notes
As a user, I think
> If you actually believe the operation of consensus and the discussion
> relevant to that is a mundane or philosophical dissection of people's ability
> to grasp a humorous while on-topic but obligatorily unnecessary conversation
> you may prefer if you enquire how Bitcoin is
I’m pretty sure it’s subtle mockery. Even a legit title doesn’t warrant
additional attention.
e
> On Mar 12, 2021, at 14:02, R E Broadley via bitcoin-dev
> wrote:
>
> Can I just point out (to those addressing James as Lord/Excelency/etc
> that he isn't noble nor a Lord, so just wanted to
One should not assume that those trying to avoid a chain split are against
Taproot.
There is a concerning widespread misperception in the community at large that
soft forks are inherently “backward compatible”. To many people this seems to
mean that, even without hash power enforcement,
The most sensible approach I’ve seen yet.
e
> On Mar 6, 2021, at 01:29, Anthony Towns via bitcoin-dev
> wrote:
>
> On Fri, Mar 05, 2021 at 05:43:43PM -1000, David A. Harding via bitcoin-dev
> wrote:
>> ## Example timeline
>> - T+0: release of one or more full nodes with activation code
>> -
FYI it’s generally considered bad form repost a private thread, especially one
you initiate.
...
It’s typically more effective to generate some community support before
actually submitting a BIP. Otherwise the process gets easily overwhelmed. This
is likely why you aren’t getting a response.
Hi Andrew,
Do you mean that you can reduce the cost of executing the cryptography at a
comparable level of security? If so this will only have the effect of
increasing the amount of it that is required to consume the same cost.
Mike was wrong about a number of things, and in the end decided that Bitcoin
was pointless, as people could not defend it against the state. He used this as
the basis for his defense of large blocks and centralized mining. When that
didn’t work out he quit, to work on centralized systems.
"The Australian",
>
> This discussion list is serious stuff, please stop making noise. Fungibility
> is a desirable property, anyway.
>
> Thank you!
>
>> On Wed, Mar 3, 2021 at 12:04 PM Eric Voskuil via bitcoin-dev
>> wrote:
> > cons
tion, it is
absolutely no concern of yourself or any other party that this transaction has
occured.
Bitcoin is digital cash.
Daniel Edgecumbe | esotericnonsense
em...@esotericnonsense.com <mailto:em...@esotericnonsense.com> |
https://esotericnonsense.com
On Mon, Mar 1, 2021, at 22:37,
I personally don’t like the term 51% attack as applied to censorship. A miner
is free to mine or not mine any transactions it wants (censor). The term attack
is better reserved for stealing from someone (reclaiming spends using hash
power), as it implies a moral distinction.
But 51% attack is
To clarify, it is the soft fork enforcement by majority hash power that is the
51% attack, not the stopping of it. Majority hash power censors non-conforming
transactions. To counter it requires only a non-censoring majority to continue
mining.
It is correct that the purpose of supermajority
To be clear, is this a NACK because Taproot reduces “transparency” (increases
privacy) on the chain (“maintaining consensus” is obviously an argument against
any protocol change, so that’s a red herring)?
And is it your theory that only an “honest” (statute abiding) person should
have
On Sun, Feb 28, 2021 at 10:18 AM Leo Wandersleb via bitcoin-dev
mailto:bitcoin-dev@lists.linuxfoundation.org> > wrote:
> Only headers need to be downloaded sequentially so downloading relevant
> blocks from one node is totally possible with gaps in between.
In fact this is exactly how
I think it has been shown that an understanding of reasonableness is not
universal, making any assertion about it as a collective goal kind of
self-defeating. The question is what is achievable, not what is reasonable. I’m
not making any value judgements here. Simply pointing out that anything
In the attempt to change consensus rules there is a simple set of choices:
1) hard fork: creates a chain split
2) soft fork: creates a chain split
3) 51% attack: does not create a chain split
The presumption being that one can never assume 100% explicit adoption of any
rule change.
A 51%
Hi Sebastian,
It's important to consider here that anonymity is the reason fees are
incorporated into transactions. One must generally trust the party with whom
one transacts. But since integral fees are paid to any miner, this does not
apply to fees. In paying fees externally one must find
I see no requirement for anything here apart from exchanging a list of
supported “features”. Conditionally hiding a feature provides no benefit. Any
peer that wants it can get it (obfuscation being weak security), and otherwise
it’s a non-issue.
e
> On Aug 24, 2020, at 13:22, Jeremy wrote:
>
I said security, not privacy. You are in fact exposing the feature to any node
that wants to negotiate for it. if you don’t want to expose the buggy feature,
then disable it. Otherwise you cannot prevent peers from accessing it.
Presumably peers prefer the new feature if they support it, so
> On Aug 21, 2020, at 13:45, Matt Corallo wrote:
>
> This seems to be pretty overengineered.
I agree. In fact all proposals I’ve seen on this are over engineered.
> Do you have a specific use-case in mind for anything more than simply
> continuing the pattern we've been using of sending a
> On Aug 21, 2020, at 15:16, Matt Corallo wrote:
>
> Hmm, could that not be accomplished by simply building this into new
> messages? eg, send "betterprotocol", if you see a verack and no
> "betterprotocol" from your peer, send "worseprotocol" before you send a
> "verack".
>
> Matt
>
>>
Service bits are advertised, protocol support is not.
https://en.bitcoin.it/wiki/Protocol_documentation#Network_address
e
> On Aug 21, 2020, at 14:08, Jeremy wrote:
>
>
> Actually we already have service bits (which are sadly limited) which allow
> negotiation of non bilateral feature
I’m pretty sure one can run whatever they want even without a BIP. There is
nobody here to do any “allowing”. On the other hand, standards development is
tedious for good reason.
Generally speaking, overloading is a primary source of complexity (creating
more branches in code and human
Hi Anthony,
This is what I was implying in my last post (the reference to the unnecessary
overload of message typing). However, if one imagines a sequence diagram for
this communication it becomes obvious that all such messages are 100% redundant
with verack.
e
> On Aug 20, 2020, at 19:37,
> On Aug 18, 2020, at 11:25, Matt Corallo wrote:
>
> On 8/18/20 2:11 PM, Eric Voskuil wrote:
> - snip -
>>> Still, I think we're talking pedantics here, and not in a useful way.
>> Not to be pedantic, but I don’t know what that means.
>
> It means that part of the discussion is not useful, and
> On Aug 18, 2020, at 10:26, Matt Corallo wrote:
>
> There are several cases where a new message has been sent as a part of a
> negotiation without changing the protocol version.
Such as?
> You may chose to ignore that, but that doesn't mean that it isn't an
> understood and even relied
“Bitcoin protocol has always expected clients to ignore unknown messages”
This is not true. Bitcoin has long implemented version negotiation, which is
the opposite expectation. Libbitcoin’s p2p protocol implementation immediately
drops a peer that sends an invalid message according to the
Hi Suhas,
It seems to me that your first two paragraphs contradict each other, so I’m not
sure we have understanding. As you say in the first paragraph, a peer would
never get messages that it does not understand, so there is no chance that
missing a protocol change would matter.
In case it’s
A requirement to ignore unknown (invalid) messages is not only a protocol
breaking change but poor protocol design. The purpose of version negotiation is
to determine the set of valid messages. Changes to version negotiation itself
are very problematic.
The only limitation presented by
Mining is a lottery.
e
> On Mar 22, 2020, at 07:10, LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev
> wrote:
>
>
> There seems to be the real possibility that miners are simply trying to
> optimise mining profit by limiting the average hash rate during the
> retargeting, saving some
> On Nov 8, 2019, at 11:16, David A. Harding via bitcoin-dev
> wrote:
>
> On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via bitcoin-dev
> wrote:
>> In the current draft, witness v1 outputs of length other
>> than 32 remain unencumbered, which means that for now such an
>>
e risk of a damaged car that
>>>> > refrain from becoming drivers until insurance allows them to lower the
>>>> > worst case scenario of a damaged car.
>>>> >
>>>> > -JW
>>>> >
>>>> >
>>>>
>> This is a restatement of the assumption I questioned. Hash rate increase
>> >> does not imply unprofitability. The new rig should be profitable.
>> >>
>> >> What is being assumed is a hash rate increase without a proportional
>> >> block reward
by buying insurance for this
>>> possibility.
>>> And the existence of attractive insurance contracts would lower the barrier
>>> to entry for new competitors in mining and this would increase bitcoins
>>> security.
>>> -JW
>>> ‐‐‐ Original
d this would increase bitcoins
> security.
>
> -JW
>
>
>
>
> ‐‐‐ Original Message ‐‐‐
>> On Sunday, October 20, 2019 1:03 AM, Eric Voskuil via bitcoin-dev
>> wrote:
>>
>> Hi Lucas,
>>
>> I would question the assumption
I agree, thanks.
FWIW I’ve never been a fan of the ‘reject’ message, or its implementation.
https://github.com/bitcoin/bips/wiki/Comments:BIP-0061
e
> On Oct 18, 2019, at 18:46, David A. Harding wrote:
>
> On Thu, Oct 17, 2019 at 01:16:47PM -0700, Eric Voskuil via bitcoin-
Hi Lucas,
I would question the assumption inherent in the problem statement. Setting
aside variance discount, proximity premium, and questions of relative
efficiency, as these are presumably already considered by the miner upon the
purchase of new equipment, it’s not clear why a loss is
As this is a P2P protocol change it should be exposed as a version increment
(and a BIP), not just as a conditional service. If the intent is to retain this
protocol indefinitely, exposing it conditionally, then a service bit would make
sense, but it remains a protocol change.
BIP61 is
Thanks for adding this to the record.
And for the record I’ll reiterate here, as I did with BIP90, that this is a
hard fork.
e
> On Aug 16, 2019, at 12:06, Peter Todd via bitcoin-dev
> wrote:
>
>> On Fri, Aug 16, 2019 at 11:23:37AM -0400, John Newbery via bitcoin-dev wrote:
>> Once a
> On Jul 18, 2019, at 20:45, ZmnSCPxj wrote:
>
> Good morning Kenshiro,
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
>> On Thursday, July 18, 2019 11:50 PM, Kenshiro [] wrote:
>>
>> Hi all,
>>
> A 51% attack under proof-of-work is only possible, in
> On Jul 17, 2019, at 03:10, Kenshiro [] via bitcoin-dev
> wrote:
>
> Hi ZmnSCPxj,
>
> I'm based on the more evolved implementation of PoS that I know, which is PoS
> v3.0 and it's currently implemented in several coins:
>
>
1 - 100 of 252 matches
Mail list logo
