On 19/09/15 15:11, Rune K. Svendsen wrote:
> An honest miner is a miner that supports the network by building on top of
> the best valid chain. A malicious miner is one who wants to disrupt the
> Bitcoin network, not support it, for example by executing a 51% attack which
> mines empty blocks on
It seems there should be a practical limit to the size of a re-org - I mean
a practical limit that is smaller than the current height. Vincent's
proposal suggests that a year's worth of blocks is such a practical limit.
I agree. There are probably lower limits that are practical too, but I
like a
An honest miner is a miner that supports the network by building on top of the
best valid chain. A malicious miner is one who wants to disrupt the Bitcoin
network, not support it, for example by executing a 51% attack which mines
empty blocks on top of the best chain.
/Rune
> Den 19/09/2015 k
On 19/09/15 10:45, Rune Kjær Svendsen wrote:
> We need to distinguish between two different things here:
>
> 1) A 51% attack, where the majority of mining power is *malicious* (hence
> “attack”)
What does "malicious" mean?
In other words, If miner A is mining honestly, and miner B is mining
mal
We need to distinguish between two different things here:
1) A 51% attack, where the majority of mining power is *malicious* (hence
“attack”)
and
2) A fork that exists because of a disagreement in the network, with total
mining power split in two camps, each camp mining peacefully on their own
On 18/09/15 15:17, Rune Kjær Svendsen via bitcoin-dev wrote:
> Bitcoin does not function if the majority of mining power is dishonest. There
> is no way around that. It’s how proof-of-work functions.
None of those statements are true.
If a majority of Bitcoin miners are mining invalid blocks, t
This way lets us protect from 51% overwrites for a whole year:
1. Hash utxo set as is today, H1, and store it in a block.
2. At the same time, store a copy of the utxo set for H1 on disk, D1
3. After 1 year, create D2, then wait for H2 (if a fork happens then
recreate D2 and see which wins)
4. The
s/move the genesis block forward/move your genesis checkpoint forward/
On Sep 18, 2015 4:37 PM, "Jorge Timón" wrote:
> Well, with utxo commitments at some point maybe is enough to validate the
> full headers history but only the last 5 years of ttansaction history
> (assuming utxo commitments are
Well, with utxo commitments at some point maybe is enough to validate the
full headers history but only the last 5 years of ttansaction history
(assuming utxo commitments are buried 5 years worth of blocks in the past).
This scales much better than validating the full history and if we get a 5
year
There are a couple of points I’d like to address.
Firstly, yes, >50% attacks are a problem for Bitcoin. Bitcoin does not function
if the majority of mining power is dishonest. There is no way around that. It’s
how proof-of-work functions. And if we lose proof-of-work, we lose Bitcoin.
Secondly,
I believe the discussion here is on improving initial-sync time by
simply skipping initial-sync and getting a committed-to utxo set. This
is obviously a new security model in between SPV and full-node (I would
call it SPV with future validation). Still, I'm not convinced it buys us
anything, we rea
I guess I always assumed that UTXO set commitments were an alternative
security model (between SPV and full-node), not that they would cause the
existing security model to be deprecated.
On Fri, Sep 18, 2015 at 3:43 PM, Patrick Strateman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wr
Full nodes using UTXO set commitments is a change to the bitcoin
security model.
Currently an attacker with >50% of the network hashrate can rewrite history.
If full nodes rely on UTXO set commitments such an attacker could create
an infinite number of bitcoins (as in many times more than the cur
Currently, when a new node wants to join the network, it needs to retrieve the
entire blockchain history, starting from January 2009 and up until now, in
order to derive a UTXO set that it can verify new blocks/transactions against.
With a blockchain size of 40GB and a UTXO size of around 1GB, t
14 matches
Mail list logo
