Re: [Bitcoin-development] Draft BIP for Bloom filtering

2012-10-26 Thread Gregory Maxwell
On Fri, Oct 26, 2012 at 10:21 AM, Mike Hearn m...@plan99.net wrote: Anyway, it's trivial to DoS the entire Bitcoin network today. It hasn't ever happened. Maybe one day it will, but the only rationale people can come up with for such an attack beyond random griefing is Which happens and is a

Re: [Bitcoin-development] Draft BIP for Bloom filtering

2012-10-25 Thread Gregory Maxwell
On Wed, Oct 24, 2012 at 11:56 AM, Mike Hearn m...@plan99.net wrote: I've written a draft BIP describing the bloom filtering protocol extension developed by myself and Matt. https://en.bitcoin.it/wiki/BIP_0037 Thanks for taking the time to write this up. I still don't understand what purpose

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

2012-10-20 Thread Gregory Maxwell
On Sat, Oct 20, 2012 at 1:55 PM, Pieter Wuille pieter.wui...@gmail.com wrote: What do you think about these rules? If people want these rules, nothing would happen for now - just start try to find software that doesn't produce complying data. In a second step, these could be enabled as check

Re: [Bitcoin-development] Large backlog of transactions building up?

2012-09-25 Thread Gregory Maxwell
? This is discussion about transactions which are not in the chain yet. On 9/23/12, Gregory Maxwell gmaxw...@gmail.com wrote: There are bursts of weird transactions (e.g. someone was flooding zero value txn a few weeks ago; before that there were some enormous series of double-spend induced orphans), and other

Re: [Bitcoin-development] Large backlog of transactions building up?

2012-09-23 Thread Gregory Maxwell
On Sun, Sep 23, 2012 at 4:30 PM, Jeff Garzik jgar...@exmulti.com wrote: Yeah, my public nodes currently have 2200+ Over time, it gets cluttered naturally due to the disconnect between what miners mine and what relayers relay. Right, this disconnect is why simple scalar measures of mempool

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-13 Thread Gregory Maxwell
On Thu, Sep 13, 2012 at 10:05 AM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: @Gregory But you only need to request the transactions you don't have. Most of time you should already have almost all of the transactions. Yes, my proposal allows you to do this. You skip out

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-11 Thread Gregory Maxwell
On Tue, Sep 11, 2012 at 3:07 PM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: For some reason sourceforge is not sending me updates anymore but I can see the replies online… There could be a slightly more simple protocol which gives all the transactions hashes and nodes can then

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-11 Thread Gregory Maxwell
On Tue, Sep 11, 2012 at 5:48 PM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: You wouldn't need to pipeline the requests, just place more than one inventory vector in get data, right? Well my messages would save the space of those inventory vectors. Instead of needing 36 byte

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-10 Thread Gregory Maxwell
On Mon, Sep 10, 2012 at 11:07 AM, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote: Here is a BIP draft for improving the block relaying and validation so that it can be done in parallel and so that redundancy can be removed. This becomes more beneficial the larger the block sizes are.

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-10 Thread Gregory Maxwell
On Mon, Sep 10, 2012 at 3:53 PM, Matt Corallo bitcoin-l...@bluematt.me wrote: It seems to me the whole idea of segmenting blocks would add very little (to nothing) with any sane block size. Sure, if a block were to be 10GB, it may make sense. However, even in that case, it would be easier As

Re: [Bitcoin-development] BIP: Custom Services

2012-08-13 Thread Gregory Maxwell
On Mon, Aug 13, 2012 at 10:24 AM, Jeff Garzik jgar...@exmulti.com wrote: My only response is a weak one: inevitability. It seems likely that -somebody- will implement their own P2P commands for their own client subset, even if only a simple use 'getstatus' with strSubVer matching /FooClient/

Re: [Bitcoin-development] BIP 22 - getmemorypool

2012-07-30 Thread Gregory Maxwell
On Mon, Jul 30, 2012 at 4:26 PM, Amir Taaki zgen...@yahoo.com wrote: Hi, luke-jr wants me to split this BIP into 3 separate BIPs because he says that other devs felt it was too unfocused and covered too many topics. However this discussion took place on IRC, a It actually took place on

Re: [Bitcoin-development] Scalability issues

