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 l...@dashjr.org 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

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 melvincarva...@gmail.com 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

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

2014-10-27 Thread Melvin Carvalho
On 27 October 2014 08:49, Wladimir laa...@gmail.com wrote: On Sun, Oct 26, 2014 at 12:44 PM, Melvin Carvalho melvincarva...@gmail.com 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

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 melvincarva...@gmail.com 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

[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

[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

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

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

Re: [Bitcoin-development] DS Deprecation Window

2014-10-27 Thread Gregory Maxwell
On Tue, Oct 28, 2014 at 2:26 AM, Tom Harding t...@thinlink.com 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