Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Peter Todd
On Fri, Jun 19, 2015 at 09:37:49PM +0800, Chun Wang wrote: Hello. We recognize the problem. We will switch to FSS RBF soon. Thanks. No worries, let me know if you have any issues. You have my phone number. While my own preference - and a number of other devs - is full-RBF, either one is a good

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Peter Todd
On Fri, Jun 19, 2015 at 09:33:03AM -0400, Gavin Andresen wrote: I just sent the following email to F2Pool: I was disappointed to see Peter Todd claiming that you have (or will?) run his replace-by-fee patch. I strongly encourage you to wait until most wallet software supports replace

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Peter Todd
On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote: It is disappointing that F2Pool would enable full RBF when the safe alternative, first-seen-safe RBF, is also available, especially since the fees they would gain by supporting full RBF over FSS RBF would likely be negligible. Did

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Peter Todd
On Fri, Jun 19, 2015 at 07:00:56AM -0700, Adrian Macneil wrote: For instance, if Coinbase had contracts with 80% of the Bitcoin hashing power to guarantee their transactions would get mined, but 20% of the hashing power didn't sign up, then the only way to guarantee their transactions

[Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Peter Todd
v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet, Peter Todd, May 23rd 2015, Bitcoin-development mailing list, http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07795.html 2) From Zero to Hero

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Peter Todd
On Fri, Jun 19, 2015 at 03:00:57PM +, justusranv...@riseup.net wrote: On 2015-06-19 10:39, Peter Todd wrote: Yesterday F2Pool, currently the largest pool with 21% of the hashing power, enabled full replace-by-fee (RBF) support after discussions with me. This means

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Peter Todd
On Fri, Jun 19, 2015 at 07:30:17AM -0700, Adrian Macneil wrote: In that case would you enter into such contracts? We take it as it comes. Currently, it's perfectly possible to accept zeroconf transactions with only a very small chance of double spend. As long as it's only possible to

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Peter Todd
On Fri, Jun 19, 2015 at 09:44:08AM -0400, Peter Todd wrote: On Fri, Jun 19, 2015 at 09:33:05AM -0400, Stephen Morse wrote: It is disappointing that F2Pool would enable full RBF when the safe alternative, first-seen-safe RBF, is also available, especially since the fees they would gain

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Peter Todd
On Fri, Jun 19, 2015 at 09:18:54AM -0700, Adrian Macneil wrote: So connecting to many nodes just because we can and it's not technically prevented is bad for the network and creating systemic risks of failure, Well it is actually; that's why myself, Wladimir van der Laan, and Gregory

Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

2015-06-19 Thread Peter Todd
On Fri, Jun 19, 2015 at 09:42:33AM -0700, Eric Lombrozo wrote: If we want a non-repudiation mechanism in the protocol, we should explicitly define one rather than relying on “prima facie” assumptions. Otherwise, I would recommend not relying on the existence of a signed transaction as proof

Re: [Bitcoin-development] questions about bitcoin-XT code fork non-consensus hard-fork

2015-06-16 Thread Peter Todd
On Tue, Jun 16, 2015 at 08:33:31PM +0800, Pindar Wong wrote: On Tue, Jun 16, 2015 at 2:03 AM, Adam Back a...@cypherspace.org wrote: Dear Adam, All: At the community's convenience, it would be an honour to arrange an initial open summit to meet with representatives of the Chinese miners in

Re: [Bitcoin-development] Reusable payment codes

2015-06-16 Thread Peter Todd
On Tue, Jun 16, 2015 at 09:26:07AM -0700, odinn wrote: This is very well done. Have you seen this discussion that I started regarding BIP 63? https://bitcointalk.org/index.php?topic=1083961.0 I have no response from Peter Todd back on it other than my time is better spent focusing

Re: [Bitcoin-development] Scaling Bitcoin with Subchains

2015-06-16 Thread Peter Todd
On Mon, Jun 15, 2015 at 01:15:14PM -0400, Jeff Garzik wrote: On Mon, Jun 15, 2015 at 1:09 PM, Pieter Wuille pieter.wui...@gmail.com wrote: It's simple: either you care about validation, and you must validate everything, or you don't, and you don't validate anything. Sidechains do not

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

