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

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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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] 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

[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] 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

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] 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] 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] 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] 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] 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 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] 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] 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-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] 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] 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] 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-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-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] 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] 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] 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] Draft BIP for Bloom filtering

2012-10-26 Thread Gregory Maxwell
On Fri, Oct 26, 2012 at 10:01 AM, Mike Hearn m...@plan99.net wrote: If you just want to waste bandwidth of nodes you can connect to nodes and repeatedly download blocks, or fill the network with fake nodes that spam random generated transactions to whoever connects. I don't see how to avoid

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] Electrum security model concerns

2012-11-15 Thread Gregory Maxwell
On Sat, Oct 6, 2012 at 12:37 PM, Gregory Maxwell gmaxw...@gmail.com wrote: I'm concerned about how the particular security model of electrum is being described; or rather— not being described. Just to close the loop on this: I finally got in touch with Thomas on IRC and walked over the security

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Gregory Maxwell
On Mon, Nov 26, 2012 at 6:19 PM, Luke-Jr l...@dashjr.org wrote: On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote: They could be included as well of course, but from a seller perspective the most important thing is consistency. You have to be able to predict what CAs the user has,

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Gregory Maxwell
On Mon, Nov 26, 2012 at 9:16 PM, Walter Stanish wal...@stani.sh wrote: X-ISO4217-A3 I see that draft-stanish-x-iso4217-a3 is not standards track, is there a reason for this? It also doesn't appear to address ~any of the the targeted items here. Is there another draft I should be looking for

Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming

2012-12-03 Thread Gregory Maxwell
On Mon, Dec 3, 2012 at 7:24 AM, Michael Gronager grona...@ceptacle.com wrote: Bitcoin aka the blockchain is defined by the majority of the miners. This is what people have signed up to imo. A scheme that a) is of benefit for us all and b) is also of economical benefit for the miners, will

Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming

2012-12-03 Thread Gregory Maxwell
On Mon, Dec 3, 2012 at 10:00 AM, Mike Hearn m...@plan99.net wrote: The main source for these 1 Satoshi payouts is Sahtoshi Dice. Because people are making 1 satoshi bets, or is this part of their messaging system? It's part of their messaging system. Every losing play results in a new 1e-8

Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming

2012-12-03 Thread Gregory Maxwell
On Mon, Dec 3, 2012 at 2:50 PM, Andreas Petersson andr...@petersson.at wrote: These discussed features are all useful but quite contradicting. I imagine that a user will be able to switch between different coin selection policies minimize fees,max privacy,defragmentation,i don't care and even

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-12-03 Thread Gregory Maxwell
On Thu, Nov 29, 2012 at 12:31 PM, Mike Hearn m...@plan99.net wrote: 4) A longer term reason - in time, people may choose to not broadcast transactions at all in some cases. I think how network speed will be funded post-inflation is still an open question. Assuming the simplest arrangement

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn m...@plan99.net wrote: The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm not convinced this is the best use of time, but if somebody steps up to do it, that could also work. I strongly believe that if community leads with client

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 1:57 PM, Mark Friedenbach m...@monetize.io wrote: Alan's :( UTxO meta-chain proposal becomes vastly easier to do now that ultraprune is merged. No, not really. Somewhat easier due to some structural changes, but it still needs to invent and get consensus on a

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 3:58 PM, Mike Hearn m...@plan99.net wrote: It sounds to me that you're insisting that you're asking people who oppose degrading our recommendations to commit to a costly rushed development timeline. I think this is a false choice. Hardly. I don't have any particular

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 5:44 PM, Alan Reiner etothe...@gmail.com wrote: Greg's point looks like it's veering towards we don't want to grow the network unless we're going to get more full nodes out of it. No… There is no fundamental completion between taking what actions we can to maximize the

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 9:08 PM, Alan Reiner etothe...@gmail.com wrote: Our divergence is on two points (personal opinions): (1) I don't think there is any real risk to the centralization of the network by promoting a SPV (purely-consuming) node to brand-new users. In my opinion (but I'm not

