Re: [Bitcoin-development] 0.4rc1 known bugs]

2011-09-04 Thread Pieter Wuille
On Sat, Sep 03, 2011 at 08:13:14PM -0400, Gavin Andresen wrote: Quick status update on 0.4; I probably won't have time to tackle these properly before Tuesday: + sipa found what looks like a deadlock between the addr-handling and IRC-join-handling code. I've compiled bitcoind with Gavin's

Re: [Bitcoin-development] 0.4rc1 known bugs

2011-09-06 Thread Pieter Wuille
On Sun, Sep 4, 2011 at 13:59, Pieter Wuille pieter.wui...@cs.kuleuven.be wrote: I've compiled bitcoind with Gavin's DEBUG_LOCKORDER, and fixed two potential reported deadlock issues (see https://github.com/sipa/bitcoin/commits/lockfixes). My mistake: these are not actual potential deadlocks

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

2011-10-24 Thread Pieter Wuille
On Mon, Oct 24, 2011 at 10:29:57AM +0200, Jan Vornberger wrote: Hi there! As part of my green address endeavor, I'm currently trying to extend the 'gettransaction' call to include an extra field inputaddresses which should return a list of the Bitcoin addresses associated with the inputs of

Re: [Bitcoin-development] Difficulty adjustment / time issues

2011-11-07 Thread Pieter Wuille
On Tue, Sep 13, 2011 at 11:06:37AM -0400, Gavin Andresen wrote: Background: Timejacking: http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html And a recent related exploit launched against the low-difficulty alternative chains:

Re: [Bitcoin-development] Difficulty adjustment / time issues

2011-11-07 Thread Pieter Wuille
On Mon, Nov 07, 2011 at 10:27:57AM -0500, Luke-Jr wrote: On Monday, November 07, 2011 10:02:43 AM Pieter Wuille wrote: Maybe a short interval (1 minute? 10 minutes?) instead of a fixed value could be allowed for the multiple-of-2016 blocks. Reminder that there is *already* a short interval

[Bitcoin-development] Compressed public keys

2011-11-20 Thread Pieter Wuille
Hello all, I just submitted a pull request (#649) that enables the use of compressed public keys in Bitcoin. As discovered by roconnor (IRC), this is possible in such a way that old clients verify and relay them without problems. They are supported by default by OpenSSL, and all alternative

Re: [Bitcoin-development] Compressed public keys

2011-11-21 Thread Pieter Wuille
On Mon, Nov 21, 2011 at 03:34:28AM +0100, Pieter Wuille wrote: Hello all, Things that need attention: * Do all client implementations support it? To help in testing this: this address corresponds to a compressed public key: http://blockexplorer.com/testnet/address

Re: [Bitcoin-development] Version bytes 2.0

2011-12-12 Thread Pieter Wuille
It seems base58 is actually quite terrible for producing nice human-recognizable addresses, even though base58 is specially intended for human usage. We'll just have to deal with it, or completely overhaul it and move to a saner encoding. Luke's proposal is somewhat more drastic than my original

Re: [Bitcoin-development] Pubkey addresses

2011-12-18 Thread Pieter Wuille
On Sun, Dec 18, 2011 at 01:15:26PM +0100, Jorge Timón wrote: But anyway, reading some comments I feel I'm missing something about this proposal. How can you save space by putting the whole public key instead of just the address (a hash of the public key) with each output? Is this what it's

Re: [Bitcoin-development] Alternative to OP_EVAL

2011-12-29 Thread Pieter Wuille
On Thu, Dec 29, 2011 at 08:08:38PM +0100, Pieter Wuille wrote: On Thu, Dec 29, 2011 at 01:55:03AM -0500, rocon...@theorem.ca wrote: Gavin asked me to come up with an alternative to OP_EVAL, so here is my proposal. OP_CODEHASH Initial Proposal If we're again brainstorming about

[Bitcoin-development] [ANN] Bitcoin-seeder v0.1

2012-01-01 Thread Pieter Wuille
Hello all, I've just tagged v0.1.0 of my bitcoin-seeder program on github: https://github.com/sipa/bitcoin-seeder This is the program powering the DNS seed on seed.bitcoin.sipa.be. It is a crawler for the bitcoin network, with integrated DNS server. It's not more than a preview release with

Re: [Bitcoin-development] Pull 748 pay to script hash

2012-01-08 Thread Pieter Wuille
On Sat, Jan 07, 2012 at 08:12:35PM -0500, Gavin Andresen wrote: Pieter's compressed-public-keys patch (which was just pulled) Uhm, was it? I just added some unit tests though. interacts with pay-to-script-hash to make ECDSA denial-of-service attempts less expensive; I think we need to think

[Bitcoin-development] Compressed public keys: import/export and test cases

2012-01-09 Thread Pieter Wuille
Hello all, pull #649 now also defines an import/export format for private keys whose public key is compressed. Rationale: even though a compressed and uncompressed public key share the same actual 32-byte secret, the import/export format needs a marker that states whether the corresponding

Re: [Bitcoin-development] some feedbacks

2012-01-15 Thread Pieter Wuille
On Sat, Jan 14, 2012 at 08:19:29AM -0700, Roger Pack wrote: Since I seemingly could not find the create new post link on the forum, resorting to here... a few feedbacks: 1) It would be helpful I think to, when the client first starts, to ask do you want to set a password to encrypt your

Re: [Bitcoin-development] BIP 21 (modification BIP 20)]