2015-06-12 Thread Peter Todd
On Fri, Jun 12, 2015 at 06:51:02PM +0200, Pieter Wuille wrote: The configuration used in the code right now simulates two groups of miners (one 80%=25%+25%+30%, one 20%=5%+5%+5%+5%), which are well-connected internally, but are only connected to each other through a slow 2 Mbit/s link. Here

Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-12 Thread Peter Todd
On Fri, Jun 12, 2015 at 02:22:36PM -0400, Matt Whitlock wrote: Why should miners only be able to vote for double the limit or halve the limit? If you're going to use bits, I think you need to use two bits: 0 0 = no preference (wildcard vote) 0 1 = vote for the limit to remain

Re: [Bitcoin-development] User vote in blocksize through fees

2015-06-12 Thread Peter Todd
On Fri, Jun 12, 2015 at 02:26:20PM -0400, Matt Whitlock wrote: On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote: Peter it's not clear to me that your described protocol is free of miner influence over the vote, by artificially generating transactions which they claim in their

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

2015-06-12 Thread Peter Todd
On Fri, Jun 12, 2015 at 01:21:46PM -0400, Gavin Andresen wrote: Nice work, Pieter. You're right that my simulation assumed bandwidth for 'block' messages isn't the bottleneck. But doesn't Matt's fast relay network (and the work I believe we're both planning on doing in the near future to

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

2015-06-11 Thread Peter Todd
Summary --- The BIP66 soft-fork recently passed the 75% support threshold. This means that 75% of the hashing power has upgraded to support BIP66; 25% of the hashing power has not. Once 95% of the hashing power has upgraded, blocks created by the 5% who have not upgraded will be rejected. If

[Bitcoin-development] First-Seen-Safe Replace-by-Fee patch against Bitcoin Core v0.10.2

2015-06-10 Thread Peter Todd
First-seen-safe Replace-by-Fee is now available as a patch against v0.10.2: https://github.com/petertodd/bitcoin/tree/first-seen-safe-rbf-v0.10.2 I've also had a pull-req against git HEAD open for a few weeks now: https://github.com/bitcoin/bitcoin/pull/6176#issuecomment-104877829 I've

Re: [Bitcoin-development] Proposal: SPV Fee Discovery mechanism

2015-06-10 Thread Peter Todd
On Wed, Jun 10, 2015 at 02:00:27PM -0600, Nathan Wilcox wrote: On Wed, Jun 10, 2015 at 1:19 PM, Aaron Voisine vois...@gmail.com wrote: It could be done by agreeing on a data format and encoding it in an op_return output in the coinbase transaction. If it catches on it could later be

Re: [Bitcoin-development] Lexicographical Indexing of Transaction Inputs and Outputs

2015-06-09 Thread Peter Todd
On Mon, Jun 08, 2015 at 06:53:54PM -0400, Kristov Atlas wrote: Two other things: On Sat, Jun 6, 2015 at 10:35 PM, Peter Todd p...@petertodd.org wrote: Why mention SIGHASH_SINGLE at all? Its use-case is highly specialized protocols; you haven't taken into account the needs of those

Re: [Bitcoin-development] [RFC] Canonical input and output ordering in transactions

2015-06-08 Thread Peter Todd
On Mon, Jun 08, 2015 at 02:25:40PM -0700, Danny Thorpe wrote: FWIW, The Open Assets colored coin protocol (CoinPrism) places special significance on the zeroth input and the position of the OP_RETURN colored coin marker output to distinguish colored coin issuance outputs from transfer outputs.

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the blocksize limit

2015-06-08 Thread Peter Todd
On Mon, Jun 08, 2015 at 03:01:34PM -0700, Raystonn . wrote: There will always be a blocksize limit based on technological considerations - the network has a finite bandwidth limit. A bandwidth limit is not the same as a blocksize limit. Bandwidth is unique to every individual. Miners in

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

2015-06-08 Thread Peter Todd
On Mon, Jun 08, 2015 at 06:06:00PM -0400, Bob McElrath wrote: There was this wonderful technology invented a few years ago to deal with spam. It's called Hashcash. All these hacky heuristics like block size are just dancing around the problem, and the natural solution is already present in

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

2015-06-08 Thread Peter Todd
On Mon, Jun 08, 2015 at 02:33:54PM -0700, Raystonn . wrote: the attack would be expensive. For attacks being waged to destroy Bitcoin by filling all blocks with spam transactions, the attack succeeds when the attacker is well funded. This gives well-funded private and/or public entities

Re: [Bitcoin-development] New attack identified and potential solution described: Dropped-transaction spam attack against the block size limit

2015-06-08 Thread Peter Todd
On Mon, Jun 08, 2015 at 10:13:10PM +, Patrick Mccorry (PGR) wrote: With the 0.01mBTC/KB minimum relay fee and $230 USD/BTC that works out to about $2.3kUSD/GB of ram IIRC, the fee is 0.1mBTC, so it's $23/MB (assuming 1,000 tx * 2.3 cents) and $23k/GB (assuming $23 * 1000, as each $23 is

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

2015-05-28 Thread Peter Todd
On Thu, May 28, 2015 at 01:19:44PM -0400, Gavin Andresen wrote: As for whether there should be fee pressure now or not: I have no opinion, besides we should make block propagation faster so there is no technical reason for miners to produce tiny blocks. I don't think us developers should be

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

2015-05-28 Thread Peter Todd
On Thu, May 28, 2015 at 11:30:18AM +0100, Tier Nolan wrote: Can you update it so that it only applies to transactions with version number 3 and higher. Changing the meaning of a field is exactly what the version numbers are for. You could even decode version 3 transactions like that.

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

2015-05-27 Thread Peter Todd
On Wed, May 27, 2015 at 08:18:52AM +, Gregory Maxwell wrote: On Wed, May 27, 2015 at 7:47 AM, Peter Todd p...@petertodd.org wrote: Equally this proposal is no more consensus enforcement than simply increasing the fee (and possibly decreasing the absolute nLockTime) for You've

Re: [Bitcoin-development] Version bits proposal

2015-05-27 Thread Peter Todd
On Wed, May 27, 2015 at 10:35:03AM +0100, Tier Nolan wrote: I think it would be better to have the deadlines set as block counts. That eliminates the need to use the median time mechanism. The median time mechanism is basically a way for hashing power to show what time they think it is.

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

2015-05-27 Thread Peter Todd
On Tue, May 26, 2015 at 01:13:05AM -0400, Peter Todd wrote: Case 1: Increasing the fee on a single tx - We start with a 1-in-2-out P2PKH using transaction t1, 226 bytes in size with the minimal relay fee, 2.26uBTC. Increasing the fee while respecting

Re: [Bitcoin-development] Consensus-enforced transaction replacement via sequence numbers

2015-05-27 Thread Peter Todd
On Tue, May 26, 2015 at 06:50:29PM -0700, Mark Friedenbach wrote: Sequence numbers appear to have been originally intended as a mechanism for transaction replacement within the context of multi-party transaction construction, e.g. a micropayment channel. The idea is that a participant can sign

Re: [Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

2015-05-26 Thread Peter Todd
On Wed, May 27, 2015 at 12:29:28AM +0300, s7r wrote: What is wrong with the man testing some ideas on his custom branch? This is how improvements come to life. I saw in the BIPs some really interesting ideas and nice brainstorming which came from Peter Todd. Now, my question, if replace

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

2015-05-25 Thread Peter Todd
On Mon, May 25, 2015 at 10:29:26PM +0200, Andreas Schildbach wrote: I see this behavior all the time. I am using the latest release, as far as I know. Version 4.30. The same behavior occurs in the Testnet3 variant of the app. Go in there with an empty wallet and receive one payment

[Bitcoin-development] Cost savings by using replace-by-fee, 30-90%

2015-05-25 Thread Peter Todd
On Tue, May 26, 2015 at 12:03:09AM +0200, Mike Hearn wrote: CPFP also solves it just fine. CPFP is a significantly more expensive way of paying fees than RBF, particularly for the use-case of defragmenting outputs, with cost savings ranging from 30% to 90% Case 1: CPFP vs. RBF for increasing

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

2015-05-25 Thread Peter Todd
On Mon, May 25, 2015 at 08:44:18PM +0200, Mike Hearn wrote: Wallets are incentivised to do a better job with defragmentation already, as if you have lots of tiny UTXOs then your fees end up being huge when trying to make a payment. The reason they largely don't is just one of manpower.

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

2015-05-25 Thread Peter Todd
Summary --- First-seen-safe replace-by-fee (FSS RBF) does the following: 1) Give users effective ways of getting stuck transactions unstuck. 2) Use blockchain space efficiently. without: 3) Changing the status quo with regard to zeroconf. The current Bitcoin Core implementation has

