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 usage.
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
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
On Wed, Jun 3, 2015 at 10:33 AM, Stephen Morse stephencalebmo...@gmail.com
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
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
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 Sunday
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
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
On 2 June 2015 at 14:26, Mike Hearn m...@plan99.net 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
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
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
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
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
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
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
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 CPUs and
17 matches
Mail list logo
