Re: [Bitcoin-development] Building a node crawler to map network

2011-09-06 Thread Mike Hearn
Actually Steve, take a look at the bitcoinj mailing list today. Somebody has already built this and has it running. It's accumulating data at the moment, they'll announce it more widely soon. But I think there's no need to duplicate work.

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

2011-09-15 Thread Mike Hearn
If I think you're trying to DoS me, why would I be nice to you? The issue is, what if I'm not trying to DoS you, but something went wrong? think response messages would just give an attacker another potential attack vector, and it is clear from the debug.log what triggers a ban. Only clear

Re: [Bitcoin-development] Transaction Delivery and Storage

2011-10-05 Thread Mike Hearn
I imagine a lot of the things on the contracts page will be implemented by specialized software that interacts with the Bitcoin network directly. Transactions would then be moved around, for example, by having clients do HTTP POSTs of protocol buffers to servers that are listening and know how to

Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-25 Thread Mike Hearn
Interesting suggestion! So if I understand correctly, greensig would be the signature generated from signing the transaction with the key of a green address? Sure. Or just a key. It wouldn't have to be an actual key used in the block chain. Sounds good - I guess I never thought in this

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

2011-10-25 Thread Mike Hearn
scriptPubKeys that use OP_EVAL contain a hash of a script. If I understand correctly, that means to detect a transaction in a block that is relevant to your wallet, that means you need to pre-calculate every possible hash that might appear. For the case of a single payment, that's not a problem.

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-05 Thread Mike Hearn
BitCoinJ already sets the subver field to its name and version. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___

Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...

2011-11-12 Thread Mike Hearn
BIPs are either standards track (affects everyone, represents consensus), informational (ie basically just summarizing the authors viewpoints on things) or process. My point is you can't have a credible standards track BIP until something has been implemented end to end. I don't think it's a good

Re: [Bitcoin-development] multisig, op_eval and lock_time/sequence...

2011-11-12 Thread Mike Hearn
Sure, of course, as long as it's clearly labelled as just your thoughts, no issues. For dispute mediation the way I'd start is playing around with some UI design stuff and a toy protocol underneath. Once the process is smooth from the users POV (no seeing binary blobs disguised as text) then it

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

2011-11-12 Thread Mike Hearn
Looks pretty reasonable to me. If Gavin changes the mainline client to use this format I'll change BitcoinJ as well. It'll need a bit of API work so clients are sure to set it up properly. On Thu, Nov 10, 2011 at 10:16 PM, Amir Taaki zgen...@yahoo.com wrote: Hi,

[Bitcoin-development] [ANNOUNCE] BitCoinJ 0.3

2011-11-25 Thread Mike Hearn
Perhaps a bit off-topic for this list, maybe there should be a software/services announcements list? Anyway ... I'm happy to announce version 0.3 of the leading Java implementation of the Bitcoin protocol. BitCoinJ is a widely used library that forms the foundation of projects as diverse as the

Re: [Bitcoin-development] Version bytes 2.0

2011-12-13 Thread Mike Hearn
Why does anyone care what an address looks like? If the user is seeing an address, that's a usability fail right there. It's common today because AFAIK nobody finished off the URL handling support in the main client for browser integration. It'd be a much better use of time to finish off that

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

2011-12-13 Thread Mike Hearn
I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of their QR code and a bitcoin address. I don't own a mobile phone so the QR code is useless. Fixed addresses like that are a temporary thing during Bitcoins maturation period. They lead to merchants

Re: [Bitcoin-development] Version bytes 2.0

2011-12-13 Thread Mike Hearn
Base58 was chosen not for human readability but to make it easy to copy/paste. It was also chosen for hand-writeability, weirdly enough. That's why it excludes some confusible characters. But Satoshi didn't really understand how people would end up using Bitcoin, he originally imagined most

[Bitcoin-development] [ANNOUNCE] BitCoinJ 0.4

2012-03-09 Thread Mike Hearn
I'm pleased to announce the release of BitCoinJ 0.4, the leading Java implementation of the Bitcoin protocol. BitCoinJ implements simplified payment verification, a lightweight mode in which no central server or authority is needed but the resource requirements are still low enough to be usable on

[Bitcoin-development] Adding a pong message

2012-03-13 Thread Mike Hearn
https://github.com/bitcoin/bitcoin/pull/932 adds a pong message that echoes back a 64 bit nonce contained in the ping, if the protocol version is new enough. The goal of this is to make it easier for clients, especially mobile clients, to quickly check if a connection is stale, and also to see if

