Re: [Bitcoin-development] improving development model (Re: Concerns Regarding Threats by a Developer to Remove Commit Access from Other Developers

2015-06-19 Thread Tom Harding
On 6/19/2015 6:43 AM, Mike Hearn wrote: No surprise, the position of Blockstream employees is that hard forks must never happen and that everyone's ordinary transactions should go via some new network that doesn't yet exist. If my company were working on spiffy new ideas that required a hard

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

2015-06-18 Thread Tom Harding
On 06/12/2015 06:51 PM, Pieter Wuille wrote: However, it does very clearly show the effects of larger blocks on centralization pressure of the system. On 6/14/2015 10:45 AM, Jonas Nick wrote: This means that your scenario is not the result of a cartel but the result of a long-term network

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

2015-06-15 Thread Tom Harding
mailto:ka...@rosenbaum.se: 2015-06-06 18:10 GMT+02:00 Tom Harding t...@thinlink.com mailto:t...@thinlink.com: On Jun 6, 2015 8:05 AM, Kalle Rosenbaum ka...@rosenbaum.se mailto:ka...@rosenbaum.se wrote: I'm open to changes here. I suggest

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

2015-06-11 Thread Tom Harding
On 6/11/2015 6:10 AM, Peter Todd wrote: On Wed, Jun 10, 2015 at 02:18:30PM -0700, Aaron Voisine wrote: The other complication is that this will tend to be a lagging indicator based on network congestion from the last time you connected. If we assume that transactions are being dropped in an

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

2015-06-06 Thread Tom Harding
On Jun 6, 2015 8:05 AM, Kalle Rosenbaum ka...@rosenbaum.se wrote: I'm open to changes here. I suggest: - Don't include any real outputs. They are redundant because the txid is already referenced. - Start the proof script, which should be invalid, with a magic constant and include space for

Re: [Bitcoin-development] soft-fork block size increase (extension blocks)

2015-06-01 Thread Tom Harding
On 6/1/2015 10:21 AM, Adam Back wrote: if it stays as is for a year, in a wait and see, reduce spam, see fee-pressure take effect as it has before, work on improving improve decentralisation metrics, relay latency, and do a blocksize increment to kick the can if-and-when it becomes necessary

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

2015-05-26 Thread Tom Harding
I think this is a significant step forward. I suggest you also need to ensure that no inputs can be removed or changed (other than scriptsigs) -- only added. Otherwise, the semantics change too much for the original signers. Imagine a tx with two inputs from different parties. Should it be

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

2015-05-26 Thread Tom Harding
On 5/26/2015 4:11 PM, Gregory Maxwell wrote: On Tue, May 26, 2015 at 11:00 PM, Tom Harding t...@thinlink.com wrote: The bitcoin transaction is part of a real-world deal with unknown connections to the other parts I'm having a hard time parsing this. You might as well say that its part

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

2015-05-16 Thread Tom Harding
On 5/16/2015 1:35 PM, Owen Gunden wrote: There are alternatives that still use bitcoin as the unit of value, such as sidechains, offchain, etc. To say that these are not bitcoin is misleading. Is it? Nobody thinks euro accepted implies Visa is ok, even though Visa is just a bunch of extra

[Bitcoin-development] No Bitcoin For You

2015-05-14 Thread Tom Harding
A recent post, which I cannot find after much effort, made an excellent point. If capacity grows, fewer individuals would be able to run full nodes. Those individuals, like many already, would have to give up running a full-node wallet :( That sounds bad, until you consider that the alternative

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Tom Harding
On 5/7/2015 12:54 PM, Jeff Garzik wrote: In the short term, blocks are bursty, with some on 1 minute intervals, some with 60 minute intervals. This does not change with larger blocks. I'm pretty sure Alan meant that blocks are already filling up after long inter-block intervals. 2)

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Tom Harding
On 5/7/2015 7:09 PM, Jeff Garzik wrote: G proposed 20MB blocks, AFAIK - 140 tps A proposed 100MB blocks - 700 tps For ref, Paypal is around 115 tps VISA is around 2000 tps (perhaps 4000 tps peak) I ask again: where do we want to go? This is the existential question behind block size.

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Tom Harding
On 5/7/2015 6:40 AM, Jorge Timón wrote: Known: There's a major problem looming for miners at the next block reward halving. Many are already in a bad place and without meaningful fees then sans a 2x increase in the USD:BTC ratio then many will simply have to leave the network, increasing

Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Tom Harding
On 5/6/2015 3:12 PM, Matt Corallo wrote: Long-term incentive compatibility requires that there be some fee pressure, and that blocks be relatively consistently full or very nearly full. I think it's way too early to even consider a future era when the fiat value of the block reward is no

Re: [Bitcoin-development] Proof of Payment

2015-04-26 Thread Tom Harding
On 4/22/2015 1:03 PM, Kalle Rosenbaum wrote: I've built a proof-of-concept for Proof of Payment. It's available at http://www.rosenbaum.se:8080. The site contains links to the source code for both the server and a Mycelium fork as well as pre-built apk:s. There are several scenarios in

[Bitcoin-development] Address Expiration to Prevent Reuse

2015-03-24 Thread Tom Harding
The idea of limited-lifetime addresses was discussed on 2014-07-15 in http://thread.gmane.org/gmane.comp.bitcoin.devel/5837 It appears that a limited-lifetime address, such as the fanciful address = 4HB5ld0FzFVj8ALj6mfBsbifRoD4miY36v_349366 where 349366 is the last valid block for a

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

2015-02-22 Thread Tom Harding
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 double-spends of unconfirmed transactions. But the idea that it

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

2015-02-12 Thread Tom Harding
On 2/11/2015 10:47 PM, Peter Todd wrote: ... replace-by-fee ... Replace-by-fee creates the power to repudiate an entire tree of payments, and hands this power individually to the owner of each input to the top transaction. Presumably this is why the original replacement code at least

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

2015-02-12 Thread Tom Harding
On 2/12/2015 6:25 AM, Tamas Blummer wrote: Miner will see a mixed picture and will struggle to act “honestly” on a statistical measure. The statistics come from the aggregate actions of all nodes, especially those miners who watch p2p transactions and assemble blocks. Any one node makes

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

2015-02-09 Thread Tom Harding
Many thanks for the feedback Peter. Please if you would, see below On 2/8/2015 10:32 PM, Peter Todd wrote: Seeing a transaction is not a guarantee that any other node has seen it; not seeing a transaction is not a guarantee other nodes have not seen a spend. In no way does proposal rely on

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

2015-02-08 Thread Tom Harding
This update strengthens the incentive not to confirm double-spends after time T (30 seconds). To grow and stabilize adoption, it is necessary to influence the miner of the block after a deprecated block, who in turn is concerned with the block after that. Accordingly, the disincentive is

Re: [Bitcoin-development] IMPULSE: Instant Payments using the Bitcoin protocol

2015-01-22 Thread Tom Harding
On 1/17/2015 12:45 PM, Rune Kjær Svendsen wrote: PDF: http://impulse.is/impulse.pdf I'd love to hear this list's thoughts. Will success be defined by BitPay Payment Channels Accepted Here signs appearing in shop windows?

Re: [Bitcoin-development] DS Deprecation Window

2014-11-06 Thread Tom Harding
first seen, he should expect 5 of 1 nodes to delay his block. Hal Finney remarked that this idea would need careful analysis. More help is very welcome. https://bitcointalk.org/index.php?topic=3441.msg48789#msg48789 Cheers! On 10/28/2014 10:38 AM, Tom Harding wrote: So, I think

Re: [Bitcoin-development] DS Deprecation Window

2014-10-28 Thread Tom Harding
On 10/27/2014 7:36 PM, Gregory Maxwell wrote: Consider a malicious miner can concurrently flood all other miners with orthogonal double spends (which he doesn't mine himself). These other miners will all be spending some amount of their time mining on these transactions before realizing others

[Bitcoin-development] DS Deprecation Window

2014-10-27 Thread Tom Harding
much appreciated. It is not yet implemented anywhere. Cheers, Tom Harding CA, USA -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https

Re: [Bitcoin-development] DS Deprecation Window

2014-10-27 Thread Tom Harding
:17 PM, Matt Corallo wrote: miners are incentivized to go connect to everyone on the network and look for double-spends On 10/27/14 19:58, Tom Harding wrote: https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

2014-10-07 Thread Tom Harding
On 10/7/2014 8:50 AM, Gavin Andresen wrote: I don't have any opinion on the hard- versus soft- fork debate. I think either can work. Opinion: if a soft work works, it should be preferred, if for no other reason than once a hard-fork is planned, the discussion begins about what else to

Re: [Bitcoin-development] bitcoinj 0.12

2014-10-03 Thread Tom Harding
I'm stunned by what bitcoinj can do these days. Just reading the release notes gives one app ideas. Mike, Awesome. On 10/3/2014 5:49 AM, Mike Hearn wrote: I'm pleased to announce version 0.12 of bitcoinj, one of the worlds most popular Bitcoin libraries.

Re: [Bitcoin-development] SPV clients and relaying double spends

2014-09-27 Thread Tom Harding
On 9/25/2014 7:37 PM, Aaron Voisine wrote: Of course you wouldn't want nodes to propagate alerts without independently verifying them How would a node independently verify a double-spend alert, other than by having access to an actual signed double-spend? #4570 relays the first double-spend AS

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-08 Thread Tom Harding
Having explored more drastic approaches, it looks like Kaz' basic idea stands well. His #1... 1. start setting nLockTime to the current height by default in newly created transactions (or slightly below the current height, for reorg-friendliness) is already implemented in bitcoin-qt #2340,

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Tom Harding
to rewrite their nLockTime, if it fails to be confirmed before some arbitrary deadline being set. On Wed, Aug 6, 2014 at 12:01 AM, Tom Harding t...@thinlink.com mailto:t...@thinlink.com wrote: ... If nLockTime is used for expiration, transaction creator can't lie

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-06 Thread Tom Harding
Today we have first-eligible-height (nLockTime), and mempool expiration measured from this height would work for the goals being discussed, no fork or protocol rev. With first-eligible-height and last-eligible-height, creator could choose a lifetime shorter than the max, and in addition,

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-05 Thread Tom Harding
On 8/5/2014 12:10 PM, Kaz Wesley wrote: Any approach based on beginning a transaction expiry countdown when a transaction is received (as in mempool janitor) seems unviable to me: once a node has forgotten a transaction, it must be susceptible to reaccepting it; It's hard to argue with

Re: [Bitcoin-development] deterministic transaction expiration

2014-08-01 Thread Tom Harding
On 7/31/2014 5:58 PM, Kaz Wesley wrote: 1. start setting nLockTime to the current height by default in newly created transactions (or slightly below the current height, for reorg-friendliness) Reorg-frendliness is the opposite of the rationale behind #2340, which proposes setting nLockTime at

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-17 Thread Tom Harding
On 6/16/2014 8:09 AM, Daniel Rice wrote: What if we solved doublespends like this: If a node receives 2 transactions that use the same input, they can put both of them into the new block as a proof of double spend, but the bitcoins are not sent to the outputs of either transactions. They

Re: [Bitcoin-development] instant confirmation via payment protocol backwards compatible proto buffer extension

2014-06-17 Thread Tom Harding
On 6/16/2014 8:48 AM, Mike Hearn wrote: In practice of course this is something payment processors like Bitpay and Coinbase will think about. Individual cafes etc who are just using mobile wallets won't be able to deal with this complexity: if we can't make native Bitcoin work well enough

Re: [Bitcoin-development] A statistical consensus rule for reducing 0-conf double-spend risk

2014-05-12 Thread Tom Harding
is .0025 BTC, still quite high for one transaction. I guess miner could try to make a business out of mining double-spends, to defray that cost. On 5/11/2014 9:41 PM, Tom Harding wrote: Back up to the miner who decided to include a seasoned double-spend in his block. Let's say he saw it 21

Re: [Bitcoin-development] A statistical consensus rule for reducing 0-conf double-spend risk

2014-05-06 Thread Tom Harding
Christophe Biocca wrote: it becomes trivial with a few tries to split the network into two halves: (tx1 before tx2, tx2 before tx1). before implies T=0. That is a much too optimistic choice for T; 50% of nodes would misidentify the respend. Tom Harding t...@thinlink.com wrote

[Bitcoin-development] A statistical consensus rule for reducing 0-conf double-spend risk

2014-05-03 Thread Tom Harding
This idea was suggested by Joe on 2011-02-14 https://bitcointalk.org/index.php?topic=3441.msg48484#msg48484 . It deserves another look. Nodes today make a judgment regarding which of several conflicting spends to accept, and which is a double-spend. But there is no incorporation of these

Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise

2014-04-23 Thread Tom Harding
On 4/22/2014 9:03 PM, Matt Whitlock wrote: On Tuesday, 22 April 2014, at 8:45 pm, Tom Harding wrote: A network where transaction submitters consider their (final) transactions to be unchangeable the moment they are transmitted, and where the network's goal is to confirm only transactions all

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

2014-04-23 Thread Tom Harding
On 4/23/2014 2:23 PM, Tier Nolan wrote: An interesting experiment would be a transaction proof of publication chain. What if a transaction could simply point back to an earlier transaction, forming a chain? Not a separately mined blockchain, just a way to establish an official publication

Re: [Bitcoin-development] Economics of information propagation

2014-04-22 Thread Tom Harding
Jonathan - These are a few things I've been wishing for recent data on: - 95th percentile transaction propagation time vs. fees/kb, vs. total fees - Count of blocks bypassing well-propagated transactions vs. fees/kb, vs. total fees - Signed-double-spend confirmation probability vs.

Re: [Bitcoin-development] Double-spending unconfirmed transactions is a lot easier than most people realise

2014-04-22 Thread Tom Harding
Since no complete solution to preventing 0-confirmation respends in the bitcoin network has been proposed, or is likely to exist, when evaluating partial solutions let's ask what kind of network does this move toward? Does the solution move toward a network with simple rules, where the