Re: [Bitcoin-development] Anti DoS for tx replacement

2013-04-18 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wed, Apr 17, 2013 at 9:48 AM, Mike Hearn m...@plan99.net wrote: So it'd be nice if this ended up not being necessary. Experience indicates that rational miners typically don't pursue a short-termist profit-at-any-cost agenda - free

Re: [Bitcoin-development] Anti DoS for tx replacement

2013-04-18 Thread John Dillon
on the forums: https://bitcointalk.org/index.php?topic=179612.msg1881800#msg1881800 On Thu, Apr 18, 2013 at 8:14 AM, Peter Todd p...@petertodd.org wrote: On Thu, Apr 18, 2013 at 06:07:23AM +, John Dillon wrote: Gavin do you actually agree with Mike on this stuff like he implies? Because

Re: [Bitcoin-development] Anti DoS for tx replacement

2013-04-23 Thread John Dillon
Sorry I don't have time to reply more in depth, but I wanted to say to Jeremy (especially) and Peter I'm very impressed to see such a good design be created so fast that does not depend on replacement at all. This is a great example of how often the right approach to a problem is to accept that

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

2013-04-28 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Apr 29, 2013 at 3:36 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Sun, Apr 28, 2013 at 7:57 PM, John Dillon john.dillon...@googlemail.com wrote: Have we considered just leaving that problem to a different protocol such as BitTorrent

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

2013-05-04 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I think you too should ask yourself why you are putting so much effort into optimizing a centralized service, the DNS seeds, rather than putting effort into optimizing the P2P peer discovery instead. DNS seeds are a necessary evil, one that

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

2013-05-08 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 You mean scam you with a zero-conf transaction that hasn't actually been broadcast? Yeah. Or just scam you at all. It's hard to imagine an organisation as a big as a mobile carrier engaging in financial scamming (roaming fees excepted).

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

2013-05-08 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, May 8, 2013 at 11:44 PM, Peter Todd p...@petertodd.org wrote: Who knows? Satoshi used 32-bits and those fields can't be changed now without every single Bitcoin user changing all at once. (a hard-fork change) We'll probably need to do

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

2013-05-08 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, May 9, 2013 at 1:13 AM, Pieter Wuille pieter.wui...@gmail.com wrote: On Wed, May 08, 2013 at 09:08:34PM -0400, Jeff Garzik wrote: Guffaw :) The year 2038 is so far in the future that it is not really relevant, from that angle. Meh. I

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

2013-05-08 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, May 9, 2013 at 1:57 AM, Peter Todd p...@petertodd.org wrote: Remember that interpreting the timestamp on a block for the purposes of timestamping is a lot more subtle than it appears at first. I actually just meant how Pieter Wuille was

Re: [Bitcoin-development] merged mining hashcash bitcoin (Re: Coinbase TxOut Hashcash)

2013-05-13 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 - what about if a pool could lock the reward (rather than receive it or destroy it) eg some kind of merkle root instead of a public key hash in the reward recipient address field in the coinbase. Sorry I don't have time for a full reply due

Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

2013-06-04 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'm one of the people experimenting in this area. I've long argued that a zero-output transaction should be permitted -- 100% miner fee -- as an elegant proof of sacrifice. Unfortunately that requires a hard fork. Also, for most people, it

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

2013-06-09 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 It has been suggested that we leave the decision of what the blocksize to be entirely up to miners. However this leaves a parameter that affects every Bitcoin participant in the control of a small minority. Of course we can not force miners to

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

2013-06-09 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Jun 10, 2013 at 4:44 AM, Edmund Broadley rebr...@gmail.com wrote: I really like this idea. I also like that users with no clue will leave their vote to the default chosen by the software developers, which hopefully will be 1MB. I like how

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

2013-06-15 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Jun 10, 2013 at 5:43 PM, Peter Todd p...@petertodd.org wrote: On Mon, Jun 10, 2013 at 01:25:05PM -0400, Alan Reiner wrote: to sign votes. Not only that, but it would require them to reveal their public key, which while isn't technically

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