Re: [Bitcoin-development] Adding a pong message

2012-03-13 Thread Mike Hearn
TCP keep-alives aren't reliably implemented. I've got reports that sometimes we struggle to keep connection to the network on mobile, eg, because we roam into an area with poor connectivity but not poor enough for the network stack to drop access entirely. Being able to quickly check if the

[Bitcoin-development] BIP 31

2012-04-11 Thread Mike Hearn
Jeff asked for a BIP for the pong message, so here it is: https://en.bitcoin.it/wiki/BIP_0031 -- Better than sec? Nothing is better than sec when it comes to monitoring Big Data applications. Try Boundary one-second

Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior

2012-04-13 Thread Mike Hearn
It sounds OK as long as you exclude nLockTimed transactions. That said, if you broadcast a transaction that does not meet the fee rules, you should be able to notice that it wasn't accepted by your peers immediately. Today it's painful because the protocol isn't very chatty - in bitcoinj I plan

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

2012-05-02 Thread Mike Hearn
We're debating the descriptions on the thread. I provided rewritten descriptions that try and keep with the theme per client goal, whilst being less technical. I think it's unclear how best to run this page. It's clear we need one though. If everyone can just submit whatever they like then we'll

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

2012-05-02 Thread Mike Hearn
What computer is the initial start time 24-hours+ now? On normal systems initial sync-up now takes a couple hours. OK, I haven't tried a full block chain sync for a while. If it's only a couple of hours that's great. Let's change that.

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

2012-05-02 Thread Mike Hearn
Bitcoin-qt is translated into a pretty broad set of languages (now— I cant tell you how many of them are _good_). Listing language just under multibit makes it sound like a distinguishing characteristic. Fair enough then, let's take that out.

Re: [Bitcoin-development] BIP 33 - Stratized Nodes

2012-05-16 Thread Mike Hearn
Thanks for getting this started. With regards to the specific proposal, I don't believe it's the best option and still plan to eventually implement the original design outlined more than a year ago in this thread: https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285 Namely that

[Bitcoin-development] [ANNOUNCE] BitCoinJ 0.5 released

2012-05-30 Thread Mike Hearn
I'm pleased to announce the release of BitCoinJ 0.5, the library that powers Android Wallet, SatoshiDice, Bitcoin Status, the server side part of BCCAPI and much more. This release focusses on bug fixes, making the build more standard and completing the transition to the protobuf wallet format.

Re: [Bitcoin-development] Full Clients in the future - Blockchain management

2012-06-03 Thread Mike Hearn
Yeah, for actually storing transactions the approach Satoshi uses of relying on a database engine makes sense and is what the code already does, so I'm not sure why this is a problem. The real problem with Satoshis code for scaling down to smaller devices (and one day desktops too) is the need to

[Bitcoin-development] Bootstrapping full nodes post-pruning

2012-06-11 Thread Mike Hearn
Apologies if this has been discussed elsewhere. I don't recall us ever reaching a solid conclusion on it. A node that has pruned its block chain cannot serve the chain to new nodes. So there are three options for bootstrapping a newly installed node: 1) Have some kind of special archival nodes

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

2012-06-11 Thread Mike Hearn
If we wanted to go the route of shipping pruned chains I'd prefer to have a deterministic process to produce archival chains Yeah, that sounds reasonable. I mean, I can't see why pruning would not be deterministic. So if you download a binary that contains a pre-indexed and pruned chain up to

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

2012-06-11 Thread Mike Hearn
Actual BDB files are absolutely not deterministic. Nor is the raw blockchain itself currently, because blocks aren't always added in the same order (plus they get orphans in them) That's true. Though if you prune up to the last checkpoint, orphans before that point can be safely thrown away.

[Bitcoin-development] Near-term scalability

2012-06-15 Thread Mike Hearn
I had to hit the sack last night as it was 2am CET, but I'd like to sum up the discussion we had on IRC about scalability and SatoshiDice in particular. I think we all agreed on the following: - Having senders/buyers pay no fees is psychologically desirable even though we all understand that

Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

2012-06-15 Thread Mike Hearn
Need to specify the format of how these arrive. It means that when a new block is found instead of inv-getdata-block we'd see something like  inv-getdata-merkleblock where a merkleblock structure is a header + list of transactions + list of merkle branches linking them to the root. Thinking

Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

