Re: [Bitcoin-development] Hard fork via miner vote

2015-06-20 Thread Pieter Wuille
On Sat, Jun 20, 2015 at 7:26 PM, David Vorick david.vor...@gmail.com wrote: I see it as unreasonable to expect all nodes to upgrade during a hardfork. If you are intentionally waiting for that to happen, it's possible for an extreme minority of nodes to hold the rest of the network hostage by

Re: [Bitcoin-development] BIP for Proof of Payment

2015-06-16 Thread Pieter Wuille
held particular private keys in the past. On Jun 16, 2015 9:41 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote: 2015-06-16 21:25 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com: You can't avoid sharing the token, and you can't avoid sharing the private keys used for signing either

Re: [Bitcoin-development] BIP for Proof of Payment

2015-06-15 Thread Pieter Wuille
a transaction to prove. So, yes, it's just a proof of access to certain coins that you no longer have. Maybe I don't understand you correctly? /Kalle 2015-06-15 11:27 GMT+02:00 Pieter Wuille pieter.wui...@gmail.com: Now that you have removed the outputs, I don't think it's even a intent

Re: [Bitcoin-development] Miners: You'll (very likely) need to upgrade your Bitcoin Core node soon to support BIP66

2015-06-13 Thread Pieter Wuille
On Fri, Jun 12, 2015 at 10:37 AM, Tier Nolan tier.no...@gmail.com wrote: Once the 75% threshold is reached, miners who haven't updated are at risk of mining on invalid blocks. Note that we've been above the 75% threshold since june 7th (before Peter's main was sent). -- Pieter

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

2015-06-13 Thread Pieter Wuille
On Wed, May 20, 2015 at 4:55 AM, Andrew onelinepr...@gmail.com wrote: Hi I briefly mentioned something about this on the bitcoin-dev IRC room. In general, it seems experts (like sipa i.e. Pieter) are against using sidechains as a way of scaling. As I only have a high level understanding of

[Bitcoin-development] Mining centralization pressure from non-uniform propagation speed

2015-06-12 Thread Pieter Wuille
Hello all, I've created a simulator for Bitcoin mining which goes a bit further than the one Gavin used for his blog post a while ago. The main difference is support for links with different latency and bandwidth, because of the clustered configuration described below. In addition, it supports

Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed

2015-06-12 Thread Pieter Wuille
If there is a benefit in producing larger more-fee blocks if they propagate slowly, then there is also a benefit in including high-fee transactions that are unlikely to propagate quickly through optimized relay protocols (for example: very recent transactions, or out-of-band receoved ones). This

Re: [Bitcoin-development] Mining centralization pressure from non-uniform propagation speed

2015-06-12 Thread Pieter Wuille
I'm merely proving the existence of the effect. On Jun 12, 2015 8:24 PM, Mike Hearn m...@plan99.net wrote: are only connected to each other through a slow 2 Mbit/s link. That's very slow indeed. For comparison, plain old 3G connections routinely cruise around 7-8 Mbit/sec. So this

Re: [Bitcoin-development] BIP for Proof of Payment

2015-06-06 Thread Pieter Wuille
On Sat, Jun 6, 2015 at 5:05 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote: What do you gain by making PoPs actually valid transactions? You could for example change the signature hashing algorithm (prepend a constant string, or add a second hashing step) for signing, rendering the

Re: [Bitcoin-development] BIP for Proof of Payment

2015-06-06 Thread Pieter Wuille
What do you gain by making PoPs actually valid transactions? You could for example change the signature hashing algorithm (prepend a constant string, or add a second hashing step) for signing, rendering the signatures in a PoP unusable for actual transaction, while still committing to the same

Re: [Bitcoin-development] BIP for Proof of Payment

2015-06-06 Thread Pieter Wuille
On Sat, Jun 6, 2015 at 5:18 PM, Luke Dashjr l...@dashjr.org wrote: I also agree with Pieter, that this should *not* be so cleanly compatible with Bitcoin transactions. If you wish to share code, perhaps using an invalid opcode rather than OP_RETURN would be appropriate. Using an invalid

Re: [Bitcoin-development] Version bits proposal

2015-06-03 Thread Pieter Wuille
Thanks for all the comments. I plan to address the feedback and work on an implementation next week. On Tue, May 26, 2015 at 6:48 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Hello everyone, here is a proposal for how to coordinate future soft-forking consensus changes: https

Re: [Bitcoin-development] Proposed alternatives to the 20MB step function

2015-05-28 Thread Pieter Wuille
until we have size-independent new block propagation I don't really believe that is possible. I'll argue why below. To be clear, this is not an argument against increasing the block size, only against using the assumption of size-independent propagation. There are several significant

Re: [Bitcoin-development] Proposed alternatives to the 20MB stepfunction

2015-05-28 Thread Pieter Wuille
On May 28, 2015 10:42 AM, Raystonn . rayst...@hotmail.com wrote: I agree that developers should avoid imposing economic policy. It is dangerous for Bitcoin and the core developers themselves to become such a central point of attack for those wishing to disrupt Bitcoin. I could not agree more

[Bitcoin-development] Version bits proposal

2015-05-26 Thread Pieter Wuille
Hello everyone, here is a proposal for how to coordinate future soft-forking consensus changes: https://gist.github.com/sipa/bf69659f43e763540550 It supports multiple parallel changes, as well as changes that get permanently rejected without obstructing the rollout of others. Feel free to

Re: [Bitcoin-development] First-Seen-Safe Replace-by-Fee

2015-05-26 Thread Pieter Wuille
It's just a mempool policy rule. Allowing the contents of blocks to change (other than by mining a competing chain) would be pretty much the largest possible change to Bitcoin's design --

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

2015-05-13 Thread Pieter Wuille
On Wed, May 13, 2015 at 1:27 PM, Tier Nolan tier.no...@gmail.com wrote: After more thought, I think I came up with a clearer description of the recursive version. The simple definition is that the hash for the new signature opcode should simply assume that the normalized txid system was used

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

2015-05-13 Thread Pieter Wuille
On Wed, May 13, 2015 at 11:04 AM, Christian Decker decker.christ...@gmail.com wrote: If the inputs to my transaction have been long confirmed I can be reasonably safe in assuming that the transaction hash does not change anymore. It's true that I have to be careful not to build on top of

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

2015-05-13 Thread Pieter Wuille
On Wed, May 13, 2015 at 12:14 PM, Christian Decker decker.christ...@gmail.com wrote: On Wed, May 13, 2015 at 8:40 PM Pieter Wuille pieter.wui...@gmail.com wrote: On Wed, May 13, 2015 at 11:04 AM, Christian Decker decker.christ...@gmail.com wrote: If the inputs to my transaction have

Re: [Bitcoin-development] Long-term mining incentives

2015-05-13 Thread Pieter Wuille
On Wed, May 13, 2015 at 5:48 PM, Aaron Voisine vois...@gmail.com wrote: We have $3billion plus of value in this system to defend. The safe, conservative course is to increase the block size. Miners already have an incentive to find ways to encourage higher fees and we can help them with

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

2015-05-13 Thread Pieter Wuille
On Wed, May 13, 2015 at 1:32 PM, Tier Nolan tier.no...@gmail.com wrote: On Wed, May 13, 2015 at 9:31 PM, Pieter Wuille pieter.wui...@gmail.com wrote: This was what I was suggesting all along, sorry if I wasn't clear. That's great. So, basically the multi-level refund problem is solved

Re: [Bitcoin-development] Long-term mining incentives

2015-05-13 Thread Pieter Wuille
On Wed, May 13, 2015 at 6:13 PM, Aaron Voisine vois...@gmail.com wrote: Conservative is a relative term. Dropping transactions in a way that is unpredictable to the sender sounds incredibly drastic to me. I'm suggesting increasing the blocksize, drastic as it is, is the more conservative

Re: [Bitcoin-development] [BIP] Normalized Transaction IDs

2015-05-13 Thread Pieter Wuille
Normalized transaction ids are only effectively non-malleable when all inputs they refer to are also non-malleable (or you can have malleability in 2nd level dependencies), so I do not believe it makes sense to allow mixed usage of the txids at all. They do not provide the actual benefit of

Re: [Bitcoin-development] CLTV opcode allocation; long-term plans?

2015-05-12 Thread Pieter Wuille
I have no strong opinion, but a slight preference for separate opcodes. Reason: given the current progress, they'll likely be deployed independently, and maybe the end result is not something that cleanly fits the current CLTV argument structure.

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-09 Thread Pieter Wuille
Miners do not care about the age of a UTXO entry, apart for two exceptions. It is also economically irrelevant. * There is a free transaction policy, which sets a small portion of block space aside for transactions which do not pay sufficient fee. This is mostly an altruistic way of encouraging

Re: [Bitcoin-development] A suggestion for reducing the size of the UTXO database

2015-05-09 Thread Pieter Wuille
It's a very complex trade-off, which is hard to optimize for all use cases. Using more UTXOs requires larger transactions, and thus more fees in general. In addition, it results in more linkage between coins/addresses used, so lower privacy. The only way you can guarantee an economical reason to

Re: [Bitcoin-development] Removing transaction data from blocks

2015-05-08 Thread Pieter Wuille
So, there are several ideas about how to reduce the size of blocks being sent on the network: * Matt Corallo's relay network, which internally works by remembering the last 5000 (i believe?) transactions sent by the peer, and allowing the peer to backreference those rather than retransmit them

Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Pieter Wuille
On May 7, 2015 3:08 PM, Roy Badami r...@gnomon.org.uk wrote: On Thu, May 07, 2015 at 11:49:28PM +0200, Pieter Wuille wrote: I would not modify my node if the change introduced a perpetual 100 BTC subsidy per block, even if 99% of miners went along with it. Surely, in that scenario Bitcoin

Re: [Bitcoin-development] Mechanics of a hard fork

2015-05-07 Thread Pieter Wuille
I would not modify my node if the change introduced a perpetual 100 BTC subsidy per block, even if 99% of miners went along with it. A hardfork is safe when 100% of (economically relevant) users upgrade. If miners don't upgrade at that point, they just lose money. This is why a

Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Pieter Wuille
On Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me wrote: Recently there has been a flurry of posts by Gavin at http://gavinandresen.svbtle.com/ which advocate strongly for increasing the maximum block size. However, there hasnt been any discussion on this mailing list in

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

2015-04-17 Thread Pieter Wuille
Anyone can alter the txid - more details needed. The number of altered txids in practice is not so high in order to make us believe anyone can do it easily. It is obvious that all current bitcoin transactions are malleable, but not by anyone and not that easy. At least I like to think so.

Re: [Bitcoin-development] 75%/95% threshold for transaction versions

2015-04-15 Thread Pieter Wuille
On Apr 16, 2015 1:46 AM, s7r s...@sky-ip.org wrote: but for transaction versions? In simple terms, if 75% from all the transactions in the latest 1000 blocks are version 'n', mark all previous transaction versions as non-standard and if 95% from all the transactions in the latest 1000 blocks

[Bitcoin-development] Deprecating Bitcoin Core's regtest-specific `setgenerate` behaviour

2015-04-12 Thread Pieter Wuille
Hello everyone, Bitcoin Core's `setgenerate` RPC call has had a special meaning for -regtest (namely instantaneously mining a number of blocks, instead of starting a background CPU miner). We're planning to deprecate that overloaded behaviour, and replace it with a separate RPC call `generate`.

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-02-06 Thread Pieter Wuille
On Mon, Jan 26, 2015 at 10:35 AM, Gregory Maxwell gmaxw...@gmail.com wrote: I'd like to request a BIP number for this. Sure. BIP0066. Four implementations exist now: * for master: https://github.com/bitcoin/bitcoin/pull/5713 (merged) * for 0.10.0: https://github.com/bitcoin/bitcoin/pull/5714

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-02-03 Thread Pieter Wuille
On Tue, Feb 3, 2015 at 4:00 AM, Wladimir laa...@gmail.com wrote: One way to do that is to just - right now - add a patch to 0.10 to make those non-standard. This requires another validation flag, with a bunch of switching logic. The much simpler alternative is just adding this to BIP66's

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-02-03 Thread Pieter Wuille
On Tue, Feb 3, 2015 at 10:15 AM, Pieter Wuille pieter.wui...@gmail.com wrote: The much simpler alternative is just adding this to BIP66's DERSIG right now, which is a one-line change that's obviously softforking. Is anyone opposed to doing so at this stage? I'm retracting this proposed change

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-02-02 Thread Pieter Wuille
On Sun, Jan 25, 2015 at 6:48 AM, Gregory Maxwell gmaxw...@gmail.com wrote: So I think we should just go ahead with R/S length upper bounds as both IsStandard and in STRICTDER. I would like to fix this at some point in any case. If we want to do that, we must at least have signatures with

Re: [Bitcoin-development] var_int ambiguous serialization consequences

2015-02-01 Thread Pieter Wuille
Hashes are always computed by reserializing data structures, never by hashing wire data directly. This has been the case in every version of the reference client's code that I know of. This even meant that for example a block of 99 bytes with non-shortest length for the transaction count

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-01-25 Thread Pieter Wuille
On Thu, Jan 22, 2015 at 6:41 PM, Zooko Wilcox-OHearn zo...@leastauthority.com wrote: * Should the bipstrictder give a rationale or link to why accept the 0-length sig as correctly-encoded-but-invalid? I guess the rationale is an efficiency issue as described in the log entry for

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-01-25 Thread Pieter Wuille
On Tue, Jan 20, 2015 at 8:35 PM, Pieter Wuille pieter.wui...@gmail.com wrote: I therefore propose a softfork to make non-DER signatures illegal (they've been non-standard since v0.8.0). A draft BIP text can be found on: https://gist.github.com/sipa/5d12c343746dad376c80 I'd like

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-01-25 Thread Pieter Wuille
On Wed, Jan 21, 2015 at 8:32 PM, Rusty Russell ru...@rustcorp.com.au wrote: One weirdness is the restriction on maximum total length, rather than a 32 byte (33 with 0-prepad) limit on signatures themselves. Glad that you point this out; I believe that's a weakness with more impact now that this

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-01-21 Thread Pieter Wuille
On Tue, Jan 20, 2015 at 11:45 PM, Rusty Russell ru...@rustcorp.com.au wrote: // Null bytes at the start of R are not allowed, unless it would otherwise be // interpreted as a negative number. if (lenS 1 (sig[lenR + 6] == 0x00) !(sig[lenR + 7] 0x80)) return false; You mean null

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-01-21 Thread Pieter Wuille
On Wed, Jan 21, 2015 at 3:37 PM, Gavin Andresen gavinandre...@gmail.com wrote: DERSIG BIP looks great to me, just a few nit-picky changes suggested: You mention the DER standard : should link to http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf (or whatever is best reference

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-01-21 Thread Pieter Wuille
On Wed, Jan 21, 2015 at 2:29 PM, Douglas Roark d...@bitcoinarmory.com wrote: Nice paper, Pieter. I do have a bit of feedback. Thanks for the comments. I hope I have clarified the text a bit accordingly. 1)The first sentence of Deployment has a typo. We reuse the double-threshold switchover

Re: [Bitcoin-development] [softfork proposal] Strict DER signatures

2015-01-21 Thread Pieter Wuille
On Wed, Jan 21, 2015 at 11:18 PM, Matt Whitlock b...@mattwhitlock.name wrote: To be more in the C++ spirit, I would suggest changing the (const std::vectorunsigned char sig, size_t off) parameters to (std::vectorunsigned char::const_iterator itr, std::vectorunsigned char::const_iterator

[Bitcoin-development] [softfork proposal] Strict DER signatures

2015-01-20 Thread Pieter Wuille
Hello everyone, We've been aware of the risk of depending on OpenSSL for consensus rules for a while, and were trying to get rid of this as part of BIP 62 (malleability protection), which was however postponed due to unforeseen complexities. The recent evens (see the thread titled OpenSSL 1.0.0p

Re: [Bitcoin-development] Recent EvalScript() changes mean CHECKLOCKTIMEVERIFY can't be merged

2014-12-15 Thread Pieter Wuille
On Mon, Dec 15, 2014 at 1:47 PM, Peter Todd p...@petertodd.org wrote: BtcDrak was working on rebasing my CHECKLOCKTIMEVERIFY¹ patch to master a few days ago and found a fairly large design change that makes merging it currently impossible. Pull-req #4890², specifically commit c7829ea7,

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Pieter Wuille
On Mon, Nov 17, 2014 at 4:19 AM, Alan Reiner etothe...@gmail.com wrote: On 11/16/2014 02:04 PM, Jorge Timón wrote: I remember people asking in #bitcoin-dev Does anyone know any use case for greater sizes OP_RETURNs? and me answering I do not know of any use cases that require bigger sizes.

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Pieter Wuille
On Mon, Nov 17, 2014 at 12:43 PM, Flavien Charlon flavien.char...@coinprism.com wrote: My main concern with OP_RETURN is that it seems to encourage people to use the blockchain as a convenient transport channel The number one user of the blockchain as a storage and transport mechanism is

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

2014-11-17 Thread Pieter Wuille
On Mon, Nov 17, 2014 at 1:31 PM, Chris Pacia ctpa...@gmail.com wrote: If users wishes to use stealth addresses with out of band communication, the benefits of HD would largely be lost and they would be back to making regular backups -- this time after every transaction rather than every 100.

Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT

2014-11-06 Thread Pieter Wuille
On Thu, Nov 6, 2014 at 2:38 AM, Peter Todd p...@petertodd.org wrote: However the implementation of the STRICTENC flag simply makes pubkey formats it doesn't recognize act as through the signature was invalid, rather than failing the transaction. Similar to the invalid due to too many sigops

Re: [Bitcoin-development] SCRIPT_VERIFY_STRICTENC and CHECKSIG NOT

2014-11-06 Thread Pieter Wuille
On Thu, Nov 6, 2014 at 2:47 AM, Pieter Wuille pieter.wui...@gmail.com wrote: I suggest we either change STRICTENC to simply fail unrecognized pubkeys immediately - similar to how non-standard signatures are treated - or fail the script if the pubkey is non-standard and signature verification

[Bitcoin-development] BIP62 and future script upgrades

2014-11-04 Thread Pieter Wuille
Hi all, one of the rules in BIP62 is the clean stack requirement, which makes passing more inputs to a script than necessary illegal. Unfortunately, this rule needs an exception for P2SH scripts: the test can only be done after (and not before) the second stage evaluation. Otherwise it would

Re: [Bitcoin-development] BIP62 and future script upgrades

2014-11-04 Thread Pieter Wuille
On Tue, Nov 4, 2014 at 5:38 AM, Mike Hearn m...@plan99.net wrote: This is another problem that only exists because of the desire to soft fork. If script 2.0 is a hard fork upgrade, you no longer need weird hacks like scripts-which-are-not-scripts. I agree. I also agree that the desire for

Re: [Bitcoin-development] BIP62 and future script upgrades

2014-11-04 Thread Pieter Wuille
On Tue, Nov 4, 2014 at 11:56 AM, Jeff Garzik jgar...@bitpay.com wrote: On Tue, Nov 4, 2014 at 8:13 PM, Peter Todd p...@petertodd.org wrote: On another topic, I'm skeptical of the choice of nVersion==3 - we'll likely end up doing more block.nVersion increases in the future, and there's no

Re: [Bitcoin-development] BIP62 and future script upgrades

2014-11-04 Thread Pieter Wuille
the optional rules only to strict v2, and not higher or lower. On Tue, Nov 4, 2014 at 12:07 PM, Peter Todd p...@petertodd.org wrote: On Tue, Nov 04, 2014 at 12:00:43PM -0800, Pieter Wuille wrote: On Tue, Nov 4, 2014 at 11:56 AM, Jeff Garzik jgar...@bitpay.com wrote: On Tue, Nov 4, 2014 at 8:13

[Bitcoin-development] Malleable booleans

2014-10-13 Thread Pieter Wuille
Hi all, while working on a BIP62 implementation I discovered yet another type of malleability: the interpretation of booleans. Any byte array with non-zero bytes in it (ignoring the highest bit of the last byte, which is the sign bit when interpreting as a number) is interpreted as true,

[Bitcoin-development] Request for review/testing: headers-first synchronization in Bitcoin Core

2014-10-11 Thread Pieter Wuille
Hi all, I believe that a large change that I've been working on for Bitcoin Core is ready for review and testing: headers-first synchronization. In short, it changes the way the best chain is discovered, downloaded and verified, with several advantages: * Parallel block downloading (much faster

Re: [Bitcoin-development] Small update to BIP 62

2014-09-13 Thread Pieter Wuille
On Fri, Sep 12, 2014 at 6:35 PM, Pieter Wuille pieter.wui...@gmail.com wrote: Changes: https://github.com/bitcoin/bips/pull/102/files Gregory, Jeff: does this address your concerns? Others: comments? I've made another change in the PR, as language about strictly only compressed

Re: [Bitcoin-development] Small update to BIP 62

2014-09-12 Thread Pieter Wuille
On Mon, Sep 8, 2014 at 1:31 AM, Pieter Wuille pieter.wui...@gmail.com wrote: I've sent out a new pull request (https://github.com/bitcoin/bips/pull/102/files) that: * Changes the order of the rules. * Adds more reference documentation about minimal pushes and number encodings. * Clarified

Re: [Bitcoin-development] Small update to BIP 62

2014-09-07 Thread Pieter Wuille
On Wed, Sep 3, 2014 at 6:34 PM, Pieter Wuille pieter.wui...@gmail.com wrote: On Mon, Sep 1, 2014 at 10:48 PM, Gregory Maxwell gmaxw...@gmail.com wrote: Not related to this change but the definition of rule 4 may not be sufficiently specific-- without a definition someone could reasonably reach

Re: [Bitcoin-development] Small update to BIP 62

2014-09-03 Thread Pieter Wuille
On Mon, Sep 1, 2014 at 10:48 PM, Gregory Maxwell gmaxw...@gmail.com wrote: Not related to this change but the definition of rule 4 may not be sufficiently specific-- without a definition someone could reasonably reach a different conclusion about OP_1NEGATE being a push operation, or might

Re: [Bitcoin-development] Reconsidering github

2014-08-23 Thread Pieter Wuille
On Sat, Aug 23, 2014 at 8:17 AM, Troy Benjegerdes ho...@hozed.org wrote: On Fri, Aug 22, 2014 at 09:20:11PM +0200, xor wrote: On Tuesday, August 19, 2014 08:02:37 AM Jeff Garzik wrote: It would be nice if the issues and git repo for Bitcoin Core were not on such a centralized service as

Re: [Bitcoin-development] Outbound connections rotation

2014-08-18 Thread Pieter Wuille
Yes, I believe peer rotation is useful, but not for privacy - just for improving the network's internal knowledge. I haven't looked at the implementation yet, but how I imagined it would be every X minutes you attempt a new outgoing connection, even if you're already at the outbound limit. Then,

Re: [Bitcoin-development] Synchronization: 19.5 % orphaned blocks at height 197'324

2014-08-10 Thread Pieter Wuille
On Sun, Aug 10, 2014 at 4:07 PM, Bob McElrath bob_bitc...@mcelrath.org wrote: I had the same problem (repeatedly) which came down a hardware problem. This is actually an independent problem (though something to be aware of). Flaky hardware can make synchronization fail completely - as it relies

Re: [Bitcoin-development] Abusive and broken bitcoin seeders

2014-07-30 Thread Pieter Wuille
At least my crawler (bitcoin-seeder:0.01) software shouldn't reconnect more frequently than once every 15 minutes. But maybe the two connections you saw were instances? On Wed, Jul 30, 2014 at 3:50 PM, Wladimir laa...@gmail.com wrote: The version message helpfully tells me my own IP address but

Re: [Bitcoin-development] Small update to BIP 62

2014-07-19 Thread Pieter Wuille
On Jul 18, 2014 4:56 PM, Wladimir laa...@gmail.com wrote: On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn m...@plan99.net wrote: The rationale doesn't seem to apply to rule #4, what's so special about that one? 4. Non-push operations in scriptSig Any non-push operation in a scriptSig

[Bitcoin-development] Small update to BIP 62

2014-07-18 Thread Pieter Wuille
Hi all, I've sent a pull request to make a small change to BIP 62 (my anti-malleability proposal) which is still a draft; see: * https://github.com/bitcoin/bips/pull/90 (the request) * https://github.com/sipa/bips/blob/bip62up/bip-0062.mediawiki (the result) It makes two of the 7 new rules

Re: [Bitcoin-development] Small update to BIP 62

2014-07-18 Thread Pieter Wuille
On Fri, Jul 18, 2014 at 5:39 PM, Mike Hearn m...@plan99.net wrote: The rationale doesn't seem to apply to rule #4, what's so special about that one? Nothing really. If it's controversial in any way, I'm fine with changing that. It's just one those things that nobody needs, nobody uses, has

Re: [Bitcoin-development] Small update to BIP 62

2014-07-18 Thread Pieter Wuille
On Fri, Jul 18, 2014 at 5:45 PM, Pieter Wuille pieter.wui...@gmail.com wrote: But perhaps we should investigate how many non-DER signatures still make it into blocks first... In the last 11 blocks (4148 transactions), apparently none. -- Pieter

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Pieter Wuille
I'd like to point out that there is quite a difference between what core nodes should be like and what the codebase core nodes are built from must support. Given sufficiently modularized code (which I think everyone seems to be in favor of, regardless of the goals), you can likely build a binary

Re: [Bitcoin-development] Bitcoin miner heads-up: getwork RPC going away

2014-06-21 Thread Pieter Wuille
On Sat, Jun 7, 2014 at 10:29 AM, Wladimir laa...@gmail.com wrote: On Sat, Jun 7, 2014 at 3:55 AM, Jeff Garzik jgar...@bitpay.com wrote: As such, it is planned to remove getwork in the next release. Most if not all pool servers have switched away from getwork years ago. To be clear, they

Re: [Bitcoin-development] Possible attack: Keeping unconfirmed transactions

2014-06-06 Thread Pieter Wuille
Whenever you do a reissuing of a transaction that didn't go through earlier, you should make sure to reuse one of the inputs for it. That guarantees that both cannot confirm simultaneously. On Sat, Jun 7, 2014 at 12:21 AM, Raúl Martínez r...@i-rme.es wrote: Alice does not intercept the

Re: [Bitcoin-development] Future Feature Proposal - getgist

2014-06-05 Thread Pieter Wuille
On Thu, Jun 5, 2014 at 7:43 PM, Richard Moore m...@ricmoo.com wrote: I was considering names like getcheckpoints() to use the terminology that already seemed to be in place, but they were too long :) I have been using getheaders() in my thick client to quickly grab all the headers before

Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again

2014-05-30 Thread Pieter Wuille
I don't think it would be too hard to add support for a option to the seeder for non-matching requests, forward to other DNS server at IP:PORT, so you could cascade them. On Fri, May 30, 2014 at 4:51 PM, Robert McKay rob...@mckay.com wrote: No, I don't think so. The problem is the 'aa' flag is

Re: [Bitcoin-development] testnet-seed.bitcoin.petertodd.org is up again

2014-05-30 Thread Pieter Wuille
On Fri, May 30, 2014 at 5:40 PM, Andreas Schildbach andr...@schildbach.de wrote: I maybe have made this suggestion in the past, but why don't we teach the seeder (or maybe even plain bitcoind) how to write a zone file and then use matured DNS servers to serve this zone? I admit I never ran my

Re: [Bitcoin-development] statoshi.info is now live

2014-05-14 Thread Pieter Wuille
On May 14, 2014 1:42 PM, Jameson Lopp jameson.l...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks; I've received several suggestions for other metrics to collect that I hope to implement soon, but you're right in that tracking per-peer pings is a different type of

Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-09 Thread Pieter Wuille
I believe stealth addresses and the payment protocol both have their use cases, and that they don't overlap. If you do not want to communicate with the receiver, you typically do not want them to know who is paying or for what (otherwise you're already talking to them in some way, right?). That's

Re: [Bitcoin-development] ECDH in the payment protocol

2014-05-09 Thread Pieter Wuille
On Fri, May 9, 2014 at 8:13 PM, Peter Todd p...@petertodd.org wrote: I don't think we're going to find that's practical unfortunately due to change. Every payment I make ties up txouts, so if we try to base the atomicity of payments on whether or not the payee decides to broadcast the

Re: [Bitcoin-development] Bug in key.cpp

2014-05-06 Thread Pieter Wuille
On Tue, May 6, 2014 at 5:12 AM, odinn.cyberguerri...@riseup.net wrote: You are right there is a bug in there. But the value is not 25% I think. Tinker some more. :-) Afaict, 3 is a perfectly valid value, meaning 25% of sig- key recoveries would fail erroneously... Values 2 and 3 are only

