Re: [Bitcoin-development] Public key and signature malleability

> Any objections from other transaction-validating implementations? Sounds good to me. I think it's important to give people a chance to fix their software, but Pieter's proposal does that. On 10/21/2012 7:05 PM, Gavin Andresen wrote: > Any objections from other transaction-validating implementat

Re: [Bitcoin-development] BIP 35: add mempool message

> This seems safe, although it forces other full implementations that want to > expose protocol version 60002 (or later) to also implement this. What do they > think about this? BitcoinJS will implement it, it's a useful feature and there is no reason not to support it. Two comments from my end:

Re: [Bitcoin-development] BIP: Custom Services

> More elaboration of the use cases might therefore be useful. I'm implementing a DHT, rather than storing the whole blockchain index locally, a future version of BitcoinJS will store only a user defined percentage (anywhere from 0-100%.) Any misses will be resolved by querying the network. Thank

[Bitcoin-development] BIP: Custom Services

Hey everyone, I was working on some custom protocol extensions for Bitcoin that I wanted to experiment with and I noticed that in order to enable nodes to announce these services the only mechanism the protocol currently provides is to use one of the 64 bits of the services field. This is obviousl

Re: [Bitcoin-development] script tests - invalid script in script_valid.json?

ht be something that I'd like to help with if pull requests in that direction are welcome. On 7/29/2012 6:42 PM, Amir Taaki wrote: > oh, bitcoin... > > Thanks justmoon :D > > > > - Original Message - > From: Stefan Thomas > To: bitcoin-development@lists.sourcefor

Re: [Bitcoin-development] script tests - invalid script in script_valid.json?

OP_WITHIN is lower-bound-inclusive, but upper bound exclusive, so 1 0 1 WITHIN is false. bool fValue = (bn2 <= bn1 && bn1 < bn3); https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L854 On 7/29/2012 6:31 PM, Amir Taaki wrote: > Hi! > > Is this a valid script? > > ["1 0 1", "WITHIN N

Re: [Bitcoin-development] Random order for clients page

> I wouldn't expect any really important features which don't have > complicated compromises attached to them to be omitted from all > clients for all that long. True, it's those compromises that people should base their decision on. To make that easier was the motivation for me to suggest feature

Re: [Bitcoin-development] Random order for clients page

> I think by "users" you mean, geeks who understand wiki syntax. The point is to expand the circle of contributors. I'm pretty sure there are more people who can edit a wiki than people who know HTML and how to create a git pull request. :) > Inability to agree on columns isn't why the page look

Re: [Bitcoin-development] Random order for clients page

> However that starts the project down the road of being dominated by > our internal politics rather than what actually makes sense from the > end users perspective. I strongly agree, but this is *why* I suggested moving it to the wiki. I recently had to choose an XMPP client and I looked on xmpp

Re: [Bitcoin-development] Random order for clients page

> You are not a developer of any alternative clients I am and I'm going to have to agree with Greg. Information about clients is bound to be transient and controversial. My relatively naive suggestion would be to move it to the Wiki. If it can handle the controversies involved with the Trade page

Re: [Bitcoin-development] Enforcing inflation rules for SPV clients

Very interesting for you to bring this up. I had a similar idea for a totally different use case. Greg recently pointed out an interesting dilemma saying that (significantly) larger blocks would lead to centralization. So I've been working on a design for a decentralized pool that can handle gigaby

Re: [Bitcoin-development] Berlin Bitcoin Hackathon

Flights booked. Mike Hearn and I will be there. :) On 6/22/2012 1:03 AM, Amir Taaki wrote: > This is happening in Berlin if anyone is around: http://bitcoin-hackathon.com/ > > I am happy to host if space is needed. > > > -

Re: [Bitcoin-development] LevelDB benchmarking

Here are my 2 cents after using LevelDB as the default backend for BitcoinJS for about a year. LevelDB was written to power IndexedDB in Chrome which is a JavaScript API. That means that LevelDB doesn't really give you a lot of options, because they assume that on the C++ layer you don't know any

Re: [Bitcoin-development] SatoshiDice and Near-term scalability

the high priority transactions get confirmed faster, the low priority ones take even longer.) On 6/15/2012 7:17 PM, Jeff Garzik wrote: > On Fri, Jun 15, 2012 at 12:56 PM, Stefan Thomas wrote: >> The artificial limits like the block size limit are essentially putting > [...] > >

Re: [Bitcoin-development] Near-term scalability

Thanks Mike for the writeup - I'm very sad to have missed the discussion on IRC since fee economics are probably my favorite topic, but I'll try to contribute to the email discussion instead. > (4) Making the block size limit float is better than picking a new > arbitrary threshold. Fees are a pr

Re: [Bitcoin-development] Punishing empty blocks?

Zooko is spot on - slower confirmations will give people a reason to set higher fees. As soon as fees reach a level where they matter, even botnet operators will be looking into ways of including transactions for some extra profit. In the meantime slightly slower confirmations aren't a problem. Co

Re: [Bitcoin-development] BIP 18 (or not?)