2012-06-15 Thread Mike Hearn
Yes, the format is something that must be hashed out (no pun intended).  Need input from potential users about what information they might need. Matts point that a branch-per-transaction may duplicate data is well made, that said, I suspect a format that tries to fix this would be much more

Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

2012-06-16 Thread Mike Hearn
- From: Mike Hearn m...@plan99.net To: Jeff Garzik jgar...@exmulti.com Cc: Bitcoin Development bitcoin-development@lists.sourceforge.net Sent: Friday, June 15, 2012 3:43 PM Subject: Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients Yes, the format is something

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

2012-06-17 Thread Mike Hearn
* 0x04 [32-byte X coord] [32-byte Y coord]: uncompressed format * 0x06 [32-byte X coord] [32-byte Y coord]: hybrid format for even Y coords * 0x07 [32-byte X coord] [32-byte Y coord]: hybrid format for odd Y coords So what's the actual difference in format? Is there any at all, or it's just

[Bitcoin-development] LevelDB benchmarking

2012-06-18 Thread Mike Hearn
I switched the transaction database to use the Google LevelDB library, which is a refactored out part of BigTable. Here are my results. All tests are done on this hard disk:

Re: [Bitcoin-development] LevelDB benchmarking

2012-06-19 Thread Mike Hearn
+list On Mon, Jun 18, 2012 at 9:07 PM, Gregory Maxwell gmaxw...@gmail.com wrote: In addition to the ECDSA caching,  ECDSA can can easily be run on multiple cores for basically a linear speedup.. so even with the checking in place once ECDSA was using multiple threads we'd be back to the DB

Re: [Bitcoin-development] LevelDB benchmarking

2012-06-19 Thread Mike Hearn
What problem does it solve? Primarily that block verification and therefore propagation is too slow because it's very CPU and IO intensive. The CPU work can be multi-threaded. The IO work, not as much. As Bitcoin grows we need to scale the nodes. Eventually there may be multi-machine nodes, but

Re: [Bitcoin-development] LevelDB benchmarking

2012-06-20 Thread Mike Hearn
Two days ago on #bitcoin-dev: 21:01:19 sipa what was CTxDB::ReadOwnerTxes ever used for? 21:01:31 sipa maybe it predates the wallet logic (read: it's not used anywhere in the code, and apparently wasn't ever, even in 0.1.5) Great, in that case Stefan is right and I'll delete that code when

[Bitcoin-development] Enforcing inflation rules for SPV clients

2012-06-24 Thread Mike Hearn
I've been having a discussion with d'aniel from the forums about how to handle the possibility of a majority-miner conspiracy to raise inflation, if most economic actors use SPV clients. Because of how blocks are formatted you cannot check the coinbase of a transaction without knowing the fees in

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

2012-06-25 Thread Mike Hearn
Link? It was a private conversation for some reason. I also proposed this on this list (see the response in the tree datastructures thread) along with more elaboration on IRC. Ah OK. I wasn't paying much attention to those threads.

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

2012-06-25 Thread Mike Hearn
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. Yeah. I am still unsure that this really holds. Bitcoin moves fast, but

Re: [Bitcoin-development] LevelDB benchmarking

2012-06-25 Thread Mike Hearn
on this again until next week. On Wed, Jun 20, 2012 at 2:41 PM, Mike Hearn m...@plan99.net wrote: Two days ago on #bitcoin-dev: 21:01:19 sipa what was CTxDB::ReadOwnerTxes ever used for? 21:01:31 sipa maybe it predates the wallet logic (read: it's not used anywhere in the code, and apparently wasn't

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

2012-07-09 Thread Mike Hearn
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.org - after a frustrating experience with their listing [1] Probably because their listing is even more useless than any of the proposals that were presented

[Bitcoin-development] Accepting broken QRcodes

2012-07-15 Thread Mike Hearn
Hi bitcoin-development, blockchain.info generates non-BIP-compliant URIs in its QRcodes, as does its iPhone app. They are of the form bitcoin://address not bitcoin:address. I asked Ben to fix this (social networks don't parse QRcodes after all), but after explaining that social networks don't

Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients

2012-07-21 Thread Mike Hearn
One thing that occurred to me recently is that it'd be useful if filters could contain exact matches as well as Bloom filters. Specifically I'm thinking of things like my bond network proposal where some outputs may be marked as special using script fragments like BOND data or hash of data 2DROP.