Re: [Bitcoin-development] Zero-Conf for Full Node Discovery

2015-05-25 Thread Peter Todd
On Tue, May 26, 2015 at 12:52:07AM -0400, Matt Whitlock wrote: On Monday, 25 May 2015, at 11:48 pm, Jim Phillips wrote: Do any wallets actually do this yet? Not that I know of, but they do seed their address database via DNS, which you can poison if you control the LAN's DNS resolver. I

[Bitcoin-development] Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet

2015-05-23 Thread Peter Todd
My replace-by-fee patch is now available for the Bitcoin Core v0.10.2 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2 This release fixes a serious DoS attack present in previous releases. Upgrading is strongly recommended for relay nodes, and mandatory for miners.

Re: [Bitcoin-development] ChainDB Whitepaper

2015-05-20 Thread Peter Todd
-development] Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation Peter Todd, Nov 19th, 2013, http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03307.html 2) https://github.com/bitcoin/bitcoin/pull/5863 3) https://en.bitcoin.it/wiki

Re: [Bitcoin-development] Proposed additional options for pruned nodes

2015-05-12 Thread Peter Todd
On Tue, May 12, 2015 at 09:05:44AM -0700, Jeff Garzik wrote: A general assumption is that you will have a few archive nodes with the full blockchain, and a majority of nodes are pruned, able to serve only the tail of the chains. Hmm? Lots of people are tossing around ideas for partial

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

