The Problem
===
We have an embedded consensus system and we want to be able to upgrade
it with new rules. There inevitably will be a transition period where
some users use clients that interpret the new rules, while others only
interpret the old rules. Since we only rely on the host
On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
We have an embedded consensus system and we want to be able to upgrade
it with new rules.
This asserts a central authority and gives developers too much power.
Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE
that allows colored coins and similar embedded consensus system assets
to be securely transferred to another party in exchange for Bitcoins
atomically. In summary his p2p 2-step-trade mechanism operates as
follows:
Alice
On Sun, Feb 09, 2014 at 05:25:41PM +, Luke-Jr wrote:
On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
We have an embedded consensus system and we want to be able to upgrade
it with new rules.
This asserts a central authority and gives developers too much power.
Please, the
On Sun, Feb 09, 2014 at 05:25:41PM +, Luke-Jr wrote:
On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
We have an embedded consensus system and we want to be able to upgrade
it with new rules.
This asserts a central authority and gives developers too much power.
I don't quite
On Sun, Feb 09, 2014 at 12:11:32PM -0600, Troy Benjegerdes wrote:
On Sun, Feb 09, 2014 at 05:25:41PM +, Luke-Jr wrote:
On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
We have an embedded consensus system and we want to be able to upgrade
it with new rules.
This asserts
The only 'assertion' of central authority here is people who download and
run the code and submit to whatever the code asserts they are supposed to
do.
At least with the 'central authority' of the big-business bitcoin developer
cabal I can read the code before I submit to it's
On Sun, Feb 09, 2014 at 01:04:58PM -0500, Peter Todd wrote:
Alex Mizrahi recently outlined a mechanism(1) based on SIGHASH_SINGLE
that allows colored coins and similar embedded consensus system assets
to be securely transferred to another party in exchange for Bitcoins
atomically. In summary
Hello all,
it was something I planned to do since a long time, but with the
recent related issues popping up, I finally got around to writing a
BIP about how we can get rid of transaction malleability over time.
The proposed document is here: https://gist.github.com/sipa/8907691
I expect most
Hello,
I have a request, which is how do developers address the circumstance in
which someone utilizes your code as part of some effort to deprive (or
steal as the case may be) someone of their bitcoin?
This hasn't happened to me, but I have posed a question about it at
bitcointalk:
On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
Hello all,
it was something I planned to do since a long time, but with the
recent related issues popping up, I finally got around to writing a
BIP about how we can get rid of transaction malleability over time.
The proposed
On Sunday, February 09, 2014 11:33:02 PM Pieter Wuille wrote:
The proposed document is here: https://gist.github.com/sipa/8907691
Rule 3 4 are already enforced.
AFAIK nVersion==3 transactions are not currently considered non-standard?
Luke
12 matches
Mail list logo