2012-01-31 Thread Pieter Wuille
On Tue, Jan 31, 2012 at 09:35:26AM +0100, Wladimir wrote: I also wonder whether the send to private address should be part of this BIP, or a future one. It is actually a send of private key, not to. And I agree, it should be part of a separate BIP. -- Pieter

Re: [Bitcoin-development] BIP 21 (modification BIP 20)

2012-01-31 Thread Pieter Wuille
On Tue, Jan 31, 2012 at 10:01:00AM +, Gary Rowe wrote: Personally, I feel that simple is best and while a block number represents Bitcoin's pulse, there is no guarantee that a block will be discovered at any particular moment. From a merchant perspective the main point of the expires field

Re: [Bitcoin-development] BIP16/17 replacement

2012-02-01 Thread Pieter Wuille
Op 1 feb. 2012 10:48 schreef Andy Parkins andypark...@gmail.com het volgende: On 2012 January 31 Tuesday, Luke-Jr wrote: Both BIP 16 and 17 are backward compatible enough that people can continue to use the old clients with each other. An upgrade is only required to send to (or

Re: [Bitcoin-development] Announcement: libcoin

2012-02-02 Thread Pieter Wuille
You will also find the RPC server in libcoin blistering fast compared to the Satoshi client. (It was actually what got me to write libcoin in the first place...). The Satoshi client HTTP server executes all rpc commands in its own thread, but to do so, it needs to stop the thread of the Node,

Re: [Bitcoin-development] Duplicate transactions vulnerability

2012-02-29 Thread Pieter Wuille
On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote: Could you spell out the attack explicitly? Presumably there aren't a lot of people with the malice energy to perform the attack but not to figure it out for themselves. I, however, have the niceness energy to think about it

Re: [Bitcoin-development] Duplicate transactions vulnerability

2012-03-01 Thread Pieter Wuille
On Tue, Feb 28, 2012 at 17:48, Pieter Wuille pieter.wui...@gmail.com wrote: I've written about it in BIP30[2]. There is a patch for the reference client, which has been tested and verified to make the attack impossible. The change is backward compatible in the same way BIP16

Re: [Bitcoin-development] Duplicate transactions vulnerability

2012-03-03 Thread Pieter Wuille
On Tue, Feb 28, 2012 at 17:48, Pieter Wuille pieter.wui...@gmail.com wrote: Hello all, I've written about it in BIP30[2]. There is a patch for the reference client, which has been tested and verified to make the attack impossible. The change is backward compatible in the same way BIP16

Re: [Bitcoin-development] 0.7 merge recommendations/status

2012-03-31 Thread Pieter Wuille
On Sat, Mar 31, 2012 at 12:03:17AM -0400, Luke-Jr wrote: NOTE: I've been piecing this together for about a week now, and intended to update it when 0.6.0 final was released, but with the timing of it, I just won't get the time to update for a while, so here is my last draft... Nice summary,

Re: [Bitcoin-development] 0.7 merge recommendations/status

2012-03-31 Thread Pieter Wuille
On Sat, Mar 31, 2012 at 12:54:02PM +0200, Pieter Wuille wrote: Something else was suggested by Jeff: what if a node accidentally connects to itself? As we're moving towards multiple local addresses with IPv6, the chances for this become larger. Finally, there are always extra risks involved

Re: [Bitcoin-development] 0.7 merge recommendations/status

2012-03-31 Thread Pieter Wuille
On Sat, Mar 31, 2012 at 01:16:56PM +0200, Michael Grønager wrote: If you are interested, I could push libcoin to bitcoin (e.g. bitcoin/libcoin) and then you could build bitcoind bitcoin-qt on libcoin. libcoin solved most of the problems you list below. And if you worry about the

[Bitcoin-development] Network version increase

2012-04-02 Thread Pieter Wuille
Hello all, Mike Hearn has submitted a pull request to add a pong message in reply to a ping. This warrants an upgrade of the network protocol version number, which is since BIP14 independent from the version numbers of the reference client. Any opinions about a numbering scheme? Currently the

Re: [Bitcoin-development] Adding request/reply id in messages

2012-04-12 Thread Pieter Wuille
On Thu, Apr 12, 2012 at 11:41:05AM -0400, Gavin Andresen wrote: On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt sirk...@gmail.com wrote: I would like to discuss the following bitcoin protocol improvement proposal:          Adding request/reply id in all messages (in the message header,

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

2012-04-14 Thread Pieter Wuille
On Sat, Apr 14, 2012 at 04:20:50PM -0400, Jeff Garzik wrote: Furthermore, many of these ideas -- like sending TX's directly to the merchant -- involve far more direct payee-payer communication on the part of the wallet client than is currently envisioned Yes, though it's worth

Re: [Bitcoin-development] Potential network split when individual tx used as coinbase?

2012-05-05 Thread Pieter Wuille
On Sat, May 05, 2012 at 09:31:39AM +0100, Rebroad (sourceforge) wrote: Hi, Looking at: https://github.com/bitcoin/bitcoin/commit/3e52aaf2121d597ab1ed012b65e37f9cb5f2754e#src/main.cpp-P52 It appears that 8 months ago the code was changed to DoS(100) nodes sending on txs that use

[Bitcoin-development] IPv6 bitcoin support now live

2012-05-26 Thread Pieter Wuille
On Sat, May 12, 2012 at 3:42 AM, Jeff Garzik jgar...@exmulti.com wrote: sipa just pushed out IPv6 support to bitcoin/bitcoin.git, and we have a few IPv6 nodes live on the network already. If you have IPv6, please pull the latest bitcoin and test! Since yesterday, my DNS seeder (running at

[Bitcoin-development] getmemorypool

2012-06-11 Thread Pieter Wuille
Hello everyone, Luke's getmemorypool/BIP22 pull request has been open for a long time, and didn't receive too much discussion. I think that having a stable and flexible API for negotiating block generation is important to be standardized. The fact that it allows moving block generation to

[Bitcoin-development] BIP22/getmemorypool

2012-06-11 Thread Pieter Wuille
- Forwarded message from Pieter Wuille pieter.wui...@gmail.com - Date: Sun, 10 Jun 2012 01:10:54 +0200 From: Pieter Wuille pieter.wui...@gmail.com To: bitcoin-development@lists.sourceforge.net Subject: getmemorypool User-Agent: Mutt/1.5.20 (2009-06-14) Hello everyone, Luke's

Re: [Bitcoin-development] BIP22/getmemorypool

2012-06-12 Thread Pieter Wuille
On Mon, Jun 11, 2012 at 08:10:22PM +0200, thoma...@gmx.de wrote: discussion back here. The executive summary: Pieter and I feel like BIP 22 is overly complicated, and would like it to be simpler. I'd especially like to hear what people think will be the will be used by lots of pool

Re: [Bitcoin-development] Manual file cleanup on exit, safe? [coredump backtrace]

2012-06-15 Thread Pieter Wuille
On Fri, Jun 15, 2012 at 04:58:55PM -0400, grarpamp wrote: When bitcoind exits cleanly, it does not seem safe for the blockchain to clean up the following hierarchy with rm -r ? Use -detachdb if you want to detach the blockchain database files from the database environment at exit. This was

[Bitcoin-development] After compressed pubkeys: hybrid pubkeys

2012-06-16 Thread Pieter Wuille
Hello all, while OpenSSL's silent support for compressed public keys allowed us to enable them in a fully backward-compatible way, it seems OpenSSL supports yet another (and non-standard, and apparently useless) encoding for public keys. As these are supported by (almost all?) fully validating

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

2012-06-17 Thread Pieter Wuille
On Sun, Jun 17, 2012 at 01:01:12PM +0200, Mike Hearn wrote: * 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

[Bitcoin-development] Tor hidden service support

2012-06-26 Thread Pieter Wuille
Hello everyone, a few days ago we merged Tor hidden service support in mainline. This means that it's now possible to run a hidden service bitcoin node, and connect to other bitcoin hidden services (via a Tor proxy) when running git HEAD. See doc/Tor.txt for more information. This is expected to

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

2012-07-06 Thread Pieter Wuille
Hello all, I've implemented a new block/transaction validation system for the reference client, called ultraprune. Traditionally, pruning for bitcoin is considered to be the ability to delete full transactions from storage once all their outputs are spent, and they are buried deeply enough in

Re: [Bitcoin-development] Scalability issues

2012-07-27 Thread Pieter Wuille
And now to the list... On Jul 27, 2012 6:21 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

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

2012-08-16 Thread Pieter Wuille
On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote: Consensus was we should do a BIP for all P2P changes, so here it is... feedback requested. https://en.bitcoin.it/wiki/BIP_0035 I like the idea of being able to query the memory pool of a node; the implementation is

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

2012-09-13 Thread Pieter Wuille
On Thu, Sep 13, 2012 at 06:49:49PM +0100, Matthew Mitchell wrote: A merkle tree root is found by hashing the two children together and those children are found the same way until you get to the greatest level down the tree. This means you can validate children as being correct as long as they

[Bitcoin-development] Public key and signature malleability

2012-10-20 Thread Pieter Wuille
Hello all, as some may be aware, OpenSSL accepts several encodings for the same public key or the same signature. It even accepts encodings that fail to conform to the SEC and DER specification by which they are defined. As it perfectly capable of parsing every standard-compliant encoding, this

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

2012-10-24 Thread Pieter Wuille
On Wed, Oct 24, 2012 at 06:35:08PM +0200, Mike Hearn wrote: * 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 matches both single and multi sig outputs

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

2012-11-06 Thread Pieter Wuille
On Fri, Oct 26, 2012 at 04:01:58PM +0200, Mike Hearn wrote: I don't feel I understand the effort required to do some kind of partial tree encoding. Having a kind of custom compression whereby branches are represented as varint indexes into a dictionary, I can feel how much work that involves

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

2012-11-07 Thread Pieter Wuille
On Tue, Nov 6, 2012 at 7:47 PM, Gavin Andresen gavinandre...@gmail.com wrote: Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to be a good time for the core dev team to meet on the #bitcoin-dev freenode IRC channel to chat. Ok, good. -- Pieter

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

2012-11-08 Thread Pieter Wuille
On Thu, Nov 08, 2012 at 10:19:05AM +0100, Mike Hearn wrote: Comments: BIP process: are we happy with how it is working? What can we do to improve it? Needing some kind of process to allocate a number is over the top. I skipped this for the bloom filtering BIP. We should take off the

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

2012-11-27 Thread Pieter Wuille
On Wed, Nov 21, 2012 at 01:38:37PM -0500, Matt Corallo wrote: On Wed, 2012-11-21 at 16:15 +0100, Pieter Wuille wrote: On Wed, Oct 24, 2012 at 05:56:07PM +0200, Mike Hearn wrote: I've written a draft BIP describing the bloom filtering protocol extension developed by myself and Matt

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

2012-12-03 Thread Pieter Wuille
On Mon, Dec 3, 2012 at 12:19 PM, Michael Gronager grona...@ceptacle.comwrote: (Also posted on the forum: https://bitcointalk.org/index.php?topic=128900.0) The amount of dust in the block chain is getting large and it is growing all the time. Currently 11% of unspent tx outputs (UTXO) are of

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

2012-12-03 Thread Pieter Wuille
On Mon, Dec 3, 2012 at 1:24 PM, Michael Gronager grona...@ceptacle.comwrote: If this were a proposal at the time Bitcoin was created, I would definitely be in favor, but I feel we can't just change such a policy right now - it's not what people signed up for when they started using the

Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers

2012-12-03 Thread Pieter Wuille
On Mon, Dec 3, 2012 at 2:49 PM, Amir Taaki zgen...@yahoo.com wrote: Can this be amended? I think it makes much more sense to allow people to input labels not numbers at this level. General category names for different accounts is much more human than numbers, and you can still use

Re: [Bitcoin-development] Testnet DNS seed

2013-01-27 Thread Pieter Wuille
On Sun, Jan 27, 2013 at 05:27:52AM -0500, Peter Todd wrote: seed.txt? You mean the dumpfile produced by bitcoin-seeder? That has uptime info, although only a months worth if I understand it correctly. It has information about all non-banned IPs that were ever connected to succesfully. The

Re: [Bitcoin-development] 0.8.0rc1 status

2013-02-08 Thread Pieter Wuille
On 9 Feb 2013 00:50, Gavin Andresen gavinandre...@gmail.com wrote: Then before final release (or rc2, if that is needed) pull #2286 and create and pull a patch to fix the windows non-determinism problem. #2243 should fix that, I think. -- Pieter

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

2013-03-11 Thread Pieter Wuille
Hello everyone, Í've just seen many reports of 0.7 nodes getting stuck around block 225430, due to running out of lock entries in the BDB database. 0.8 nodes do not seem to have a problem. In any case, if you do not have this block: 2013-03-12 00:00:10 SetBestChain: new

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

2013-03-11 Thread Pieter Wuille
. -- Pieter On Tue, Mar 12, 2013 at 1:18 AM, Pieter Wuille pieter.wui...@gmail.comwrote: Hello everyone, Í've just seen many reports of 0.7 nodes getting stuck around block 225430, due to running out of lock entries in the BDB database. 0.8 nodes do not seem to have a problem. In any case

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

2013-03-12 Thread Pieter Wuille
On Tue, Mar 12, 2013 at 11:13:09AM +0100, Michael Gronager wrote: Yes, 0.7 (yes 0.7!) was not sufficiently tested it had an undocumented and unknown criteria for block rejection, hence the upgrade went wrong. We're using 0.7 as a short moniker for all clients, but this was a limitation that

Re: [Bitcoin-development] Blocksize and off-chain transactions

2013-03-13 Thread Pieter Wuille
On Wed, Mar 13, 2013 at 07:01:02PM +0100, Michael Gronager wrote: Please note that it was not 0.8 that had issues, but 0.7(and downwards). I really think changing features in 0.8 aiming for a fluffy limit to avoid lock object errors on 0.7 is the wrong way to go, and it will never cover for

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Pieter Wuille
On Wed, Mar 13, 2013 at 11:27:13AM -0700, Mark Friedenbach wrote: I know there's people here who will jump in saying that the bitcoin protocol is the behavior of the Satoshi client, period. But which Satoshi client? 0.7 or 0.8? The protocol is whatever the network enforces - and that is some

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

2013-04-07 Thread Pieter Wuille
(cross-post from bitcointalk.org) Hello all, as some may know, Bitcoin uses DER-encoded signatures in its transactions. However, OpenSSL (which is used to verify them) accepts more than just the strict DER specification (it allows negative numbers, extra zero padding, extra bytes at the end, and

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

2013-04-07 Thread Pieter Wuille
On Sun, Apr 07, 2013 at 06:01:13PM +0200, Mike Hearn wrote: It'd help to know how the signatures are invalid. The majority (~90%) is negative R or S values (which are just interpreted as unsigned by OpenSSL, but if the top byte has its highest bit set, it must be preceeded by a 0x00 accordinging

[Bitcoin-development] Service bits for pruned nodes

2013-04-28 Thread Pieter Wuille
Hello all, I think it is time to move forward with pruning nodes, i.e. nodes that fully validate and relay blocks and transactions, but which do not keep (all) historic blocks around, and thus cannot be queried for these. The biggest roadblock is making sure new and old nodes that start up are

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

2013-04-28 Thread Pieter Wuille
On Sun, Apr 28, 2013 at 6:29 PM, 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 restrictive - presumably node operators are constrained by physical disk space,

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

2013-05-03 Thread Pieter Wuille
(generic comment on the discussion that spawned off: ideas about how to allow additional protocols for block exchange are certainly interesting, and in the long term we should certainly consider that. For now I'd like to keep this about the more immediate way forward with making the P2P protocol

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

2013-05-06 Thread Pieter Wuille
On Mon, May 06, 2013 at 10:19:35AM +0200, Mike Hearn wrote: You are welcome to optimise P2P addr broadcasts or develop better bootstrap mechanisms. I think John's actually has a point here. If we're judging the quality of a protocol change by how compatible it is with DNS seeding, then we're

Re: [Bitcoin-development] minor bitcoin-qt gripes moving BTC off specific key

2013-05-07 Thread Pieter Wuille
On Tue, May 07, 2013 at 02:16:41PM +0200, Adam Back wrote: Hi Three minor security/other issues: 1. please a way to unlock the wallet without displaying wallet password in console screen (console unlock wallet, to import priv key); or I think the general solution here is providing a

Re: [Bitcoin-development] 32 vs 64-bit timestamp fields

2013-05-08 Thread Pieter Wuille
On Wed, May 08, 2013 at 09:08:34PM -0400, Jeff Garzik wrote: On Wed, May 8, 2013 at 9:00 PM, John Dillon john.dillon...@googlemail.com wrote: Perhaps Satoshi did this delibrately, knowing that at some point a hard-fork would be a good idea, so that we all would have a good excuse to do one?

Re: [Bitcoin-development] 32 vs 64-bit timestamp fields

2013-05-09 Thread Pieter Wuille
On Wed, May 08, 2013 at 10:42:44PM -0400, Peter Todd wrote: Ah, shoot, I just realized we both got missed Pieter's point entirely: he means to change the meaning of the header timestamp to be relative time passed since the last block... No, though that's also a possibility, but a

Re: [Bitcoin-development] 0.8.2rc1 - testnet datadir behavior changed

2013-05-12 Thread Pieter Wuille
On Sun, May 12, 2013 at 8:35 AM, Jay F j...@outlook.com wrote: On 5/10/2013 8:39 AM, Gavin Andresen wrote: Bitcoin-Qt version 0.8.2 release candidate 1 is now available from: http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.8.2/test/ Testnet glitch, something broke... I

Re: [Bitcoin-development] Double Spend Notification

2013-05-20 Thread Pieter Wuille
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 larger fee, it will be considered to be the valid one, and the first one

Re: [Bitcoin-development] BIP0032

2013-05-27 Thread Pieter Wuille
On Mon, May 27, 2013 at 03:10:04PM +0200, Michael Gronager wrote: Commenting on my own mail... Rereading the BIP, it occurs to me that the private derivation is actually intentional. So: (m/i/j/k)*G = (M/i/j/k), but (m/i'/j/k)*G (M/i/j/k) (M/i'/j/k = ERROR) But: ((m/i')*G)/j/k =

Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

2013-06-10 Thread Pieter Wuille
On Mon, Jun 10, 2013 at 10:14 AM, Melvin Carvalho melvincarva...@gmail.com wrote: However, Bitcoin's fundamental philosophy was one CPU one vote. This is perhaps the largest misconception that keeps being repeated. Bitcoin is not a democracy; it is a zero-trust system. The rules are set in

Re: [Bitcoin-development] Bitcoin addresses -- opaque or not

2013-06-11 Thread Pieter Wuille
On Tue, Jun 11, 2013 at 3:11 PM, Melvin Carvalho melvincarva...@gmail.com wrote: There was some confusion on IRC as to whether bitcoin addresses are opaque or not. https://en.bitcoin.it/wiki/Address For the sake of argument let's say that opaque means that you can tell nothing about the

Re: [Bitcoin-development] Optional wallet-linkable address format - Payment Protocol

2013-06-19 Thread Pieter Wuille
On Mon, Jun 17, 2013 at 11:48:22PM -0400, Alan Reiner wrote: _*Goal*_: An alternative address format made possible by BIP 32, which allows one to specify a Wallet ID and One-time payment code, instead of the standard one-use Base58-Hash160 addresses. This allows parties with a persistent

Re: [Bitcoin-development] Missing fRelayTxes in version

2013-06-20 Thread Pieter Wuille
On Thu, Jun 20, 2013 at 09:36:40AM +0200, Mike Hearn wrote: Sure but why not do that when there's an actual new field to add? Does anyone have a proposal for a feature that needs a new version field at the moment? There's no point changing the protocol now unless there's actually a new field

Re: [Bitcoin-development] Missing fRelayTxes in version

2013-06-20 Thread Pieter Wuille
m...@plan99.net *To:* Pieter Wuille pieter.wui...@gmail.com *Cc:* Bitcoin Dev bitcoin-development@lists.sourceforge.net; Tamas Blummer ta...@bitsofproof.com *Sent:* Thursday, June 20, 2013 11:17 AM *Subject:* Re: [Bitcoin-development] Missing fRelayTxes in version There's no problem

Re: [Bitcoin-development] Bitcoin-Qt/bitcoind version 0.8.3 released

2013-06-25 Thread Pieter Wuille
On Wed, Jun 26, 2013 at 01:13:25AM +0200, Jesus Cea wrote: splash banner shows 0.8.3-BETA. Just like every release ever, and probably until we reach 1.0. -- Pieter -- This SF.net email is sponsored by Windows: Build

Re: [Bitcoin-development] Reward for P2SH IsStandard() patch.

2013-07-14 Thread Pieter Wuille
On Sun, Jul 14, 2013 at 07:05:26PM +, John Dillon wrote: Long-term we should be using P2SH with an inner OP_CHECKSIG for most addresses as it's a 1 byte savings. Change addresses can have this done first, although bitcoinj support will help so that satoshidice and similar sites can pay to

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-14 Thread Pieter Wuille
On Sun, Jul 14, 2013 at 07:33:06PM +, Luke-Jr wrote: The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously or through negligence. If the coin isn't worth much, either

Re: [Bitcoin-development] Introducing BitcoinKit.framework

2013-07-21 Thread Pieter Wuille
On Tue, Jul 16, 2013 at 12:59:56PM +0200, Mike Hearn wrote: I think that's a great approach. Here is the patch Satoshi sent me back in 2010. All the code has changed since but it can be a source of inspiration. From Satoshi: *The simplified payment verification in the paper imagined you

[Bitcoin-development] [RFC] Standard for private keys with birth timestamp

2013-07-22 Thread Pieter Wuille
Hello, I should have brought up this suggestion before, as there seems to be relevant other work. I'd like to propose encoding keys data (whatever type) with a birth timestamp as: * serialized key@unix timestamp in decimal The reason for not incorporating this inside the key serialization

Re: [Bitcoin-development] HTTP REST API for bitcoind

2013-07-23 Thread Pieter Wuille
On Tue, Jul 23, 2013 at 10:30:13AM +0100, Andy Parkins wrote: One additional URL makes this pretty much perfect: GET /rest/block-with-tx/TX-HASH Construction of the transaction-hash-to-block database is something the full client's have to do anyway, so this query is no harder than the

Re: [Bitcoin-development] HTTP REST API for bitcoind

2013-07-23 Thread Pieter Wuille
On Tue, Jul 23, 2013 at 11:52 AM, Andy Parkins andypark...@gmail.com wrote: There is actually no such index being maintained by default, and doing so is an unnecessary burden IMHO (you need to enable -txindex since 0.8 to get this). Of course, if enabled, it can be exposed. Wow. I'm

Re: [Bitcoin-development] HTTP REST API for bitcoind

2013-07-23 Thread Pieter Wuille
On Tue, Jul 23, 2013 at 12:00 PM, Andy Parkins andypark...@gmail.com wrote: The REST API has nothing to do with SPV clients; it's similar to the RPC interface and won't be exposed to the network as a whole. Yes; I know that. I'm saying that it would make it easier for SPV (and other

Re: [Bitcoin-development] HTTP REST API for bitcoind

2013-07-23 Thread Pieter Wuille
On Tue, Jul 23, 2013 at 12:17 PM, Andreas Schildbach andr...@schildbach.de wrote: Sweeping paper wallets is a common feature request. People switch to centralized services just for getting that. That means they value convenience more than the trust-freeness of a decentralized solution. The only

Re: [Bitcoin-development] HTTP REST API for bitcoind

2013-07-23 Thread Pieter Wuille
On Tue, Jul 23, 2013 at 12:29 PM, Andreas Schildbach andr...@schildbach.de wrote: Yes, I understand that. For this reason, I would vote for adding the usual HTTP authentication/SSL stuff to the REST API. That way, SPV users can decide to run their own instance of the API (providing the needed

Re: [Bitcoin-development] Linux packaging letter

2013-07-23 Thread Pieter Wuille
On Tue, Jul 23, 2013 at 10:01:55PM +0200, Mike Hearn wrote: The trigger for this is the discovery that Debian bitcoind's got split out of the consensus some time in April, for reasons that nobody yet figured out but is presumably related to a patch (eg it uses system leveldb). Just to make

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

2013-08-07 Thread Pieter Wuille
I see payment URIs rather as a replacement for bitcoin: URI rather than an extension. It solves everything they did in a much cleaner way, Given that bitcoin: have gotten some traction, we probably want to reuse the moniker, but replace the rest entirely. In other words, if a request is specified,

Re: [Bitcoin-development] Version 0.9 goals

2013-08-15 Thread Pieter Wuille
On Thu, Aug 15, 2013 at 10:09:48AM +0200, Mike Hearn wrote: Sounds awesome! Pieter told me at lunch that headers first cut sync time to 45 minutes for him, which is another amazing improvement from the master of optimisations. Just to make sure nobody expects a magic bullet: this was on a

Re: [Bitcoin-development] Version 0.9 goals

2013-08-15 Thread Pieter Wuille
On Thu, Aug 15, 2013 at 12:49 PM, Wladimir laa...@gmail.com wrote: Fully agreed about payment protocol, autotools and Qt5 build. I'm still not very excited about coin control (and last time I looked at the code, it has an issue that it introduced statefulness into the wallet model - a bane

Re: [Bitcoin-development] Combining bloom filters?

2013-08-17 Thread Pieter Wuille
If both constructed bloom filters use the same seed and the same number of hash functions, yes. Assuming the input filters were optimal for a given FP rate, the resulting filter will be worse. -- Pieter On 17 Aug 2013 16:01, Jeff Garzik jgar...@bitpay.com wrote: Consider wallet A builds bloom

Re: [Bitcoin-development] Proposal: remove getwork RPC from bitcoind

2013-08-19 Thread Pieter Wuille
On Mon, Aug 19, 2013 at 10:09 PM, Frank F frank...@gmail.com wrote: I strongly object to removing the only mechanism that allows anyone to say that bitcoin is p2p, in the truest sense of the word. Moves like this that favor only the pool operators and private mining interests are signs that

Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys

2013-10-24 Thread Pieter Wuille
This is probably too late in the discussion, and I certainly don't want to derail any standard being formed. But if it is controversial, I want to offer my own suggestion. This is a proposal I wrote a year ago, but never spent enough work to push it as a standard:

Re: [Bitcoin-development] Proposal to replace BIP0039

2013-10-26 Thread Pieter Wuille
Let's first try to agree on what we are solving. It seems that Thomas wants - in addition to the cryptographic data - to encode the tree structure, or at least version information about what features are used in it, inside the seed. I'm not sure whether we're ready to standardize on something

Re: [Bitcoin-development] Auto-generated miner backbone

2013-11-04 Thread Pieter Wuille
On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd p...@petertodd.org wrote: The correct, and rational, approach for a miner is to always mine to extend the block that the majority of hashing power is trying to extend. The current relay rules don't give you that information at all, but they can if we

Re: [Bitcoin-development] On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big)

2013-11-07 Thread Pieter Wuille
Correcting myself: On Thu, Nov 7, 2013 at 4:00 PM, Pieter Wuille pieter.wui...@gmail.com wrote: I believe that C. Decker's paper used measurements for propagation delays for blocks 18-19, which happened between may and juli 2012. The latest bitcoind/bitcoin-qt release at the time

Re: [Bitcoin-development] Fees UI warning

2013-12-16 Thread Pieter Wuille
On Mon, Dec 16, 2013 at 11:46 AM, Jim jim...@fastmail.co.uk wrote: For the HD version of MultiBit we are removing the import of individual private keys entirely and only supporting HD addresses, primarily for safety reasons. Will that also mean no longer reusing (change) addresses? -- Pieter

[Bitcoin-development] BIP 32 proposed changes

2014-01-26 Thread Pieter Wuille
Hello all, based on some feedback, I've created a pull request with a rewritten version of BIP 32, hopefully making it more readable: * Don't reuse the terminology 'public' vs 'private' for the alternate derivation scheme which doesn't allow computing child public keys from parent public keys,

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-27 Thread Pieter Wuille
On Mon, Jan 27, 2014 at 11:03 PM, Kevin Greene kgree...@gmail.com wrote: +1 for an error field. Agree, I think we need a way for client applications to interpret the response. Should the wallet broadcast the transaction to the bitcoin network when it receives an ACK, or always assume that the

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-28 Thread Pieter Wuille
On Tue, Jan 28, 2014 at 1:53 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote: Yeah, that's the interpretation I think we should go with for now. There was a reason why this isn't specified and I forgot what it was - some

Re: [Bitcoin-development] BIP70 message delivery reliability

2014-01-30 Thread Pieter Wuille
On Thu, Jan 30, 2014 at 12:15 PM, Chuck chuck+bitcoin...@borboggle.com wrote: Hi Mike. Thanks for replying. On 1/30/2014 5:49 PM, Mike Hearn wrote: Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is, so any changes from this point on have to be backwards compatible.

Re: [Bitcoin-development] BIP70 message delivery reliability

2014-01-30 Thread Pieter Wuille
On Thu, Jan 30, 2014 at 12:59 PM, Mike Hearn m...@plan99.net wrote: With the way it works in bitcoinj, the tx is only committed to the wallet if the server accepts the Payment message and ACKs it. So the tx would not be retried if there's a failure submitting or some kind of internal server

Re: [Bitcoin-development] BIP70: PaymentACK semantics

2014-01-30 Thread Pieter Wuille
On Thu, Jan 30, 2014 at 4:06 PM, Gavin Andresen gavinandre...@gmail.com wrote: On Thu, Jan 30, 2014 at 9:51 AM, Jeff Garzik jgar...@bitpay.com wrote: Is this truly the intent? That the merchant/processor takes full responsibility for getting the TX confirmed? The intent is to give the

  1   2   3   >