Re: [Bitcoin-development] String-based Hierarchical Deterministic Keys - Alternative to BIP 32

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 10:06 PM, Mike Koss m...@coinlab.com wrote: I've implemented an alternative to the BIP 32 proposal. I wanted a system based on a hierarchical string representation (rather than hierarchy of integers as BIP 32 proposes). For example I name keys like this:

[Bitcoin-development] String-based Hierarchical Deterministic Keys - Alternative to BIP 32

2012-12-04 Thread Gregory Maxwell
On Tue, Dec 4, 2012 at 10:36 PM, Watson Ladd w...@uchicago.edu wrote: being able to spend a coin sent to an address generated by this scheme implies being able to spend any coin generated by this scheme. If you have the the full extended secret there then you can spend along the chain— but

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

2013-02-06 Thread Gregory Maxwell
On Wed, Feb 6, 2013 at 8:33 AM, Mike Hearn m...@plan99.net wrote: Can somebody please unlock the BIP wiki page? I don't know why it was locked but it's stale. I asked for permissions to unlock it but haven't heard back— will prod.

Re: [Bitcoin-development] Blockchain as root CA for payment protocol

2013-02-11 Thread Gregory Maxwell
On Mon, Feb 11, 2013 at 11:12 AM, Timo Hanke timo.ha...@web.de wrote: It's not about technical differences, but about the different use or purpose, which can result in different security demands. I argue that DNS has a lower demand in this respect than payment ids have. So DNS data can be in a

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-12 Thread Gregory Maxwell
On Tue, Feb 12, 2013 at 5:49 AM, Raph Frank raph...@gmail.com wrote: Has this been considered? If made sufficiently general, older clients could support any extension of the rules. Various hard parameters within the protocol are defined in main.h of the official client. In BIP-34, there

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-13 Thread Gregory Maxwell
On Wed, Feb 13, 2013 at 6:58 AM, Raph Frank raph...@gmail.com wrote: Bitcoin is not a democracy— it quite intentionally uses the consensus mechanism _only_ the one thing that nodes can not autonomously and interdependently validate (the ordering of transactions). So, how is max block size to

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-13 Thread Gregory Maxwell
On Wed, Feb 13, 2013 at 3:10 PM, Stephen Pair step...@bitpay.com wrote: If you've already validated the majority of transactions in a block, isn't validating the block not all that compute intensive? Thus, it's really not blocks that should be used to impose any sort of scarcity, but rather

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-13 Thread Gregory Maxwell
On Wed, Feb 13, 2013 at 7:42 AM, Gregory Maxwell gmaxw...@gmail.com wrote: I hope that should it become necessary to do so that correct path will be obvious to everyone, otherwise there is a grave risk of undermining the justification for the confidence in the immutability of any of the rules

Re: [Bitcoin-development] Incorporating block validation rule modifications into the block chain

2013-02-13 Thread Gregory Maxwell
On Wed, Feb 13, 2013 at 6:44 PM, Stephen Pair step...@bitpay.com wrote: One of the beauties of bitcoin is that the miners have a very strong incentive to distribute as widely and as quickly as possible the blocks they find...they also have a very strong incentive to hear about the blocks that

Re: [Bitcoin-development] Secure download

2013-03-03 Thread Gregory Maxwell
On Sun, Mar 3, 2013 at 10:54 AM, Roy Badami r...@gnomon.org.uk wrote: Would be nice to have a secure page at bitcoin.org, though, rathar than having to go to github - certs from somewhere like Namecheap should cost you next to nothing. For those of us too lazy (not paranoid enough) to bother

Re: [Bitcoin-development] Blocking uneconomical UTXO creation

