As I understand, selfish mining is an attack where miners collude to
mine at a lower hashrate then with all miners working independently.
What are the current strategies used to prevent this and what are the
future plans?
One idea I have is to let the block reward get "modulated" according
to peak
I think I mentioned it before, but seems semi-relevant to this thread so I'd
like to throw my vote behind pretty tiny blocks on testnet (like max 50-100k
weight) to try help simulate a fee-market like situation.
(Although lately there's been a lot of testnet spam and full blocks, which has
real
When a user creates a transaction with a fee attached, they are
incentivizing miners to add this transaction to the blockchain. The
task is usually not very specific -- as long as it ends up in a valid
chain with the most Proof-of-Work, miners get paid. The payment is an
incentive for miners to act
On Wed, Aug 29, 2018 at 08:09:36AM -0400, Erik Aronesty wrote:
> Note:
>
> This spec cannot be used directly with a shamir scheme to produce
> single-round threshold multisigs, because shares of point R would need to
> be broadcast to share participants in order to produce valid single
> signature
Good morning all,
I am wondering if there is the possibility of an issue arising when different
pay-to-contract schemes are used on Bitcoin.
Specifically, I wonder, if it may be possible to reinterpret the byte
serialization of a contract under one scheme as the byte serialization of a
differe
Hi
During work on the implementation of BIP151 [1] I figured out that the current
published proposal could be further optimized.
I wrote an overhauled BIP151 specification with some – partially radical –
changes.
Now it’s unclear to me if this should be published under a new BIP nr. or if it
is
Johnson Lau writes:
> Great, I’ll revise it.
>
> Follow-up questions:
>
> 1. Is there any useful case which one would like to use NOINPUT with
> scriptCode and/or scriptPubKey committed? (Note that with
> taproot/MAST, scriptCode and scriptPubKey are not
> interchangeable. scriptPubKey commits to
Without commenting on the other merits of either proposal, the addition of the
service flag resolves bip151’s previously-discussed lack of backward
compatibility.
e
> On Sep 3, 2018, at 21:16, Jonas Schnelli via bitcoin-dev
> wrote:
>
> Hi
>
> During work on the implementation of BIP151 [1]
