Hey all,
I am proposing an informational BIP to standardize the term "bits". The
term has been around a while, but having some formal informational standard
helps give structure to how the term is used.
https://github.com/jimmysong/bips/blob/unit-bias/bip-unit-bias.mediawiki
Entire BIP included
Stupid question time:
Why don't we have multiple testnets?
On Thu, Aug 30, 2018 at 3:31 PM Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Thu, Aug 30, 2018 at 12:58:42PM +0530, shiva sitamraju via bitcoin-dev
> wrote:
> > Hi,
> >
> > Testnet is now 1411795 blocks
Hi Russell,
This is probably a dumb question, but I'd like to get some clarity on your
proposal.
OP_CHECKSIGFROMSTACKVERIFY would pop off a signature, message and pubkey.
Presumably, the message would then have to get constructed as part of the
Script execution. What would such a message look lik
Hey all,
I wanted to propose a new key in the global context for BIP174,
Partially-Signed Bitcoin Transactions.
= Rationale
Each signer should make sure that the inputs being referenced in the PSBT
exist (with the exception of a Proof-of-Reserves input). In order to do
this, it's critical to kno
Hey everyone, This is an idea that I had about Segwit and Gregory's
proposal from yesterday that I wanted to run by everyone on this list. I'm
not at all sure what this would mean for non-upgraded nodes on the network
and would like feedback on that. This is not a formal BIP as it's a
modification
I've gotten feedback from Adam Back that you actually don't need all 32
bits in the header for overt ASICBoost, so I'm modifying my proposal. Of
the 32-bit version field, bits 16 to 23 are reserved for miners, the
witness commitment stays as defined in BIP-141 except that it's now
required. BIP9 th
Praxeology Guy,
Why would the actual end users of Bitcoin (the long term and short term
> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
> policy in order to make their money more vulnerable to 51% attack?
>
Certainly, if only one company made use of the extra nonce spac
Pavel,
Until all miners update (firmware or hardware), the change encourages
> large difference in mining efficiency. And IMO it gives another
> advantage to large mining operations in general.
>
Certainly, there would have to be changes for stratum, pool software, etc.
But the monetary incentive
CBoost and the patents are licensed freely to everyone).
>
> Luke
>
>
> On Saturday, April 08, 2017 12:05:16 AM Jimmy Song via bitcoin-dev wrote:
> > I've gotten feedback from Adam Back that you actually don't need all 32
> > bits in the header for overt ASICBo
>
>
> No, it isn't allowed right now. Doing it wouldn't invalidate blocks, but it
> would clearly be an attack on the network and cause harm. The same as if
> miners were to maliciously mine only empty blocks.
>
>
What's your definition of "allowed" then? Because a miner definitely can
mine only em
Pavel,
> I agree. I only wanted to make clear, that the impact would be
> significant. Lot of parties would be involved with nonequivalent
> starting positions.
>
>
I agree with you. I believe nonequivalent starting positions are the norm
in mining, not the exception and hence don't believe this
ics too.
>
> To reiterate, whether all miners use asicboost or only a subset of
> them, I remain unconvinced that provides any additional security to
> the network (to be more precise whether that makes "tx history harder
> to rewrite"), even if it results on the hashrate c
itive advantage from
>>> having asicboost more intergrated with the sha256d asics too.
>>>
>>> To reiterate, whether all miners use asicboost or only a subset of
>>> them, I remain unconvinced that provides any additional security to
>>> the network (to be
I've changed the proposal so only 8 bits are given to grinding so something
like 20 bits are available for signaling.
I have to say I'm at a loss here as to what's next? Should I make a new BIP
or try to convince the authors of BIP141 to modify their BIP? Could someone
inform me on the next part o
In any case, I'm happy to close this discussion until there's some
indication that more miners would accept segwit as a result of this change.
Jimmy
On Tue, Apr 11, 2017 at 4:25 PM, Jorge Timón wrote:
> On Tue, Apr 11, 2017 at 4:40 PM, Jimmy Song via bitcoin-dev
> wrote:
> &g
15 matches
Mail list logo