2012-07-27 Thread Gregory Maxwell
On Fri, Jul 27, 2012 at 1:59 AM, grarpamp grarp...@gmail.com wrote: I now have an 1.8 ghz p3 celeron (128k cache) which should be substantially slower than your machine, running vintage 2.6.20 linux. Unfortunately I forgot to turn on timestamp logging so I don't know how long it took to sync

Re: [Bitcoin-development] Scalability issues

2012-07-26 Thread Gregory Maxwell
On Fri, Jul 27, 2012 at 12:20 AM, grarpamp grarp...@gmail.com wrote: Update: this class of machine just became useless for bitcoin. When blk0002.dat was created to store more blocks, all forward progress processing blocks turned into losing ground by 20 or so a day. Guessing both datfiles were

Re: [Bitcoin-development] Scalability issues

2012-07-23 Thread Gregory Maxwell
On Sun, Jul 22, 2012 at 6:37 PM, grarpamp grarp...@gmail.com wrote: It already takes a month to build a new blockchain, let alone keep up with new incoming blocks. Please fix your software stack. Something is wrong with your system and I doubt it has much to do with bitcoin. A full sync here

Re: [Bitcoin-development] Bitcoin Wallet for Android

2012-07-09 Thread Gregory Maxwell
On Mon, Jul 9, 2012 at 7:34 AM, Jorge Timón timon.elvi...@gmail.com wrote: Didn't even know that they were proprietary software bitcoin clients. Should people trust them? Should the web promote them? After all, you can't know what they do. What if one of them contains a back door or something?

Re: [Bitcoin-development] Bitcoin Wallet for Android

2012-07-09 Thread Gregory Maxwell
On Mon, Jul 9, 2012 at 5:21 AM, Amir Taaki zgen...@yahoo.com wrote: Hey, I just saw this added to the clients page. One of the conditions we set for that page was that all the clients must have the entire sourcecode available for review, and users should be able to run it from the

Re: [Bitcoin-development] Bitcoin Wallet for Android

2012-07-09 Thread Gregory Maxwell
On Mon, Jul 9, 2012 at 10:00 AM, Gregory Maxwell gmaxw...@gmail.com wrote: I've reverted these additions to the page, nothing personal but— Er, to be clear, I left the android software in because the source is available (And I'm told its had some review). I removed the proprietary software

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

2012-07-09 Thread Gregory Maxwell
On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki zgen...@yahoo.com wrote: Took me a while, but finally got it working. Entries on the clients page are randomly ordered when the page is generated. https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 We should

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

2012-07-09 Thread Gregory Maxwell
On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki zgen...@yahoo.com wrote: JS randomisation is bad. People shouldn't need JS to view a webpage. JS randomization doesn't imply needing JS to view the page. It implies needing JS to see it in random order. You could also combine it with the server-side

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

2012-07-09 Thread Gregory Maxwell
On Mon, Jul 9, 2012 at 2:18 PM, Amir Taaki zgen...@yahoo.com wrote: The only thing that's changed between now and this morning is: - Addition of Bitcoin Wallet for Android - Randomisation of entries Yes, because I reverted eight commits to it by you because they were clearly controversial,

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

2012-07-09 Thread Gregory Maxwell
On Mon, Jul 9, 2012 at 2:54 PM, Jim jim...@fastmail.co.uk wrote: RE: The position randomisation - I have to admit I was secretly pleased with the original layout, as MultiBit just happened to have the eye candy position of top and centre. It is only fair to have them switch around. This

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

2012-07-09 Thread Gregory Maxwell
On Mon, Jul 9, 2012 at 10:44 PM, Alan Reiner etothe...@gmail.com wrote: What a feature matrix is good at though is it allows you to very quickly find the specific feature or general criteria you're looking for without reading through all of the text. So it might be a useful addition maybe not

Re: [Bitcoin-development] Pruning in the reference client: ultraprune mode

2012-07-06 Thread Gregory Maxwell
Pieter's performance numbers are a bit conservative if anything— profiles on ultraprune[1] show that the reference client's wasting of a lot of time in redundant serialization and hashing operations is the major time sink. Once thats cleared up it should be quite a bit faster [1]

Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase

2012-07-06 Thread Gregory Maxwell
On Fri, Jul 6, 2012 at 4:02 PM, Gavin Andresen gavinandre...@gmail.com wrote: But those issues are solvable through other, non-backwards incompatible means. For example, mandate that a transaction hash, output index refers to the first such pair that is not already spent. No? Yes, that is

Re: [Bitcoin-development] Tor hidden service support

2012-06-26 Thread Gregory Maxwell
On Tue, Jun 26, 2012 at 7:01 PM, grarpamp grarp...@gmail.com wrote: You are going to want to include the block of the Phatom project as well: https://code.google.com/p/phantom/ fd00:2522:3493::/48 Perhaps some argument to add blocks to the IsRoutable check is in order? Then people who use

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

2012-06-24 Thread Gregory Maxwell
On Sun, Jun 24, 2012 at 8:45 AM, Mike Hearn m...@plan99.net wrote: d'aniel made a good proposal - having good nodes broadcast announcements when they detect a rule that breaks the rules, along with a proof that it did so. Checking the proof might be very Link? I also proposed this on this

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node

2012-06-19 Thread Gregory Maxwell
On Tue, Jun 19, 2012 at 1:33 PM, Alan Reiner etothe...@gmail.com wrote:  One app developer updates their RB tree code which updated the RB-tree optimizations/rebalancing, and now a significant portion of the network can't agree on the correct root.  Not only would that be disruptive, it would

Re: [Bitcoin-development] 0.6.x - detachdb in wrong place

2012-06-17 Thread Gregory Maxwell
On Sun, Jun 17, 2012 at 5:22 AM, grarpamp grarp...@gmail.com wrote: Well, detachdb doesn't appear in the -\? help because it's stuffed under pnp, which is not set in my build. please fix for people, tx :) It isn't inside the ifdef in bitcoin git master. (For future reference this sort of

Re: [Bitcoin-development] 0.6.x - detachdb in wrong place

2012-06-17 Thread Gregory Maxwell
On Sun, Jun 17, 2012 at 5:35 PM, grarpamp grarp...@gmail.com wrote: It isn't inside the ifdef in bitcoin git master. Oh, hmm, well then, what is the difference or usage between these two repositories in regards to the project? Which one are the formal releases tagged (tbz's cut) in? Which

Re: [Bitcoin-development] 0.6.x - detachdb in wrong place

2012-06-17 Thread Gregory Maxwell
On Sun, Jun 17, 2012 at 7:04 PM, grarpamp grarp...@gmail.com wrote: Presumably the github/0.6.2 branch is safe for production? 0.6.2 is very widely used, more so than the other acceptably updated backports. What degree of caution about wallet eating should be made for those using

Re: [Bitcoin-development] After compressed pubkeys: hybrid pubkeys

2012-06-16 Thread Gregory Maxwell
On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen gavinandre...@gmail.com wrote: RE: 0x06/0x07 'hybrid' public keys: Any opinions? Forbidding it certainly makes alternative implementation slightly easier in the future, but I'm not sure the hassle of a network rule change is worth it. I say

[Bitcoin-development] Near-term scalability