Re: [Bitcoin-development] Reconsidering block version number use

2012-07-24 Thread Mike Hearn
That'd be 7 bytes of nonce in the block header, which is 72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes So: the changes for version 2 blocks would be has height in the coinbase, and has a 1-byte version number with a 3-byte extranonce. I don't understand why more nonce bits

Re: [Bitcoin-development] Reconsidering block version number use

2012-07-24 Thread Mike Hearn
My point is that stuffing nonces into whatever spaces we can find to eke out a bit more scalability in pools seems like a very short term fix with potentially very long term consequences. Although it may sound harsh, if your pool is struggling to keep up with calculating merkle roots (which is

Re: [Bitcoin-development] Scalability issues

2012-07-24 Thread Mike Hearn
The Satoshi client uses a pure reentrant mutexes model As you presumably already know, the reference client doesn't attempt to parallelise most operations at all. Chain download is entirely single threaded. -- Live

Re: [Bitcoin-development] Bitcoin script opcode counts

2012-07-26 Thread Mike Hearn
OP_CODESEPARATOR 14 OP_DEPTH 182 I'm interested to see what scripts were using OP_DEPTH and OP_CODESEPARATOR, as the latter appears to be useless to my eyes. Could you give some tx ids which use unusual opcodes? --

[Bitcoin-development] Signing release binaries

2012-07-29 Thread Mike Hearn
MacOS X 10.8 makes application signing borderline mandatory, in that you cannot run unsigned apps unless you tweak your settings via the control panel. You must sign with a certificate issued by Apple via their identified developer program. Windows allows but does not require signing. However,

Re: [Bitcoin-development] BIP: Custom Services

2012-08-13 Thread Mike Hearn
I think it's pretty reasonable, although people will want to use node flags to get into the addr broadcasts anyway. That said, I suspect (based on previous discussions) that there would be quite some pushback against putting extra functionality into the core Bitcoin network. Most likely people

Re: [Bitcoin-development] Bloom Filter Implementation

2012-08-15 Thread Mike Hearn
This is great, thanks! A few remarks: If you have to update the filter after every block, IBD will require a round-trip after every single block download instead of doing bulk requests with getblocks. That sounds like it'd kill any performance gains won by the feature. There needs to be a way to

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

2012-08-17 Thread Mike Hearn
I think MSG_TX is fine. Simply sending an inv to the other node at startup would work, but it's better to request it explicitly as it will let the connecting peer configure a bloom filter before requesting mempool contents. It's already too heavy for mobile clients to download the entire mempool

Re: [Bitcoin-development] Atomic coin swapping?

2012-09-22 Thread Mike Hearn
Why Signing the input scripts as well would obviously make it impossible to construct a transaction? As it states in the source code, signatures cannot sign themselves. If scriptSigs were included in the data that is being signed, the act of inserting the newly calculated signature for one

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

2012-09-23 Thread Mike Hearn
Sounds good— my only concern is that nodes will repeat their own transactions but not the unconfirmed parents. Nodes repeat wallet transactions and any previous transactions that are not yet included in the chain (see CWalletTx::RelayWalletTransaction). So I don't think it's an issue. (ok,

[Bitcoin-development] bitcoinj 0.6 now available

2012-09-24 Thread Mike Hearn
I'm pleased to announce the release of version 0.6 of bitcoinj, the leading Java implementation of Bitcoin. You can download the source from Google Code, or use the release-0.6 branch from git. Our Nexus repository will be updated soon. This release focuses on improved compliance with the

[Bitcoin-development] Payment protocol thoughts

2012-10-02 Thread Mike Hearn
I've been thinking about the requirements for a payment protocol lately. It seems we have consensus that we need one of these. Pieter has a gist on the topic here: https://gist.github.com/1237788 IMHO we'll want to move away from send X BTC to address Y and more towards upload to me transactions

Re: [Bitcoin-development] Payment protocol thoughts

2012-10-02 Thread Mike Hearn
I think it's worth pondering the different things we may want in future, even if that future is quite far out, just to ensure we have a robust design that won't box us in later. Brainstorming feature ideas now doesn't commit anyone to implementing them, but it may help improve the final v1 design.

Re: [Bitcoin-development] Electrum security model concerns

2012-10-10 Thread Mike Hearn
+gary Electrum also has a daemon for merchants. Well, I suggest taking it up with Thomas directly. A thread here won't do much. Considering the dislike of Java that exist reflexively in much of the non-java community and the greater ease of deployment and the integration of type-2 split key

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

2012-10-21 Thread Mike Hearn
No objections. On Sun, Oct 21, 2012 at 7:05 PM, Gavin Andresen gavinandre...@gmail.com wrote: Any objections from other transaction-validating implementations? I strongly support more precisely defining the transaction validity rules by changing the reference implementation. -- -- Gavin

[Bitcoin-development] Draft BIP for Bloom filtering

2012-10-24 Thread Mike Hearn
I've written a draft BIP describing the bloom filtering protocol extension developed by myself and Matt. https://en.bitcoin.it/wiki/BIP_0037 (yes I know there's some kind of process around getting allocated a number - it seems overkill for this). Please read it and let me know if there are any

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

2012-10-24 Thread Mike Hearn
Some questions: * why limit the number of matching transactions to 255? Copy/paste error in the does :( * what does each hash and key in the output script mean exactly? what about the output script in its entirety? It's an informal way to say data elements. If you insert a key then it

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

2012-10-24 Thread Mike Hearn
What is the worst-case for an attacker interested in trying to get you to saturate your upstream bandwidth or use lots of memory? Set a bloom filter that matches everything, and then start requesting old blocks in the chain? It would be slightly worse than shipping a full block but not

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

2012-10-26 Thread Mike Hearn
Presumably these components will just get implemented a few times in some carefully constructed library code, so I don't see an implementation complexity argument here— except the fact that it isn't what Matt has implemented so far. Well, yes, that is basically the implementation complexity

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

2012-10-26 Thread Mike Hearn
Because I can potentially waste bandwidth of all nodes forever (well as long as users are still scanning blocks with my transactions in them) with O(1) work. And this gets you what? Users who have active wallets will have their bandwidth wasted for as long as you keep up the attack. Once you

Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

2012-11-08 Thread Mike Hearn
I won't be able to make it this time. My feeling is IRC is a good place to bounce ideas around when time and people happen to be available, but having meetings there will inevitably lead to decision making that's better done in a slower manner via email. Comments: BIP process: are we happy

Re: [Bitcoin-development] Electrum security model concerns

2012-11-16 Thread Mike Hearn
there's no re-org handling at all. If Electrum does end up doing all SPV work correctly, how is it different to MultiBit? Just the deterministic wallet seeding? On Fri, Nov 16, 2012 at 4:59 PM, Mike Hearn m...@plan99.net wrote: Great to hear

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

2012-11-27 Thread Mike Hearn
On Tue, Nov 27, 2012 at 9:43 AM, Michael Gronager grona...@ceptacle.com wrote: * What if the SignedReceipt is not received AND the transactions IS posted on the p2p. I think this is a problem with confusing terminology rather then the spec itself. The original formulation had a receipt being

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

2012-11-27 Thread Mike Hearn
That hash would then be reported via some secure channel outside of bitcoin's domain. OK, I see. I guess that could be a reasonable fallback for the case where you have a secure channel. I don't understand what the relevance of multi-factor is to invoices? Yes, exactly. It's about paying who

Re: [Bitcoin-development] [ANNOUNCE] picocoin and libccoin -- C-based bitcoin library and client

2012-11-28 Thread Mike Hearn
Cool, will check it out soon. libccoin should work on Windows. picocoin will work on Windows, but be a bit less secure than other platforms due to lack of fork. FYI, Windows has quite good sandboxing support. You could implement the same thing later with Win32 if you want.

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

2012-11-29 Thread Mike Hearn
I'd still like to understand the rationale for having the merchant broadcast the transaction There are several reasons for this: 1) P2P network sockets are a limited resource and bringing up connections to the network, whilst somewhat fast today, is not guaranteed to be fast in future. Passing

Re: [Bitcoin-development] Has anyone compiled under MacOS 10.8?

2012-11-29 Thread Mike Hearn
I found that the problem is the version of the Qt SDK I used didn't like the new MacOS version. Re-installing Qt fixed it. On Mon, Nov 26, 2012 at 4:05 PM, Mike Hearn m...@plan99.net wrote: It appears that something about Boost doesn't play nicely with the default build instructions (possibly

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

2012-12-03 Thread Mike Hearn
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? Pieter is right, getting consensus behind your proposal is too hard and it's not likely to ever happen (I wouldn't support it, for one). Outputs

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

2012-12-03 Thread Mike Hearn
It's part of their messaging system. Every losing play results in a new 1e-8 output being created. Every losing play? That's ... not excellent. Well, this why the payment protocol spec has a way for merchants to reply to customers with text instead of outputs.

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

2012-12-03 Thread Mike Hearn
Perhaps it could be improved by cleaning up dust from any address by default (not just ones already included in the tx), with the option for the user to disable that behavior. After all, anonymity was never a core feature of the network It's cool that Armory already does this. I never had

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

2012-12-04 Thread Mike Hearn
So, if a bitcoin client is getting Invoice messages via email or from a web server, the version will be specified as part of the MIME type; for example: Content-Type: application/x-bitcoin-invoice; version=1 The version= syntax is part of the MIME standard. I think that's OK. However, you

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

2012-12-04 Thread Mike Hearn
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 timeline in mind. But I disagree we have forever. New ideas have a

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

2012-12-05 Thread Mike Hearn
I was under the impression that connectedness was the real metric of concern I think the real thing we need full nodes for is sockets where by socket I mean resources needed to serve another node. Last year we actually ran out of sockets and it took forever for new nodes to connect because so

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

2012-12-06 Thread Mike Hearn
Escrow/multisig is complicated enough to wait for another day. But certainly having a payment protocol is an important step towards it On 6 Dec 2012 07:32, Andreas Petersson andr...@petersson.at wrote: During/before the Payment Request there should be a method to exchange the public keys to be

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

2012-12-06 Thread Mike Hearn
Re: the newest spec. Rather than make the signature over the concatenation of, why not just make it a signature over the serialized protobuf minus the signature field (as I did in my demo code). Otherwise it seems like we'd need more code than really necessary. We can state explicitly tags must be

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

2012-12-07 Thread Mike Hearn
OK. I want to keep the signature field required, though, so how about: signature: digital signature over a protocol buffer serialized variation of the SignedPaymentRequest message where signature is a zero-byte array and fields are serialized in numerical order (all current protocol buffer

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

2012-12-07 Thread Mike Hearn
mitigations into something like this, for the same reason HTML doesn't impose a maximum page size. It's in the message builders interest to ensure it gets read by all users. Crashing their clients doesn't achieve anything as long as the crash isn't exploitable. On Fri, Dec 7, 2012 at 11:45 AM, Mike

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

2012-12-07 Thread Mike Hearn
yeah... I had similar thoughts on what to do if some Outputs specify an amount and others don't. I'm still waffling on whether or not I like allowing repeated Outputs; a single Output would make the spec a fair bit simpler Yes, but at the cost of privacy. Generators of payment requests always

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

2012-12-20 Thread Mike Hearn
Thanks for the thoughts. For those who don't know, Stephen works for BitPay. My first observation is that the proposal is too heavily oriented around a merchant/customer interaction. The term merchant is just being used to mean the entity requesting the payment. I'm hopeful that in future

Re: [Bitcoin-development] Has anyone compiled under MacOS 10.8?

2012-12-27 Thread Mike Hearn
++, which perhaps ends up making gcc stricter than it's supposed to be. On Thu, Nov 29, 2012 at 8:34 PM, Mike Hearn m...@plan99.net wrote: I found that the problem is the version of the Qt SDK I used didn't like the new MacOS version. Re-installing Qt fixed it. On Mon, Nov 26, 2012 at 4:05 PM

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

2013-01-10 Thread Mike Hearn
Here's a quick update on where we're up to. Thanks to Matts excellent work, I was able to test his bitcoinj and bitcoin-qt work together today. There are a few minor tweaks needed, but I feel like we're maybe a week away from having all the code in a mergeable state. Here is the remaining work:

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

2013-01-11 Thread Mike Hearn
Oh, one last stat - syncing the entire chain with a wallet containing two keys and a 0.0001 FP rate (one or two FPs every 5 blocks or so) resulted in a download of about 46mb of data. On Fri, Jan 11, 2013 at 3:11 PM, Mike Hearn m...@plan99.net wrote: I did some very rough initial performance

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

2013-01-16 Thread Mike Hearn
Matts latest code has been tested by Andreas and seems to work correctly. He had to extend the client a bit to refresh the filter every 25k blocks because even with the extra flag, eventually the filter degrades into uselessness, but it did still improve the situation quite a bit. Because it's

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

2013-01-18 Thread Mike Hearn
algorithmic change I would like to make to the way the hash function is computed really quick before it gets merged, I'll have that finished up by the end of today. Matt On Wed, 2013-01-16 at 11:43 +0100, Mike Hearn wrote: Matts latest code has been tested by Andreas and seems to work

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

2013-01-30 Thread Mike Hearn
, as otherwise there's a risk that 0.7 snapshot nodes will get overloaded. On Wed, Jan 30, 2013 at 12:09 PM, Mike Hearn m...@plan99.net wrote: Andreas has uploaded Android builds that use the new bloom filtering and peer selection code (also, dependency analysis of transactions). The performance gain

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

2013-02-06 Thread Mike Hearn
Can somebody please unlock the BIP wiki page? I don't know why it was locked but it's stale. On Wed, Jan 30, 2013 at 12:13 PM, Mike Hearn m...@plan99.net wrote: Sorry, to clarify, these are test builds available here: https://code.google.com/p/bitcoin-wallet/downloads/detail?name=bitcoin

Re: [Bitcoin-development] RFC: empty scriptPubKeys and OP_RETURN for marking unspendable txouts

2013-02-13 Thread Mike Hearn
So what exactly was the OP_RETURN bug anyway? I know it has something to do with not executing the scriptSig and scriptPubKey separately (https://bitcointalk.org/index.php?topic=58579.msg691432#msg691432) but commit 7f7f07 that you reference isn't in the tree, nor is 0.3.5 tagged. It was

[Bitcoin-development] bitcoinj 0.7 released

2013-02-19 Thread Mike Hearn
I'm pleased to announce the release of version 0.7 of the bitcoinj Java library for working with Bitcoin. Bitcoinj forms the foundation of MultiBit, Bitcoin Wallet for Android, SatoshiDice and more. To get bitcoinj 0.7, check out our source from git and then run *git reset --hard a9bd8631b904*.

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

2013-02-20 Thread Mike Hearn
: 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] Large-blocks and censorship

2013-03-07 Thread Mike Hearn
To summarize your post - it's another go at arguing for strongly limited block sizes, this time on the grounds that large blocks make it easier for $AUTHORITY to censor transactions? Is that right? -- Symantec Endpoint

Re: [Bitcoin-development] Large-blocks and censorship

2013-03-07 Thread Mike Hearn
As an aside, there's a paper coming out in perhaps a few months that describes a new way to provide Chaum-style privacy integrated with Bitcoin, but without the use of blinding and without any need for banks. It's quite smart, I was reviewing the paper this week. Unfortunately the technique is too

Re: [Bitcoin-development] Blocking uneconomical UTXO creation

2013-03-11 Thread Mike Hearn
Why does demurrage even still come up? The base rules of Bitcoin will not be changing in such a fundamental way. With regards to trying to minimize the size of the UTXO set, this again feels like a solution in search of a problem. Even with SD abusing micropayments as messages, it's only a few

Re: [Bitcoin-development] Blocking uneconomical UTXO creation

2013-03-11 Thread Mike Hearn
This would be bloating UTXO data at a speed of 52 GB/year. That's a very big memory leak. And this is just the unspendable outputs. Firstly, the UTXO set is a LevelDB, it's not stored in memory. Outputs that never get spent are not in the working set by definition, after a while they just end

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

2013-03-12 Thread Mike Hearn
Just so we're all on the same page, can someone confirm my understanding - are any of the following statements untrue? 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

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

2013-03-12 Thread Mike Hearn
However, most nodes are not running in such a loop today. Probably almost no nodes are. I suppose you could consider mass node death to be more benign than a hard fork, but both are pretty damn serious and warrant immediate action. Otherwise we're going to see the number of nodes drop sharply

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

2013-03-12 Thread Mike Hearn
We just saw a hard-fork happen because we ran into previously unknown scaling issues with the current codebase. Technically, it with the previous codebase ;) -- Symantec Endpoint Protection 12 positioned as A LEADER in

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

2013-03-12 Thread Mike Hearn
I'm not even sure I'd say the upgrade went wrong. The problem if anything is the upgrade didn't happen fast enough. If we had run out of block space a few months from now, or if miners/merchants/exchanges had upgraded faster, it'd have made more sense to just roll forward and tolerate the loss of

  1   2   3   4   5   6   7   >