2015-05-12 Thread Peter Todd
On Tue, May 12, 2015 at 08:38:27PM +, Luke Dashjr wrote: It should actually be straightforward to softfork RCLTV in as a negative CLTV. All nLockTime are = any negative number, so a negative number makes CLTV a no-op always. Therefore, it is clean to define negative numbers as relative

Re: [Bitcoin-development] Reducing the block rate instead of increasing the maximum block size

2015-05-11 Thread Peter Todd
. Peter Todd has argued that the best strategy for miners is actually to reach 51% of the network, but not more. In other words, to exclude the slowest 49% Actually the correct figure is less than ~30%: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03200.html percent

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

2015-05-09 Thread Peter Todd
On Tue, May 05, 2015 at 01:54:33AM +0100, Btc Drak wrote: That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act as OP_NOP's. A future relative CLTV could

Re: [Bitcoin-development] Bitcoin-development Digest, Vol 48, Issue 41

2015-05-09 Thread Peter Todd
On Sat, May 09, 2015 at 12:42:08AM +, Gregory Maxwell wrote: On Sat, May 9, 2015 at 12:00 AM, Damian Gomez dgomez1...@gmail.com wrote: where w represents the weight of the total number of semantical constraints that an idivdual has expressed throught emotivoe packets that I am working

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

2015-05-09 Thread Peter Todd
On Sat, May 09, 2015 at 01:36:56AM +0300, Joel Joonatan Kaartinen wrote: such a contract is a possibility, but why would big owners give an exclusive right to such pools? It seems to me it'd make sense to offer those for any miner as long as the get paid a little for it. Especially when it's

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-08 Thread Peter Todd
On Fri, May 08, 2015 at 12:03:04PM +0200, Mike Hearn wrote: * Though there are many proposals floating around which could significantly decrease block propagation latency, none of them are implemented today. With a 20mb cap, miners still have the option of the soft limit. The