Re: [Bitcoin-development] BIP32 wallet structure in use? Remove it?

2014-04-26 Thread Pieter Wuille
On Sat, Apr 26, 2014 at 2:24 PM, Pavol Rusnak st...@gk2.sk wrote: On 04/26/2014 12:48 PM, Tier Nolan wrote: Maybe the solution is to have a defined way to import an unknown wallet? That is nonsense. There is no way how to import the wallet if you don't know its structure. I agree. Especially

Re: [Bitcoin-development] New BIP32 structure

2014-04-24 Thread Pieter Wuille
On Thu, Apr 24, 2014 at 8:54 AM, Thomas Voegtlin thoma...@gmx.de wrote: Why do clients need to use the features in BIP 64? If Electrum doesn't want to use accounts, [...] To clarify: Electrum plans to have bip32 accounts; Multibit will not, afaik. To clarify: BIP64 has a much stricter

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Pieter Wuille
On Wed, Apr 23, 2014 at 5:34 PM, Kevin kevinsisco61...@gmail.com wrote: I have some questions: 1. How can we work towards solving the double-spending problem? We have this awesome technology that solves the double-spending problem. It's called a blockchain. Of course, it only works when

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pieter Wuille
On Tue, Apr 8, 2014 at 5:41 PM, slush sl...@centrum.cz wrote: I've discussed the solution of Litecoin seed in BIP32 HMAC with Litecoin devs already, and after long discussion we've concluded that it is generally bad idea. When changing Bitcoin seed constant to something different, same

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pieter Wuille
That's the point. BIP64 specifies such a structure, and you have to scan all that it defines. If you want to write wallet software that does not have the complexity to deal with just one account, it is not BIP64 compliant. It could try to define its own purpose system, with a hierarchy without

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pieter Wuille
I believe Luke means scanning chains as defined by the structure, but not handing out addresses from other accounts than the first one. That's certainly a possibly way to compatibly implement BIP64, but it doesn't reduce all that much complexity. I hope people would choose that over defining

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pieter Wuille
On Wed, Apr 23, 2014 at 10:43 PM, Pavol Rusnak st...@gk2.sk wrote: On 04/23/2014 10:41 PM, Luke-Jr wrote: I don't see how. The user knows he has money in different subwallets. As long as he has a way to specify which subwallet he is accessing in single-subwallet clients, there shouldn't be a

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Pieter Wuille
On Wed, Apr 23, 2014 at 11:33 PM, Pavol Rusnak st...@gk2.sk wrote: On 04/23/2014 11:22 PM, Gregory Maxwell wrote: Hopefully it would be clarified as only a MUST NOT do so silently... I have funds split across two wallets and it WONT LET ME SPEND THEM sounds like a terrible user experience. :)

