-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 12/20/2013 11:48 AM, Gregory Maxwell wrote:
> A couple very early comments— I shared some of these with you on
> IRC but I thought I'd post them to make them more likely to not get
> lost.
I got the inputs from IRC, but thank you for posting to the
On Thu, Dec 19, 2013 at 5:47 PM, Mark Friedenbach wrote:
> Hello fellow bitcoin developers. Included below is the first draft of
> a BIP for a new Merkle-compressed data structure. The need for this
> data structure arose out of the misnamed "Ultimate blockchain
> compression" project, but it has
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
(Sorry Peter, this was meant for the whole list:)
On 12/20/2013 05:17 AM, Peter Todd wrote:
> I've thought about this for awhile and come to the conclusion that
> UTXO commitments are a really bad idea. I myself wanted to see them
> implemented about
I’m inclined to agree, as this was discussed on multiple occasions and seems to
fix a lot of the address re-use problems. With hot topics like “coin
validation”, I think it’s important to highlight the privacy that generating
fresh addresses from public extended keys grants us.
Also thinking ab
Are there any bitcoin to fiat currency processors (like bitpay,
coinbase, etc) that allow testing using the bitcoin testnet?
It seems most of the credit card payment processor apis have
features to allow developers to do testing without 'real money',
what's the equivalent of this for bitcoin when
Embedded consensus systems such as Mastercoin face the risk that the
data they need to embed in the host consensus system will be subject to
censorship. This censorship can take two forms: whitelists and
blacklists. The former we can't do anything about, however the latter
requires someone to ident
On Fri, Dec 20, 2013 at 03:21:38AM -0800, Mark Friedenbach wrote:
> Hi Jeremy, Let's give a preview of the application-oriented BIPs I
> mentioned:
>
> Stateless validation and mining involves prefixing transaction and
> block messages with proofs of their UTxO state changes. These are the
> "oper
On Fri, Dec 20, 2013 at 03:10:50AM -0800, Mark Friedenbach wrote:
> On 12/20/2013 02:48 AM, Peter Todd wrote:
> > On Thu, Dec 19, 2013 at 05:47:52PM -0800, Mark Friedenbach wrote:
> >> This BIP describes the authenticated prefix tree and its many
> >> variations in terms of its serialized represen
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Jeremy, Let's give a preview of the application-oriented BIPs I
mentioned:
Stateless validation and mining involves prefixing transaction and
block messages with proofs of their UTxO state changes. These are the
"operational proofs" I describe in t
On Thu, Dec 19, 2013 at 05:47:52PM -0800, Mark Friedenbach wrote:
> This BIP describes the authenticated prefix tree and its many
> variations in terms of its serialized representation. Additional BIPs
> describe the application of authenticated prefix trees to such
> applications as committed indi
On Fri, Dec 20, 2013 at 8:49 AM, Chris Evans wrote:
> maybe make it so bitcoin.conf settings can be edited with in the app
> instead of external editor, and make it easier to enable rpc server mode...
>
You can help me and diapolo a lot by testing his pull request to add a few
options to the op
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
JSON-RPC is a huge security risk. It's perfectly reasonable that
enabling it requires some technical mumbo-jumbo.
Are there specific configuration settings that you would like to see
exposed by the GUI?
On 12/19/2013 11:49 PM, Chris Evans wrote:
> m
Wow there's a lot here to think about. I'm pretty sure I haven't grasped
the full implications yet.
I see it proposes to also introduce additional BIPs describing the use of
the data stucture for stateless validation & mining, the UBC address index
for "SPV+" operating modes, document timest
13 matches
Mail list logo