2013-03-11 Thread Gregory Maxwell
On Mon, Mar 11, 2013 at 1:36 PM, Michael Gronager grona...@ceptacle.com wrote: The point with UTXO is in the long run to be able to switch from a p2p network where everyone stores, validates and verifies everything to a DHT where the load of storing, validating and verifying can be shared. I

Re: [Bitcoin-development] Warning: many 0.7 nodes break on large number of tx/block; fork risk

2013-03-12 Thread Gregory Maxwell
On Tue, Mar 12, 2013 at 2:10 AM, Mike Hearn m...@plan99.net wrote: BDB ran out of locks. However, only on some 0.7 nodes. Others, perhaps nodes using different flags, managed it. We have processed 1mb sized blocks on the testnet. Therefore it isn't presently clear why that particular block

Re: [Bitcoin-development] Some PR preparation

2013-03-12 Thread Gregory Maxwell
On Tue, Mar 12, 2013 at 9:55 AM, Alan Reiner etothe...@gmail.com wrote: I don't want to misrepresent what happened, but how much of that was really a risk? The block was rejected, but the transactions were not. Some but not much. If someone flooded a bunch of duplicate concurrently announcing

Re: [Bitcoin-development] Some PR preparation

2013-03-12 Thread Gregory Maxwell
On Tue, Mar 12, 2013 at 11:09 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Tue, Mar 12, 2013 at 10:35 AM, Peter Vessenes pe...@coinlab.com wrote: Can some enterprising soul determine if there were any double-spend attempts? I'm assuming no, and if that's the case, we should talk about

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Gregory Maxwell
On Wed, Mar 13, 2013 at 8:05 AM, Peter Todd p...@petertodd.org wrote: If we're going to consider doing this, at minimum we need to also I beg people to not derail discussion about fixing things with discussion of other controversial changes. Luke-jr, any chance in getting you to revise your

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Gregory Maxwell
On Wed, Mar 13, 2013 at 1:10 PM, Matthew Mitchell matthewmitch...@thelibertyportal.com wrote: Why would it be a difficulty in getting people to update away from 0.7 and earlier? How long would that roughly take? If people are hesitant to update, imagine if a more serious vulnerability is

[Bitcoin-development] On fork awareness Was: 0.8.1 ideas

2013-03-13 Thread Gregory Maxwell
On Wed, Mar 13, 2013 at 2:06 PM, Andy Parkins andypark...@gmail.com wrote: On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote: Here's a simple proposal to start discussion from... It seems to me that the biggest failure was not the development of two chains, but the assurance to users (by the

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Gregory Maxwell
On Wed, Mar 13, 2013 at 2:22 PM, Roy Badami r...@gnomon.org.uk wrote: The idea of the client detecting/warning about not-trivial forking seems worthwhile too, though, assuming it doesn't already (AIUI it doesn't). It does warn— if its heard the fork and its on the lower difficulty side.

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-15 Thread Gregory Maxwell
On Fri, Mar 15, 2013 at 10:06 AM, Benjamin Lindner b...@benlabs.net wrote: This. Software behavior which is not described by the source code should not be considered an integral part of the rule set. Any influence of external libraries on the consensus mechanism is unacceptable. No one

Re: [Bitcoin-development] A bitcoin UDP P2P protocol extension

2013-03-23 Thread Gregory Maxwell
On Sat, Mar 23, 2013 at 5:57 PM, Jay F j...@outlook.com wrote: My first concern was that I and about everyone else only has TCP/UDP port forwarding, You tunnel it! http://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-dtls-encaps-00 You could do worse to have a data stream that looks like WEBRTC

Re: [Bitcoin-development] Key retirement and key compromise

2013-03-25 Thread Gregory Maxwell
On Mon, Mar 25, 2013 at 1:49 PM, Roy Badami r...@gnomon.org.uk wrote: I'm not envisaging something as drastic as changing the rules to make transactions to revoked addresses invalid - just an overlay protocol. Although to be useful such a protocol would have to be pretty much universally