Re: [Bitcoin-development] bits: Unit of account

2014-04-20 Thread Pieter Wuille
I told him specifically to bring it here (on a pull request for Bitcoin Core), as there is no point in making such convention changes to just one client. I wasn't aware of any discussion about the bits proposal here before. On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer ta...@bitsofproof.com

Re: [Bitcoin-development] bits: Unit of account

2014-04-20 Thread Pieter Wuille
On Apr 21, 2014 3:37 AM, Un Ix slashdevn...@hotmail.com wrote: Something tells me this would be reduced to a single syllable in common usage I.e. bit. What units will be called colloquially is not something developers will determine. It will vary, depend on language and culture, and is not

Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)

2014-04-16 Thread Pieter Wuille
On Wed, Apr 16, 2014 at 5:12 PM, Kevin kevinsisco61...@gmail.com wrote: I think we should get to the bottom of this. Should we assume that xp is not secure enough? Yes. What is this warning? Windows XP is no longer maintained. Don't use such a system for protecting your money. Who is

Re: [Bitcoin-development] Warning message when running wallet in Windows XP (or drop support?)

2014-04-16 Thread Pieter Wuille
On Wed, Apr 16, 2014 at 11:39 PM, Mark Friedenbach m...@monetize.io wrote: On 04/16/2014 02:29 PM, Kevin wrote: Okay, so how about an autoupdate function which pulls a work around off the server? Sooner or later, the vulnerabilities must be faced. NO. Bitcoin Core will never have an

