On 06/01/2015 08:55 AM, Mike Hearn wrote:
>> Decentralization is the core of Bitcoin's security model and thus
that's what gives Bitcoin its value.
> No. Usage is what gives Bitcoin value.
Nonsense.
Visa, Dollar, Euro, Yuan, Peso have usage.
The value in Bitcoin is *despite* it's far lesser usag
>
> 1,000 *people* in control vs. 10 is two orders of
magnitude more decentralized.
Yet Bitcoin has got worse by all these metrics: there was a time before
mining pools when there were ~thousands of people mining with their local
CPUs and GPUs. Now the number of full nodes that matter for block
>Then please enlighten me. You're unable to download block templates from a trusted node outside of the country because the bandwidth requirements are too high? Or due to some other problem?
>With respect to "now it's your turn". Let's imagine the hard fork goes ahead. Let us assume that almo
>
> But the majority of the hashrate can now perform double spends on your
> chain! They can send bitcoins to exchanges, sell it, extract the money and
> build a new longer chain to get their bitcoins back.
>
Obviously if the majority of the mining hash rate is doing double spending
attacks on exch
On 2 June 2015 at 14:26, Mike Hearn wrote:
> But the majority of the hashrate can now perform double spends on your
>> chain! They can send bitcoins to exchanges, sell it, extract the money and
>> build a new longer chain to get their bitcoins back.
>>
> Obviously if the majority of the mining ha
Do you think it would be useful to have an inverted version of both CSV and
CLTV? To verify if an output is spent before a specific time. CLTV and CSV
could be implemented by taking two stack arguments, an integer for the
comparison and TRUE/FALSE.
Now that I think about this more, the problem
That would also introduce the anomaly of a script that was once valid
becoming later invalid, when nothing varies other than time. That is
not super compatible with the current model of reprocessing
transactions in later blocks if the block they were first in gets
reorged.
(Not a huge flexibility
>
> That would also introduce the anomaly of a script that was once valid
> becoming later invalid, when nothing varies other than time. That is
> not super compatible with the current model of reprocessing
> transactions in later blocks if the block they were first in gets
> reorged.
>
Very good
Hi there,
I got some requests to re-record the tutorial talk I gave at DevCore 2015,
"How to build a timestamping smart contracts app in 30 minutes". It's now
available here:
https://bitcoinj.github.io/document-timestamp-app
It covers:
- How to customise the wallet-template app for this
Oh it is far worse than that. There is nothing preventing those coins from
being spent somewhere else, so actually an expiry would enable coin theft
in a reorg -- you make your spends expire right after they hit the chain
the first time, and then if there is a reorg the spend and subsequent
transac
I am glad to see the transaction version number increase. The commit
doesn't update the default transaction version though. The node would
still produce version 1 transactions.
Does the reference client already produce transactions with final sequence
numbers? If so, then they will be valid ver
On 06/02/2015 04:03 AM, Mike Hearn wrote:
>
> 1,000 *people* in control vs. 10 is two orders of
>
> magnitude more decentralized.
>
>
> Yet Bitcoin has got worse by all these metrics: there was a time
> before mining pools when there were ~thousands of people mining with
> their local CPU
Why do it as an OP_RETURN output? It could be a simple token in the coinbase
input script, similar to how support for P2SH was signaled among miners. And
why should there be an explicit token for voting for the status quo? Simply
omitting any indication should be an implicit vote for the status
>
> Why do it as an OP_RETURN output? It could be a simple token in the
> coinbase input script, similar to how support for P2SH was signaled among
> miners. And why should there be an explicit token for voting for the status
> quo? Simply omitting any indication should be an implicit vote for the
Pindar,
yes and it's a good idea to separate the hard/soft fork upgrades. The point
> being here is that we're also establishing a process for the community to
> self-determine the way forward in a transparent and verifiable manner.
>
> What's not to like? :)
>
> I'll probably have some time on Su
Vincent,
> Some changes:
>
> Votes need to be 100%, not 50.01%. That way small miners have a fair
> chance. A 50.01% vote means large miners call the shots.
>
While I like the idea of possibly requiring more than 50%, you wouldn't
want to have a situation where a minority of uncooperative (or just
Some changes:
Votes need to be 100%, not 50.01%. That way small miners have a fair
chance. A 50.01% vote means large miners call the shots.
Users (people who make transactions) need to vote. A vote by a miner
shouldn't count without user votes. Fee incentives should attract
legitimate votes from
On Wed, Jun 3, 2015 at 10:33 AM, Stephen Morse
wrote:
> Pindar,
>
> yes and it's a good idea to separate the hard/soft fork upgrades. The
>> point being here is that we're also establishing a process for the
>> community to self-determine the way forward in a transparent and verifiable
>> manner.
Subject: Bitcoin-development Digest, Vol 49, Issue 16
1. Re: Proposed alternatives to the 20MB step (Eric Voskuil)
--
Message: 1
Date: Mon, 01 Jun 2015 17:09:10 -0700
From: Eric Voskuil
Subject: Re: [Bitcoin-developme
19 matches
Mail list logo