> luke-jr withdrew BIP 16 and put forwards support for BIP 17. You are so funny sometimes. xD On 3/14/2012 4:07 PM, Amir Taaki wrote: > Hi, > > luke-jr withdrew BIP 16 and put forwards support for BIP 17. So now there's a > consensus to move forwards. > > However he submitted BIP 18 to me today.

Re: [Bitcoin-development] getmemorypool BIP process

> I've updated the draft to include long polling, and remove some assumptions of > using HTTP for transport. Looks good to me. On 3/3/2012 4:44 PM, Luke-Jr wrote: > On Saturday, March 03, 2012 10:05:58 AM Gavin Andresen wrote: >>> HTTP and JSON-RPC are a client-server model; there is no way for t

Re: [Bitcoin-development] getmemorypool BIP process

Btw - question to Stefan as the JavaScript guru - what do you consider the standard/defacto-standard/right/best-practice way of doing S->C json-rpc, what (javascript) library do you use for this? As for an explicitly standard way, there is none. The JSON-RPC 1.0 spec

Re: [Bitcoin-development] getmemorypool BIP process

From what I understand the BIP uses a polling model, e.g. a miner would use getmemorypool to request new work from a pool in intervals. Would it make sense to specify a version of the API supporting long polling? For BitcoinJS specifically, since we also support JSON-RPC over TCP, I'd even be

Re: [Bitcoin-development] JSON-RPC is BIP territory or not?

Since several independent clients (I know at least libcoin and BitcoinJS ) aim to implement JSON-RPC APIs which are either a superset of the origi

Re: [Bitcoin-development] Duplicate transactions vulnerability

> The purpose of this mail is asking for support for adding this rule to > the protocol rules. If there is consensus this rule is the solution, I > hope pools and miners can agree to update their nodes without lengthy > coinbase-flagging procedure that would only delay a solution. So, who > is in f

Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout

I'm firmly against a *blackout* - it would harm users' trust in Bitcoin since people looking to download the client or to get information about Bitcoin may end up in the wrong place. I constantly have to delete YouTube spam advertising this or that "miracle GPU miner" or "secure Bitcoin client"

Re: [Bitcoin-development] Alternative to OP_EVAL

+1. I love this proposal. It's two less bytes than OP_EVAL even. It allows static analysis. It doesn't require any change to the script interpreter. (You can do a static replacement step between parsing and execution.) It allows all urgent use cases. It doesn't consume a NOP. If we ever want recu

Re: [Bitcoin-development] Alternative to OP_EVAL

The OP_EVAL discussion went into some private discussion for a bit, so here is a summary of what we talked about. Roconnor pointed out that the currently proposed OP_EVAL removes the ability to statically reason about scripts. Justmoon pointed out that this is evidenced by the changes to GetSi

Re: [Bitcoin-development] Alternative to OP_EVAL

RE: delaying EVAL rollout: I could live with rolling out just BIP 11 (up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and delaying EVAL rollout on the main network, but I worry that will just encourage people to delay thoroughly reviewing/testing for a couple of months, and we'll be r

Re: [Bitcoin-development] Protocol extensions

Hey Chris, The storage would be distributed, messages are routed on behalf of others, which makes finding the origin of the query hard to find (think Tor) This type of intermediate routing makes Tor slow . Bitcoin

Re: [Bitcoin-development] [BIP 15] Aliases

>> Would it be too strange to use namecoin? > This has the same problem as FirstBits, except .bit domains are dirt cheap, > whereas vanitygen at least slows down grabbing all the common words... Grabbing is no more an issue than mining Bitcoins is an issue. Sure, domain grabbers will have the dom

Re: [Bitcoin-development] Lowering confirmation requirements and preventing double spends

Hey Andy, Bitcoin already does something which in practice has exactly this effect: If a transaction is reversed, any transactions based on its outputs are rejected. Hosted wallets can make use of this - but as you correctly point out, depending on the service, it can get tricky. What if I exc

Re: [Bitcoin-development] [RFC] BIP 14 - Protocol Version and User Agent

Nice. I'll check with justmoon when I hopefully meet him at the conference. It's all fine with me. As soon as the original client switches to the new format, we will, too. On 11/13/2011 09:52 PM, Amir Taaki wrote: Nice. I'll che

Re: [Bitcoin-development] Bitcoin Wiki

+1 for something based on git. Github has a dedicated wiki feature that is git-backed: https://github.com/bitcoinjs/node-bitcoin-p2p/wiki/ git://github.com/bitcoinjs/node-bitcoin-p2p.wiki.git On 10/27/2011 6:15 PM, Daniel F wrote: > +1 on git. not necessarily as replacement, but at least as back

Re: [Bitcoin-development] Deprecating "midstate" in getwork?

BitcoinJS uses OpenSSL to calculate midstate: https://github.com/bitcoinjs/node-bitcoin-p2p/blob/master/native.cc#L380 On 9/29/2011 1:40 PM, Nils Schneider wrote: > Yes, that's possible and what > https://github.com/bitcoin/bitcoin/pull/535 does. However, deprecating > midstate (and hash1) would

Re: [Bitcoin-development] Request review: drop misbehaving peers

A few thoughts: Should the DoS protection auto-disable if the node has less than a minimum number of connections? The idea being that if our node seems to be kicking /everybody /off the roster maybe there is something wrong with the protections. It would be nice if the node sent a message to