Re: [Bitcoin-development] Bug in 2-of-3 transaction signing in Bitcoind?

2014-04-15 Thread Pieter Wuille
The first input seems to be already spent by another transaction (which looks very similar). 0.9 should report a more detailed reason for rejection, by the way. On Tue, Apr 15, 2014 at 5:05 PM, Mike Hearn m...@plan99.net wrote: Check debug.log to find out the reason it was rejected.

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-10 Thread Pieter Wuille
There were earlier discussions. The two ideas were either using one or a few service bits to indicate availability of blocks, or to extend addr messages with some flags to indicate this information. I wonder whether we can't have a hybrid: bits to indicate general degree of availability of

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Pieter Wuille
On Thu, Apr 10, 2014 at 6:47 PM, Brian Hoffman brianchoff...@gmail.com wrote: Looks like only about ~30% disk space savings so I see your point. Is there a critical reason why blocks couldn't be formed into superblocks that are chained together and nodes could serve a specific superblock, which

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Pieter Wuille
On Thu, Apr 10, 2014 at 8:19 PM, Paul Rabahy prab...@gmail.com wrote: Please let me know if I have missed something. A 51% attack can make you believe you were paid, while you weren't. Full node security right now validates everything - there is no way you can ever be made to believe something

Re: [Bitcoin-development] Chain pruning