2012-06-15 Thread Gregory Maxwell
[I originally sent an earlier version of this message to Mike off list, but I figure it's worth adding to the public discussion] On Fri, Jun 15, 2012 at 7:29 AM, Mike Hearn m...@plan99.net wrote: (4) Making the block size limit float is better than picking a new arbitrary threshold. On the

Re: [Bitcoin-development] Near-term scalability

2012-06-15 Thread Gregory Maxwell
On Fri, Jun 15, 2012 at 2:50 PM, Amir Taaki zgen...@yahoo.com wrote: Part of the problem is that Satoshi didn't totally anticipate the growth of the network. The block reward (the subsidy) is too high, which is why transactions can afford to be so cheap. What would happen if blocks required

Re: [Bitcoin-development] Bootstrapping full nodes post-pruning

2012-06-11 Thread Gregory Maxwell
On Sun, Jun 10, 2012 at 7:06 PM, Mike Hearn m...@plan99.net wrote: I remember some people, Greg in particular, who were not a fan of approach (2) at all, though it has the benefit of speeding startup for new users as there's no indexing overhead. I'm not a fan of anything which introduces

Re: [Bitcoin-development] Bootstrapping full nodes post-pruning

2012-06-11 Thread Gregory Maxwell
On Mon, Jun 11, 2012 at 4:36 PM, Mike Hearn m...@plan99.net wrote: Unless BDB has some weird behaviour in it, that shouldn't require any HAHAHA. Have you consider doing comedy full time? Actual BDB files are absolutely not deterministic. Nor is the raw blockchain itself currently, because

Re: [Bitcoin-development] Punishing empty blocks?

2012-05-24 Thread Gregory Maxwell
On Thu, May 24, 2012 at 8:51 PM, Jeff Garzik jgar...@exmulti.com wrote: which ones are the lazy miners ( 120 seconds since last block). It's important to understand the motivations before acting— otherwise you'll fail to do anything useful. E.g. if they're empty because some miners want to

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-02 Thread Gregory Maxwell
If your computer is low powered or you aren't willing to tolerate a 24-hour+ initial start time, What computer is the initial start time 24-hours+ now? On normal systems initial sync-up now takes a couple hours. It could be slower, of course, if you have the bad luck to end up with

Re: [Bitcoin-development] Fwd: Proposal for a new opcode

2012-03-21 Thread Gregory Maxwell
On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd w...@uchicago.edu wrote: Dear all, I am proposing a new opcode for the purposes of anonymous transactions. This new opcode enables scripts to be given proof that the receiver can carry out or has carried out a previous transaction. I'm currently

Re: [Bitcoin-development] Proposal for a new opcode

2012-03-21 Thread Gregory Maxwell
On Wed, Mar 21, 2012 at 6:02 PM, Watson Ladd w...@uchicago.edu wrote: -My protocol works, your's doesn't. It's not enough to have a mix, the mix needs to be verifiable to avoid one of the mixers inserting their own key and removing a key that should be in there. That doesn't mean you can't

Re: [Bitcoin-development] Fwd: Proposal for a new opcode

2012-03-06 Thread Gregory Maxwell
On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd w...@uchicago.edu wrote: I am proposing a new opcode for the purposes of anonymous transactions. This new opcode enables scripts to be given proof that the receiver can carry out or has carried out a previous transaction. I'm currently working on a

Re: [Bitcoin-development] Duplicate transactions vulnerability

2012-03-01 Thread Gregory Maxwell
On Thu, Mar 1, 2012 at 8:09 AM, Ben Reeves supp...@pi.uk.com wrote: One more thing to add. The implementation in the reference patch fixes the blockchain forking issue however by still allowing spent coinbases to be disconnected patched clients are still vulnerable to blockchain corruption.

Re: [Bitcoin-development] Announcement: libcoin

2012-02-02 Thread Gregory Maxwell
On Thu, Feb 2, 2012 at 12:12 PM, Gregory Maxwell gmaxw...@gmail.com wrote: sync, libbitcoin only made it to height 138k (of course, because the time is mostly spent late in the chain 138k is not very far along— I'm guessing it's going to take libbitcoin 3x-4x longer all said) It ended up

Re: [Bitcoin-development] Announcement: libcoin

2012-02-02 Thread Gregory Maxwell
On Thu, Feb 2, 2012 at 12:36 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Thu, Feb 2, 2012 at 12:12 PM, Gregory Maxwell gmaxw...@gmail.com wrote: sync, libbitcoin only made it to height 138k (of course, because the time is mostly spent late in the chain 138k is not very far along— I'm

Re: [Bitcoin-development] Announcement: libcoin

2012-02-01 Thread Gregory Maxwell
On Wed, Feb 1, 2012 at 9:18 AM, Michael Grønager grona...@ceptacle.com wrote: The libcoin/bitcoind client downloads the entire block chain 3.5 times faster than the bitcoin/bitcoind client. This is less than 90 minutes on a modern laptop! Very interesting. Do you know where this speedup came

Re: [Bitcoin-development] BIP 20 Rejected, process for BIP 21N

2012-01-31 Thread Gregory Maxwell
On Tue, Jan 31, 2012 at 9:33 AM, slush sl...@centrum.cz wrote: excuse me if it was already discussed, but maybe using satoshis instead of decimal bitcoin would be better choice? We all know about pains with proper handling decimal numbers across of all implementations - and it's not only about

Re: [Bitcoin-development] BIP16/17 replacement

2012-01-31 Thread Gregory Maxwell
On Tue, Jan 31, 2012 at 11:50 AM, Andy Parkins andypark...@gmail.com wrote: Hello, Gulp.  Am a little nervous about wading into this swamp.  However, it seems to me that the debate has veered into the personal and away from the I think you've been deceived by people who have some interest in

Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager

2012-01-30 Thread Gregory Maxwell
On Mon, Jan 30, 2012 at 9:05 PM, Gavin Andresen gavinandre...@gmail.com wrote: I've also been wondering if it is time to remove the IRC bootstrapping mechanism; it would remove a fair bit of code and we'd stop getting reports that various ISPs tag bitcoin as malware.  When testing the list of

Re: [Bitcoin-development] CAddrMan: Stochastic IP address manager

2012-01-30 Thread Gregory Maxwell
On Mon, Jan 30, 2012 at 11:33 PM, Michael Hendricks mich...@ndrix.org wrote: address manager point to the attacker.  If a client has 8 connections to the network, a Sybil attack would succeed 1.7% of the time. Meh, careful not to mixup addrman created issues with preexisting ones simply related

Re: [Bitcoin-development] Quote on BIP 16

2012-01-29 Thread Gregory Maxwell
On Sun, Jan 29, 2012 at 12:23 AM, Alan Reiner etothe...@gmail.com wrote: [snip] But gmaxwell has expressed some compelling reasons why plain multi-sig might be abused, which maybe suggests we don't want it ever considered standard...?  I guess I'm not really promoting one thing or another, but

Re: [Bitcoin-development] Quote on BIP 16

2012-01-28 Thread Gregory Maxwell
On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki zgen...@yahoo.com wrote: How could you have a 70 byte long address without a P2SH scheme? Is this a mistake? ... No it's not a mistake. P2SH _prevents_ needing long addresses. Lets unpack the acronym pay to script _hash_. Hashes only need to be

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

2012-01-16 Thread Gregory Maxwell
On Mon, Jan 16, 2012 at 2:35 AM, Wladimir laa...@gmail.com wrote: Internet censorship *is* a threat to bitcoin, if we don't stand up for our rights now we deserve anything that is coming. There will be no long run. Very few people actually care if they can load that particular URL ... if you

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

2012-01-16 Thread Gregory Maxwell
On Mon, Jan 16, 2012 at 9:37 PM, Kyle Henderson k...@old.school.nz wrote: For those that believe one particularly noisy country in the North America region with a policy called SOPA or PIPA directly affects Bitcoin - can you point out precisely where it does so? In addition to the concerns

Re: [Bitcoin-development] does stubbing off Merkle trees reduce initial download bandwidth?

2012-01-02 Thread Gregory Maxwell
On Mon, Jan 2, 2012 at 5:23 PM, Elden Tyrell tyrell.el...@gmail.com wrote: On 2012-01-02 05:31:19 -0800, Christian Decker said: Later full blocks would be required to detect usable inputs for future outgoing transactions. Er, yes, this is what I meant; I guess I should have been more

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

2011-12-16 Thread Gregory Maxwell
On Fri, Dec 16, 2011 at 12:36 PM, Khalahan k...@dot-bit.org wrote: Namecoin is a peer-to-peer generic name/value datastore system. Don't forget it's not limited to .bit usage ! So, directly mapping things to .bit url would not be the optimal way of using namecoin. Namecoin is specificaly

Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you

2011-10-26 Thread Gregory Maxwell
On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager grona...@ceptacle.com wrote: I think it is a very important feature to be able to extract transaction to/from you only from your private keys. In the standard transactions this is easily accomplished - in the case you only want to find the

Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you

2011-10-25 Thread Gregory Maxwell
On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen gavinandre...@gmail.com wrote: You give the hash to whoever is paying you, and store the hash -- script  mapping when you do that (assuming you're not using a deterministic wallet; if you are, you probably just increment a counter in the wallet).

Re: [Bitcoin-development] Multisignature transations

2011-09-30 Thread Gregory Maxwell
On Fri, Sep 30, 2011 at 1:21 PM, Gavin Andresen gavinandre...@gmail.com wrote: Accepting this does not preclude adding more 'standard' transaction types in the future. I think 2 of 3 is a _far_ more useful example than (a or b),  it is the prototype for a normal escrow transaction., and still

<    1   2   3   4