Re: [Bitcoin-development] DS Deprecation Window

2014-10-27 Thread Thomas Zander
On Monday 27. October 2014 19.26.48 Tom Harding wrote: > Miner has to be very careful including a double-spend in his block -- he > hopes: How does it help the zero-confirmation to not include a payment? Doesn't that just mean that if I send a double spend that neither of the payments will be m

Re: [Bitcoin-development] DS Deprecation Window

2014-10-27 Thread Gregory Maxwell
On Tue, Oct 28, 2014 at 2:26 AM, Tom Harding wrote: > Matt, > > You're right, thanks. Without double-spend relay, miner won't know that > some txes conflict with anything. Even with that, the miner cannot tell, his only safe option is to include no transactions at all. Consider a malicious mine

Re: [Bitcoin-development] DS Deprecation Window

2014-10-27 Thread Tom Harding
Matt, You're right, thanks. Without double-spend relay, miner won't know that some txes conflict with anything. I'll add that first-double-spends are relayed per #4570. Miner has to be very careful including a double-spend in his block -- he hopes: - that based on his measured time offset

Re: [Bitcoin-development] DS Deprecation Window

2014-10-27 Thread Matt Corallo
It is a very bad idea to delay relaying/accepting blocks based on information which is only local to your node (ie would create the ability for people to split the network by sending out lots of double-spends to different parts of the network at the same time). Thus, miners are incentivized to go c

[Bitcoin-development] DS Deprecation Window

2014-10-27 Thread Tom Harding
Greetings Bitcoin Dev, This is a proposal to improve the ability of bitcoin users to rely on unconfirmed transactions. It can be adopted incrementally, with no hard or soft fork required. https://github.com/dgenr8/out-there/blob/master/ds-dep-win.md Your thoughtful feedback would be very much

[Bitcoin-development] Reworking the policy estimation code (fee estimates)

2014-10-27 Thread Alex Morcos
I've been playing around with the code for estimating fees and found a few issues with the existing code. I think this will address several observations that the estimates returned by the existing code appear to be too high. For instance see @cozz in Issue 4866

Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule

2014-10-27 Thread Jeff Garzik
On Mon, Oct 27, 2014 at 7:24 AM, Melvin Carvalho wrote: > Do you think it would a reasonable idea to put down some thoughts and > proposals in a BIP? It would certainly be nice to start with a document that reflects the new REST interface. That makes a good starting point for further discussion.

Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule

2014-10-27 Thread Melvin Carvalho
On 27 October 2014 08:49, Wladimir wrote: > On Sun, Oct 26, 2014 at 12:44 PM, Melvin Carvalho > wrote: > > > Firstly, apologies in coming in late to the conversation. As I am also > > working on a REST API for electronic coins. Some questions: > > > > 1. Is there a BIP, or some other doc (e.g.

Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule

2014-10-27 Thread Wladimir
On Sun, Oct 26, 2014 at 12:44 PM, Melvin Carvalho wrote: > Firstly, apologies in coming in late to the conversation. As I am also > working on a REST API for electronic coins. Some questions: > > 1. Is there a BIP, or some other doc (e.g. gist), outlining the REST output > e.g. the response for

Re: [Bitcoin-development] Bitcoin Core 0.10 release schedule

2014-10-27 Thread Wladimir
On Sun, Oct 26, 2014 at 9:53 AM, Luke Dashjr wrote: > On Sunday, October 26, 2014 7:57:12 AM Wladimir wrote: >> Let me know if there is anything else you think is ready (and not too >> risky) to be in 0.10. > > At the very least, we need: > #5106 Bugfix: submitblock: Use a temporary CValidationS