2014-04-10 Thread Pieter Wuille
On Thu, Apr 10, 2014 at 10:12 PM, Tier Nolan tier.no...@gmail.com wrote: On Thu, Apr 10, 2014 at 7:32 PM, Pieter Wuille pieter.wui...@gmail.com wrote: If you trust hashrate for determining which UTXO set is valid, a 51% attack becomes worse in that you can be made to believe a version

Re: [Bitcoin-development] New BIP32 structure

2014-04-08 Thread Pieter Wuille
I see the cause of our disagreement now. You actually want to share a single BIP32 tree across different currency types, but do it in a way that guarantees that they never use the same keys. I would have expected that different chains would use independent chains, and have serializations encode

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Pieter Wuille
On Mon, Apr 7, 2014 at 2:19 PM, Jameson Lopp jameson.l...@gmail.com wrote: I'm glad to see that I'm not the only one concerned about the consistent dropping of nodes. Though I think that the fundamental question should be: how many nodes do we really need? Obviously more is better, but it's

[Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-01 Thread Pieter Wuille
Hi all, I understand this is a controversial proposal, but bear with me please. I believe we cannot accept the current subsidy schedule anymore, so I wrote a small draft BIP with a proposal to turn Bitcoin into a limited-supply currency. Dogecoin has already shown how easy such changes are, so I

  1   2   3   >