Re: [bitcoin-dev] The new obfuscation patch & GetStats

Hey, Daniel. Patch author here. Thanks for the diligence; I think this indeed may be an oversight, though I'm going to need to look into a bit more thoroughly at home. Curious that it didn't fail any of the automated tests. Correct me if I'm wrong, but the only actual invocation of that method

[bitcoin-dev] soft-fork security (Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!)

On 7 October 2015 at 18:26, Jonathan Toomim (Toomim Bros) via bitcoin-dev wrote: > On Oct 7, 2015, at 9:02 AM, Eric Lombrozo wrote: > If you had a 99% hashpower supermajority on the new version, an attacker > would still be able to

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Monday, October 5, 2015, Mike Hearn via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > As Greg explained to you repeatedly, a softfork won't cause a >> non-upgraded full node to start accepting blocks that create more >> subsidy than is valid. >> > > It was an example. Adam

[bitcoin-dev] Bitcoin dev list bounce

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Warren, I submitted a public apology for a false accusation I leveled at Sergio Lerner but my message was bounced by the list. Can you please confirm if there is a know reason for this. I had also sent the message to his personal email account,

Re: [bitcoin-dev] Proposed new policy for transactions that depend on other unconfirmed transactions

There is a PR up for this change at https://github.com/bitcoin/bitcoin/pull/6771, which is getting some discussion for those following along. On October 5, 2015 1:02:40 PM PDT, Alex Morcos via bitcoin-dev wrote: >Yes, total number of dependent

[bitcoin-dev] extension-blocks/sidechains & fractional/coin-cap/demurrage (Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!)

Micha I think you are correct, I dont think extension blocks (or sidechains for that matter) can allow soft-fork increase of the total Bitcoins in the system, because the main chain still enforces the 21m coin cap. A given extension block could go fractional, but if there was a run to get out,

Re: [bitcoin-dev] extension-blocks/sidechains & fractional/coin-cap/demurrage (Re: Let's deploy BIP65 CHECKLOCKTIMEVERIFY!)

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Exactly, In the coming fee market crunch, any speculator would trade an extended block in the implied direction and also hedge in the opposite direction in case it gets rejected. The speculative public will most likely trade in the same direction,

Re: [bitcoin-dev] Public Debate Challenge

>Unfortunately, one moral imbecile keeps polluting this space. Indeed. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] on rough consensus

Thank you for posting that, most informative, and suggest people arguing here lately to read it carefully. May I suggest that people who wish to debate what rough consensus means, to take it to this reddit thread

Re: [bitcoin-dev] Public Debate Challenge

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Sure, and I share your view - I want to know what is happening in the Bitcoin development space when I scan this email account. Unfortunately, one moral imbecile keeps polluting this space. I am confident that I have the debating resources and

[bitcoin-dev] Public Debate Challenge

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Hearn, I challenge you to a public debate with the following conditions: - - the topic is Bitcoin - - 15 minutes in length (19mins including breaks) - - 3 sessions of 5 minutes each - - each speaker makes one statement in each session, not

Re: [bitcoin-dev] Public Debate Challenge

On Wed, Oct 07, 2015 at 05:19:29PM +0700, Venzen Khaosan via bitcoin-dev wrote: > Mike Hearn, > > I challenge you to a public debate with the following conditions: This is very off-topic for a development mailing list. Go away. -- 'peter'[:-1]@petertodd.org

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Tue, Sep 29, 2015 at 06:31:28PM +, Gregory Maxwell via bitcoin-dev wrote: > On Mon, Sep 28, 2015 at 10:48 AM, Mike Hearn via bitcoin-dev > wrote: > > There is no consensus on using a soft fork to deploy this feature. It will > > result in the same

[bitcoin-dev] The new obfuscation patch & GetStats

Hi! I hope this is not a stupid question, but I thought I'd ask here first instead of opening a Github ticket (in case I'm wrong). With the recently merged "obfuscation" patch, content of the "chainstate" LevelDB is obfuscated by XOR'ing against a random "key". This is handled by

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev wrote: > *But* a soft fork that only forbids transactions that would previously > not have been mined anyway should be the best of both worlds, as it > automatically reduces the liklihood of old

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Oct 7, 2015, at 9:02 AM, Eric Lombrozo wrote: > But a real hashpower supermajority would make such attacks hard to pull off > in practice. If you had a 99% hashpower supermajority on the new version, an attacker would still be able to perform this attack once per

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

You're right about the potential for 1 bad confirmation even with very low frequency...but with an overwhelming supermajority of hashpower, 2 bad confirmations become quite unlikely, n bad confirmations becomes exponentially unlikely in n. As part of such soft fork deployments, it's true that

Re: [bitcoin-dev] Public Debate Challenge

On Wed, Oct 7, 2015 at 8:59 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Wed, Oct 07, 2015 at 05:19:29PM +0700, Venzen Khaosan via bitcoin-dev > wrote: > > Mike Hearn, > > > > I challenge you to a public debate with the following conditions: > > This is very

Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

On Wed, Oct 07, 2015 at 08:46:08AM -0700, Jonathan Toomim (Toomim Bros) via bitcoin-dev wrote: > On Oct 7, 2015, at 8:00 AM, Anthony Towns via bitcoin-dev > wrote: > > *But* a soft fork that only forbids transactions that would previously > > not have been