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
---
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 prop
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:
https://bitc
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 ru
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 summar
> > 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
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.
> >
> > T
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
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,
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 control
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.
---
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 consen
12 matches
Mail list logo