Re: [Bitcoin-development] A mining pool at 46%

2013-04-05 Thread Gregory Maxwell
On Fri, Apr 5, 2013 at 2:30 AM, Melvin Carvalho melvincarva...@gmail.com wrote: There was some chat on IRC about a mining pool reaching 46% http://blockchain.info/pools The estimates on there may be a bit lossy. What's the risk of a 51% attack. The whole fixation on 51 as a magic number is a

Re: [Bitcoin-development] A mining pool at 46%

2013-04-05 Thread Gregory Maxwell
On Fri, Apr 5, 2013 at 2:48 AM, Mike Hearn m...@plan99.net wrote: but I think p2pool still has a lot of problems dealing with FPGA/ASIC hardware and it hasn't been growing for a long time. As an aside and a clarification— P2pool works great with FPGAs, and one of the largest FPGA farms I've

Re: [Bitcoin-development] Integration testing for BitCoin

2013-04-05 Thread Gregory Maxwell
On Fri, Apr 5, 2013 at 10:24 AM, Adam Ritter arit...@gmail.com wrote: Hey guys, I just bought some BitCoins after being lazy to do it for the last few years, but also looked at the client code and the messages that are going on this mailing list. I saw that there are quite some unit tests,

Re: [Bitcoin-development] On-going data spam

2013-04-09 Thread Gregory Maxwell
On Tue, Apr 9, 2013 at 7:39 AM, Caleb James DeLisle calebdeli...@lavabit.com wrote: what anti-virus software might do when certain streams of bytes are sent across the tcp socket or persisted to disk. Perhaps worth contacting an AV company and asking what is the smallest data they have a

[Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution

2013-04-09 Thread Gregory Maxwell
(1) Define a new address type, P2SH^2 like P2SH but is instead H(H(ScriptPubKey)) instead of H(ScriptPubKey). A P2SH^2 address it is a hash of a P2SH address. (2) Make a relay rule so that to relay a P2SH^2 you must include along the inner P2SH address. All nodes can trivially verify it by

Re: [Bitcoin-development] To prevent arbitrary data storage in txouts — The Ultimate Solution

2013-04-10 Thread Gregory Maxwell
On Tue, Apr 9, 2013 at 11:53 PM, Peter Todd p...@petertodd.org wrote: Of course, either way you have the odd side-effect that it's now difficult to pay further funds to a random txout seen on the blockchain... strange, although possibly not a bad thing. Oh wow, thats actually a quite good

Re: [Bitcoin-development] Who is creating non-DER signatures?

2013-04-13 Thread Gregory Maxwell
On Sat, Apr 13, 2013 at 2:43 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Actual network rules will need to come later. However, even just not accepting them into memory pools will it make very hard (if not impossible) for the buggy clients that create transactions to get any confirmations.

Re: [Bitcoin-development] Service bits for pruned nodes

2013-04-28 Thread Gregory Maxwell
On Sun, Apr 28, 2013 at 9:29 AM, Mike Hearn m...@plan99.net wrote: I'd imagined that nodes would be able to pick their own ranges to keep rather than have fixed chosen intervals. Everything or two weeks is rather X most recent is special for two reasons: It meshes well with actual demand, and

Re: [Bitcoin-development] Service bits for pruned nodes

2013-04-28 Thread Gregory Maxwell
On Sun, Apr 28, 2013 at 7:57 PM, John Dillon john.dillon...@googlemail.com wrote: Have we considered just leaving that problem to a different protocol such as BitTorrent? Offering up a few GB of storage capacity is a nice idea but it means we would soon have to add structure to the network to

Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Gregory Maxwell
On Mon, May 6, 2013 at 10:19 AM, Peter Todd p...@petertodd.org wrote: running hash of all messages sent on a connection so far. Add a new protocol message that asks the node to sign the current accumulated hash. We already depend on OpenSSL, why not just use standard SSL? SSL doesn't actually

Re: [Bitcoin-development] Discovery/addr packets (was: Service bits for pruned nodes)

2013-05-06 Thread Gregory Maxwell
On Mon, May 6, 2013 at 10:53 AM, Peter Todd p...@petertodd.org wrote: We don't have non-repudiation now, why make that a requirement for the first version? Adding non-repudiation is something that has to happen at the Bitcoin protocol level,(1) so it's orthogonal to using SSL to make sure

Re: [Bitcoin-development] limits of network hacking/netsplits (was: Discovery/addr packets)

2013-05-06 Thread Gregory Maxwell
On Mon, May 6, 2013 at 3:51 PM, Adam Back a...@cypherspace.org wrote: Maybe I could hack a pool to co-opt it into my netsplit and do the work for me, or segment enough of the network to have some miners in it, and they do the work. Or you can just let it mine honestly and take the Bitcoins.

Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-15 Thread Gregory Maxwell
On Wed, May 15, 2013 at 6:24 PM, Gavin gavinandre...@gmail.com wrote: Busy with pre-conference stuff, not following details of this conversation... ... but it sounds a lot like the guy fawkes protocol Zooko was thinking about a year or so ago. Sort of, but in a guy fawkes signature you use

Re: [Bitcoin-development] blind symmetric commitment for stronger byzantine voting resilience (Re: bitcoin taint unilateral revocability)

2013-05-15 Thread Gregory Maxwell
On Wed, May 15, 2013 at 7:22 PM, Mike Hearn m...@plan99.net wrote: Conceptually it sounds a lot like ZeroCoin (not in implementation)? Zerocoin conceals the connection from everyone forever, assuming the underlying trapdoor problem is computational infeasible, but at great cost. Adamcoin,

Re: [Bitcoin-development] Double Spend Notification

2013-05-20 Thread Gregory Maxwell
On Mon, May 20, 2013 at 6:56 PM, Pieter Wuille pieter.wui...@gmail.com wrote: On Tue, May 21, 2013 at 3:24 AM, Robert Backhaus rob...@robbak.com wrote: So the decision has been made to make 0-conf double spends trivial, so no one will ever trust 0-confs. If a later transaction appears with a

Re: [Bitcoin-development] Double-Spending Fast Payments in Bitcoin due to Client versions 0.8.1

2013-06-27 Thread Gregory Maxwell
On Thu, Jun 27, 2013 at 3:23 AM, Arthur Gervais arthur.gerv...@inf.ethz.ch wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear Bitcoin developers, We would like to report a vulnerability which might lead, under some assumptions, to a double-spending attack in a fast payment scenario.

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-27 Thread Gregory Maxwell
On Thu, Jun 27, 2013 at 10:10 AM, Jim jim...@fastmail.co.uk wrote: Let me know if you think this is a good idea (or not!) and if you have any questions. Being able to promote a fast SPV desktop wallet would be great! I went through an cycle of testing on multibit after I saw some complaints

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-27 Thread Gregory Maxwell
On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit

Re: [Bitcoin-development] Review for slides for defeating trojans talk

2013-07-12 Thread Gregory Maxwell
On Fri, Jul 12, 2013 at 7:28 AM, Rob Meijer rmei...@xs4all.nl wrote: Completed the first draft of my slides+speaker-notes for my upcoming Defeating Trojans talk at the OHM2013. BitCoin is one of the main examples I use in this talk to emphasize the need for programs like BitCoin to have their

Re: [Bitcoin-development] Linux packaging letter

2013-07-23 Thread Gregory Maxwell
On Tue, Jul 23, 2013 at 4:23 PM, Greg Troxel g...@work.lexort.com wrote: Is the repeatable build infrastructure portable (to any reasonable mostly-POSIX-compliant system, with gcc or clang)? I have the vague It's portable to anything that can run the relevant VMs. Uh provided you don't mind

  1   2   3   4   >