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 discussed this more at bitcointalk:
https://bitcointalk.org/index.php?topic=4998410.0
The attacks I'm interested in preventing are not only selfish mining
and collusion, but also more subtle attacks like block withholding,
and in general anything that aims to drive out the competition in
order t
lock by including the
> suggested transactions and giving the associated transaction fees to a
> payment address specified in the Helper Block. Miners who do not use a
> Helper Block must satisfy a 25% higher difficulty.
>
> On Fri, Sep 14, 2018 at 9:56 AM Andrew via bitcoin-dev
>
____
> From: bitcoin-dev-boun...@lists.linuxfoundation.org
> on behalf of Andrew via
> bitcoin-dev
> Sent: Friday, 14 September 2018 9:19:37 AM
> To: Bitcoin Dev
> Subject: Re: [bitcoin-dev] Selfish Mining Prevention
>
> I discussed this more at bitcointalk:
> htt
> I see what you say, however, since the proposal as I have read it says "And
> this will keep happening as long as hashrate keeps rising," - what actually
> happens in the case hashrate stagnates or falls?
In general, a target hashrate can be set by users (can be less or more
than the peak hash
@ Eric: Yes I forgot to mention that cost (in addition to price) also
determines the profitability of mining and thus the total hashpower. I
disagree with your assessment of merge mining as really what matters
is opportunity cost of honestly mining vs attacking, and one reason we
are currently safe
Hi Akiva
I sketched out a similar proposal here:
https://bitcointalk.org/index.php?topic=1083345.0
It's good to see people talking about this :). I'm not quite convinced with
segregated witness, as it might mess up some things, but will take a closer
look.
On Dec 9, 2015 7:32 AM, "Loi Luu via bit
On Fri, Dec 18, 2015 at 2:47 AM, Jonathan Toomim via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Dec 18, 2015, at 10:30 AM, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> 1) The risk of an old full node wallet accepting a transaction that
I have been reading recently through the history of soft forks provided by
Bitcoin Core:
https://bitcoin.stackexchange.com/questions/43538/where-can-i-find-a-record-of-blockchain-soft-forks
.
It has led me to think that there is a deceiving notion that soft forks do
not force Bitcoin users to upgr
Hi
Is there a worked out scriptPubKey for doing multisig with just hashes
of the participants? I think it is doable and it is more secure to a
compromised ECDSA. I'm thinking something like this for the
scriptPubKey:
2 OP_SWAP OP_SWAP OP_SWAP OP_DUP OP_HASH160
OP_EQUALVERIFY OP_DUP OP_HASH160 O
Hi, recently been trying to get RBF working on a multisig input. I set
the nSequence to 0, but script didn't verify (used python-bitcoinlib).
Should it work for this type of transaction? I am using the
SignatureHash(...) method of signing, not rpc.signrawtransaction(...).
Thanks
On Thu, Jan 12, 2
What are you trying to do? Break the ice with a hard fork so that later it
becomes easier to do so, with people more complacent towards it? There are
many solutions to the scaling problem that do not require a hard fork and
are quite simple to implement actually, and don't come with the
complicatio
On Sun, Aug 16, 2015 at 9:46 AM, xor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hey folks,
>
> so you've been stressed with arguing about what to do with the block size
> for
> months now :(
>
> Why not realize that the unfruitful permanent need for administrators to
> tweak
13 matches
Mail list logo