Re: [Bitcoin-development] Assurance contracts to fund the network with OP_CHECKLOCKTIMEVERIFY

2015-05-08 Thread Peter Todd
On Fri, May 08, 2015 at 06:00:37AM -0400, Jeff Garzik wrote: That reminds me - I need to integrate the patch that automatically sweeps anyone-can-pay transactions for a miner. You mean anyone-can-spend? I've got code that does this actually:

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

2015-05-08 Thread Peter Todd
On Fri, May 08, 2015 at 03:32:00PM +0300, Joel Joonatan Kaartinen wrote: Matt, It seems you missed my suggestion about basing the maximum block size on the bitcoin days destroyed in transactions that are included in the block. I think it has potential for both scaling as well as keeping up a

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-08 Thread Peter Todd
On Fri, May 08, 2015 at 08:47:52PM +0100, Tier Nolan wrote: On Fri, May 8, 2015 at 5:37 PM, Peter Todd p...@petertodd.org wrote: The soft-limit is there miners themselves produce smaller blocks; the soft-limit does not prevent other miners from producing larger blocks. I wonder

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 12:59:13PM -0400, Gavin Andresen wrote: Fee dynamics seems to come up over and over again in these discussions, with lots of talk and theorizing. I hope some data on what is happening with fees right now might help, so I wrote another blog post (with graphs, which

Re: [Bitcoin-development] Block Size Increase Requirements

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 10:02:09PM +, Matt Corallo wrote: OK, so lets do that. I've seen a lot of I'm not entirely comfortable with committing to this right now, but think we should eventually, but not much I'd be comfortable with committing to this when I see X. In the interest of

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 11:25:04AM +0200, Mike Hearn wrote: Certainly a consensus in this kind of technical community should be a basic requirement for any serious commitment to blocksize increase. I'm afraid I have come to disagree. I no longer believe this community can reach consensus

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 03:31:46PM -0400, Alan Reiner wrote: We get asked all the time by corporate clients about scalability. A limit of 7 tps makes them uncomfortable that they are going to invest all this time into a system that has no chance of handling the economic activity that they

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote: Peter: your hypocrisy really is bottomless, isn't it? You constantly claim to be a Righteous Defender of Privacy, but don't even hesitate before publishing hacked private emails when it suits you. Satoshi's hacker had no illusions

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 05:13:34PM +0200, Justus Ranvier wrote: On 05/07/2015 04:49 PM, Peter Todd wrote: I think we'll find an basic assumption of civility to be more productive, until proven otherwise. (e.g. NSA ties) I'm not sure why you'd construe my post as having anything to do

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 10:04:21AM -0400, Jeff Garzik wrote: I have a lot more written down, a WIP; here are the highlights. - The 1MB limit is an ancient anti-spam limit, and needs to go. - The 1MB limit is economically entrenched at this point, and cannot be removed at a whim. - This

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 04:05:41PM +0200, Mike Hearn wrote: One thing is the Bitcoin core project where you could argue that the 5 committers decide (I don't know why Wladimir would have any more authority than the others). Because he is formally the maintainer. I quite liked

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 04:38:22PM +0200, Justus Ranvier wrote: On 05/07/2015 04:04 PM, Jeff Garzik wrote: - This is a major change to the economics of a $3.2B system. This change picks winners and losers. There is attendant moral hazard. This is exactly true. There are a number of

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 10:52:54AM -0400, Gavin Andresen wrote: I AM considering contributing some version of the bigger blocksize-limit hard-fork patch to the Bitcoin-Xt fork (probably target a hobbyist with a fast Internet connection, and assume Nelson's law to increase over time), and then

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 01:29:44PM +0200, Mike Hearn wrote: What if Gavin popped up right now and said he disagreed with every current proposal, he disagreed with side chains too, and there would be no consensus on any of them until the block size limit was raised. Would you say, oh, OK,

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

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 11:05:47AM +0930, Rusty Russell wrote: Peter Todd p...@petertodd.org writes: That said, if people have strong feelings about this, I would be willing to make OP_CLTV work as follows: nLockTime 1 OP_CLTV Where the 1 selects absolute mode, and all others act

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Peter Todd
On Thu, May 07, 2015 at 06:21:50PM +0200, Jorge Timón wrote: On Thu, May 7, 2015 at 4:52 PM, Gavin Andresen gavinandre...@gmail.com wrote: I would very much like to find some concrete course of action that we can come to consensus on. Some compromise so we can tell entrepreneurs THIS is

Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Peter Todd
On Wed, May 06, 2015 at 11:41:37PM +, Matt Corallo wrote: Yes, but this does NOT make an actual policy. Note that the vast majority of miners already apply their own patches to Bitcoin Core, so applying one more is not all that hard. When blocks start to become limited (ie there is any fee

Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Peter Todd
On Wed, May 06, 2015 at 10:12:14PM +, Matt Corallo wrote: Personally, I'm rather strongly against any commitment to a block size increase in the near future. Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very

[Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1

2015-05-03 Thread Peter Todd
My replace-by-fee patch is now available for the v0.10.1 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.1 No new features in this version; this is simply a rebase for the Bitcoin Core v0.10.1 release. (there weren't even any merge conflicts) As with the Bitcoin Core

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

2015-05-03 Thread Peter Todd
Matt Corallo brought up¹ the issue of OP_NOP scarcity on the mempool only CLTV pull-req²: I like merging this, but doing both CLTV things in one swoop would be really nice. Certainly if we're gonna use one of the precious few OP_NOPs we have we might as well make it more flexible. I

Re: [Bitcoin-development] Bitcoin core 0.11 planning

2015-04-28 Thread Peter Todd
On Tue, Apr 28, 2015 at 04:01:00AM -0700, Pieter Wuille wrote: As softforks almost certainly require backports to older releases and other software anyway, I don't think they should necessarily be bound to Bitcoin Core major releases. If they don't require large code changes, we can easily do

Re: [Bitcoin-development] Bitcoin core 0.11 planning

2015-04-28 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 I'll point out that at this rate the soonest we'll see CHECKLOCKTIMEVERIFY implemented on Bitcoin will be something like summer 2016, a year and a half after it got adopted on Viacoin. (and a few other alts whose names I forget) Right now the

Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

2015-04-27 Thread Peter Todd
On Sun, Apr 26, 2015 at 02:20:04PM +0200, Jorge Timón wrote: On Sun, Apr 26, 2015 at 1:35 PM, Jorge Timón jti...@jtimon.cc wrote: And a new softfork rule could enforce that all new CTxIn set nHeight to the correct height in which its corresponding prevout got into the chain. That would

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

2015-04-27 Thread Peter Todd
On Sat, Apr 25, 2015 at 10:32:36AM -0400, Stephen Morse wrote: Hi William, I personally prefer this solution, since it nails the problem completely with one simple and obvious change. The BIP 62 approach is more like a game of wac-a-mole. The two are complementary, not competing.

Re: [Bitcoin-development] Relative CHECKLOCKTIMEVERIFY (was CLTV proposal)

2015-04-21 Thread Peter Todd
On Mon, Mar 16, 2015 at 10:22:13PM +, Matt Corallo wrote: In building some CLTV-based contracts, it is often also useful to have a method of requiring, instead of locktime-is-at-least-N, locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine an

Re: [Bitcoin-development] Double spending and replace by fee

2015-04-21 Thread Peter Todd
On Wed, Apr 08, 2015 at 11:28:08PM -0700, Adrian Macneil wrote: Fwiw, Coinbase relies on the current first-seen mempool behaviour. Wide adoption of RBF (without a suitable replacement available) would make it extremely difficult to pitch bitcoin as a viable alternative to credit cards

Re: [Bitcoin-development] Build your own nHashType

2015-04-18 Thread Peter Todd
On Thu, Apr 09, 2015 at 10:56:20PM -0400, Stephen Morse wrote: On Thu, Apr 9, 2015 at 1:28 PM, Peter Todd p...@petertodd.org wrote: For the OP: Have you looked at how CODESEPARATOR allows the signature to sign code to run as part of verifying the signature? E.g. my signature can say valid

Re: [Bitcoin-development] Build your own nHashType

2015-04-09 Thread Peter Todd
On Thu, Apr 09, 2015 at 07:22:52AM -0700, Jeff Garzik wrote: On Thu, Apr 9, 2015 at 7:10 AM, Stephen Morse stephencalebmo...@gmail.com wrote: Is hashing transaction data once for each input really a huge bottleneck, though? Do mobile devices have an issue with this? Think about what

Re: [Bitcoin-development] My thoughts on the viability of the Factom token

2015-03-29 Thread Peter Todd
On Fri, Mar 20, 2015 at 12:46:18AM -0500, Brian Deery wrote: Greetings mailing list. Not sure that this content is 100% appropriate here, but Peter Todd invited me to post this for archival purposes. The original thread has been removed from the search results, but is still up here: http

Re: [Bitcoin-development] Double spending and replace by fee

2015-03-28 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Would you so us all a favor and make a list of companies *actually* relying on first-seen mempool behaviour. Because I've been having a hard time actually finding anyone who does who hasn't given up on it. Not very useful to talk about attacks

[Bitcoin-development] My thoughts on the viability of the Factom token

2015-03-16 Thread Peter Todd
Repost of https://www.reddit.com/r/Bitcoin/comments/2z9k5p/factom_announces_launch_date_for_software_token/cph0pvo for archival/disclosure purposes: I'm very skeptical about the long-term viability of Factom and the value of the Factom token. The idea behind Factom is to create a

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Peter Todd
On Sun, Feb 22, 2015 at 08:02:03AM +, Adam Back wrote: FWIW I've been advocating this kind of thing in various forms for literally years, including to hold fidelity bonded banks honest - what you now call 'federated sidechains' - and most recently Feb 12th on #bitcoin-dev: 19:56 petertodd

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-22 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo elombr...@gmail.com wrote: In case it wasn't clear in my earlier post, there's of course a third possibility - namely, some outputs are kept but not all. Here, it is generally impossible to

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Peter Todd
On Sun, Feb 22, 2015 at 02:11:31PM +, Adam Back wrote: My actual point outside of the emotive stuff (and I should've stayed away from that too) is how about we explore ways to improve practical security of fast confirmation transactions, and if we find something better, then we can help

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22 February 2015 08:50:30 GMT-05:00, Matt Whitlock b...@mattwhitlock.name wrote: On Sunday, 22 February 2015, at 2:29 pm, Natanael wrote: In other words, you are unprotected and potentially at greater risk if you create a transaction

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-22 Thread Peter Todd
On Sun, Feb 22, 2015 at 08:36:01AM -0800, Tom Harding wrote: On 2/11/2015 10:47 PM, Peter Todd wrote: My replace-by-fee patch is now available for the v0.10.0rc4 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4 This patch immediately simplifies successful

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-21 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21 February 2015 17:47:28 GMT-05:00, Jeff Garzik jgar...@bitpay.com wrote: scorched earth refers to the _real world_ impact such policies would have on present-day 0-conf usage within the bitcoin community. I think you guys are reading too

Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-15 Thread Peter Todd
On Sat, Feb 14, 2015 at 11:04:49AM -0800, Adam Back wrote: Strongly with Peter on this. That its highly complex to maintain strict consensus between bitcoin versions, does not justify consensus rewrite experiments; it tells you that the risk is exponentially worse and people should use and

Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-15 Thread Peter Todd
On Sun, Feb 15, 2015 at 06:13:06PM +0100, Tamas Blummer wrote: On Feb 15, 2015, at 6:02 PM, Peter Todd p...@petertodd.org wrote: Yes you are dicking around. I thought I was clear, that I am using Bitcoin Core as border router talking to its P2P interface. Ah, sorry, that wasn't clear

Re: [Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-15 Thread Peter Todd
On Sat, Feb 14, 2015 at 03:23:47PM +0100, Tamas Blummer wrote: Peter, You did not address me but libbitcoin. Since our story and your evaluation is probably similar, I chime in. On Feb 14, 2015, at 2:13 PM, Peter Todd p...@petertodd.org wrote: So stop wasting your time. Help get

[Bitcoin-development] On Rewriting Bitcoin (was Re: [Libbitcoin] Satoshi client: is a fork past 0.10 possible?)

2015-02-14 Thread Peter Todd
I haven't bothered reading the thread, but I'll put this out there: The consensus critical Satoshi-derived sourcecode is a protocol *specification* that happens to also be machine readable and executable. Rewriting it is just as silly as as taking RFC 791 and rewriting it because you wanted to

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Peter Todd
On Thu, Feb 12, 2015 at 08:15:01PM +0100, Alan Reiner wrote: The Bitcoin network achieves something that we didnt' think was possible 10 years ago: a totally trustless, decentralized ledger. The cost? It takes time for the decentralized network to reach consensus that transactions happened.

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Peter Todd
On Thu, Feb 12, 2015 at 07:49:29PM +, Gregory Maxwell wrote: One challenge is that without rather smart child-pays-for-parent logic the positive argument for replace by fee doesn't really work. That's actually incorrect now, as a mechanism for implementing scorched-earth without

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Peter Todd
On Thu, Feb 12, 2015 at 07:34:22PM +, Justus Ranvier wrote: In addition, I'll add that there is an assumption that honest actors can not alter their behavior in response to changing conditions. Since scorched-earth solutions to problems are apparently acceptable now, what would stop more

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Peter Todd
On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote: On Feb 12, 2015, at 8:45 AM, Peter Todd p...@petertodd.org wrote: IOW, assume every transaction your border router gives you is now the one and only true transaction, and everything conflicting with it must go. You

Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses

2015-02-12 Thread Peter Todd
On Thu, Feb 12, 2015 at 10:13:33PM +, Luke Dashjr wrote: Where is the Specification section?? Does this support arbitrary scripts, or only the simplest CHECKMULTISIG case? It might be enough to rewrite this BIP to basically say all pubkeys executed by all CHECKMULTISIG opcodes will be in

[Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-11 Thread Peter Todd
My replace-by-fee patch is now available for the v0.10.0rc4 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4 Along with demo scripts of the functionality: https://github.com/petertodd/replace-by-fee-tools New to this version is a comprehensive set of

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-11 Thread Peter Todd
On Thu, Feb 12, 2015 at 08:23:29AM +0100, Tamas Blummer wrote: Peter, An important use of the core is being border router to proprietary software, that is usually indexing the block chain and mempool. That software is also assuming that double spends are not relayed by the core. To

Re: [Bitcoin-development] Update to Double-Spend Deprecation Window Proposal

2015-02-08 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 This is an incredibly dangerous and foolish proposal that opens up the Bitcoin network to serious vulnerabilities, both from attackers outside the network, as well as miners trying to gain an advantage over their competition. Ultimately it's

Re: [Bitcoin-development] determining change addresses using the least significant digits

2015-02-05 Thread Peter Todd
On Wed, Feb 04, 2015 at 03:23:23PM +0100, Isidor Zeuner wrote: Hi there, traditionally, the Bitcoin client strives to hide which output addresses are change addresses going back to the payer. However, especially with today's dynamically calculated miner fees, this may often be ineffective:

Re: [Bitcoin-development] Merged mining a side chain with proof of burn on parent chain

2015-02-05 Thread Peter Todd
On Wed, Feb 04, 2015 at 02:54:43PM +0100, Isidor Zeuner wrote: Hi there, comments in-line: I later wrote up the idea in the context of adding Zerocoin to Bitcoin: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02472.html For the sake of maximum clarity

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 23 January 2015 08:35:23 GMT-08:00, slush sl...@centrum.cz wrote: Oh, now I got the 'soft-fork' alternative. If that means that *senders* to Trezor need to be nice guys and use some special outputs, then it's, obviously, no-go solution. That's

Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships

2015-01-20 Thread Peter Todd
On Tue, Jan 20, 2015 at 08:43:57AM -0800, Daniel Stadulis wrote: Hey Peter, What would you say to the argument: given developers have auto update capabilities they only have the ability to *give themselves* *the ability* to have custodial rights? Heh, well, courts tend not to have the

  1   2   3   4   5   >