2013-06-28 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jun 28, 2013 at 9:05 AM, Mike Hearn m...@plan99.net wrote: I see some of the the other things that were concerning for me at the time are still uncorrected though, e.g. no proxy support (so users can't follow our recommended best

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

2013-06-28 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Thinking about this a little more, I guess it does not hurt to build some kind of voting system into the clients. But I think it's more useful for straw polls. For example a bug fix 100% of people should agree on. A protocol optimization

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

2013-06-28 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jun 28, 2013 at 10:20 AM, Mike Hearn m...@plan99.net wrote: I suspect what you saw is mining nodes restarting and clearing their mempools out rather than an explicit policy of replace by fee. Possibly, but it is a rather short window of

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

2013-06-28 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Thu, Jun 27, 2013 at 6:41 PM, Gregory Maxwell gmaxw...@gmail.com wrote: On Thu, Jun 27, 2013 at 11:04 AM, Luke-Jr l...@dashjr.org wrote: On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net

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

2013-07-14 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 As you all know keeping the size of the UTXO set small is critical, and more recently we've also had problems with distasteful data being added to the UTXO set. (http://garzikrants.blogspot.se/2013_04_01_archive.html) Gregory Maxwell has an

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

2013-07-14 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 11:18 AM, Jorge Timón jti...@monetize.io wrote: All the arguments in favor of this pegging use zerocoin's point of view. Sure it would be much better for it, but are additional costs to the bitcoin network and you cannot

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

2013-07-14 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 7:28 PM, Pieter Wuille pieter.wui...@gmail.com wrote: 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

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

2013-07-14 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 7:33 PM, Luke-Jr l...@dashjr.org wrote: Merge mining is very much mining a coin for free. Ask not what the total reward is, ask that the marginal cost of merge mining an additional coin is. But the total reward is what

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

2013-07-14 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Jul 14, 2013 at 7:42 PM, Pieter Wuille pieter.wui...@gmail.com wrote: On Sun, Jul 14, 2013 at 07:33:06PM +, Luke-Jr wrote: Invalid blocks are rejected by validating clients in all circumstances. I don't think that's what John means.

[Bitcoin-development] Protecting Bitcoin against network-wide DoS attack

2013-07-14 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 It's been pointed out recently how a fairly cheap attack on the Bitcoin network would be to take advantage of the fact that we limit the number of incoming connections, but don't require anything of those connections. This means an attacker can

Re: [Bitcoin-development] Linux packaging letter

2013-07-28 Thread John Dillon
My signature: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Linux distribution packaging and Bitcoin 2013-07-23 This note summarises the dangers inherent in the Linux distribution packaging model for Bitcoin, and forms a request from upstream

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-18 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Aug 16, 2013 at 2:15 PM, Peter Todd p...@petertodd.org wrote: On Fri, Aug 16, 2013 at 10:01:16AM -0400, Peter Todd wrote: Doing this also makes it more difficult to sybil the network - for instance right now you can create SPV honeypots

Re: [Bitcoin-development] Gavin's post-0.9 TODO list...

2013-08-18 Thread John Dillon
-BEGIN PGP MESSAGE- Version: GnuPG v1.4.11 (GNU/Linux) hQEMA8xUMVQPvvGFAQf9HL/SN/TZNQuVAjz5ggDzVzpYEzLRkFlgTR2lPURaR28F G0SgcvJmt1cvucxZRxzSUDCx58Ub16dzx9IBKQ+GDDUXbHGqExfbeIFx96okNsSm GmRRyORm+L7rdpQ3G8HcfKr1R9YufgaAjsa05eXlXl+fgpYrSBgitY6T3IZ9c0Z7

Re: [Bitcoin-development] Payment protocol for onion URLs.

2013-10-28 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Oct 26, 2013 at 3:31 AM, Gregory Maxwell gmaxw...@gmail.com wrote: One limitation of the payment protocol as speced is that there is no way for a hidden service site to make use of its full authentication capability because they are

Re: [Bitcoin-development] Making fee estimation better

2013-10-28 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Oct 26, 2013 at 12:25 AM, Gavin Andresen gavinandre...@gmail.com wrote: I feel like there is a lot of in the weeds discussion here about theoretical, what-if-this-and-that-happens-in-the-future scenarios. I would just like to point out

Re: [Bitcoin-development] Even simpler minimum fee calculation formula: f bounty*fork_rate/average_blocksize

2013-11-13 Thread John Dillon
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Last week I posted a writeup: On the optimal block size and why transaction fees are 8 times too low (or transactions 8 times too big). Peter Todd made some nice additions to it including different pool sizes into the numbers. Peter claims on