The output has to be burned otherwise there is no cost of expressing
any number of alternate opinions the same time.
Tamas Blummer
Bits of Proof
On Dec 15, 2014, at 3:55 PM, Isidor Zeuner wrote:
> For every participant who could try to decide about the adequateness
> of the cost, no direct eff
> The goal is to have an opportunity cost to breaking the rules.
>
You could as well have said "The goal is to implement it in a specific way
I want it to be implemented."
This makes zero sense.
You aren't even trying to compare properties of different possible
implementations, you just outright
Let me be more concrete in implementation details:
1) burn transaction sends at least n satoshis to an OP_RETURN h,
2) h mod m matches the bitcoin block hash mod m, for the block the burn
transaction was mined into.
3) The side chain block header hashes to h and also contains the bitcoin block
On Tue, Dec 16, 2014 at 11:55:50AM +0200, Alex Mizrahi wrote:
> Usually at this point people say "we assume that miners aren't going to
> collude, otherwise even Bitcoin is not secure".
> Well, this is BS. The fact that a pool can acquire more than 50% of total
> hashpower was successfully demonstr
It can be useful to review open source development processes from time to
time. This reddit thread[1] serves use both as a case study, and also a
moment of OSS process introduction for newbies.
[1]
http://www.reddit.com/r/Bitcoin/comments/2pd0zy/peter_todd_is_saying_shoddy_development_on_v010/
Thank you Jeff.
Having looked at a lot of linux code, and now a lot of bitcoin code, the
biggest long-term systemic risk I see is that Bitcoin has is the lack of
code janitors.
The problem is that janitoring was *disruptive* for non-x86 linux architectures
when it first got going, and it's going
Peter provides an excellent summary of Proof of Publication, which starts
with defining it as being composed of a solution to the double spend
problem. He requires Proof-of-receipt (proof every member of p in audience
P has received a message m), Proof-of-non-publication (proof a message m
has not
Would someone also clarify the use of "nit" for nitpicking and how it plays
in the role of consensus?
It seems like it's used for minor complaints/preferences.
Drak
On Wed, Dec 10, 2014 at 3:52 PM, Jeff Garzik wrote:
>
> On Wed, Dec 10, 2014 at 1:47 AM, Wladimir wrote:
>
>> Concept ACK -> agree
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
bleep bloop
Peter Todd:
> On Fri, Dec 12, 2014 at 01:41:34PM +, odinn wrote:
>> Peter... It kind of sounds to me that (as fine of a position
>> paper as this is) on _certain_ points, you're falling prey to the
>> "but it's inefficient, but it's
9 matches
Mail list logo
