Our comment was posted to Github:
https://github.com/bitcoin/bitcoin/pull/6771#issuecomment-146429708
We, at Serica and DigitalTangible actively use unspent tx chains to allow
our customers to speed their bitcoin user-experience without the need for
them to wait on blockchain confirmations. These
Hi James!
On 2015-10-08 02:29, James O'Beirne wrote:
> This has been confirmed as a bug. Thanks again for reporting. I've filed
> a fix here (https://github.com/bitcoin/bitcoin/pull/6777), and will be
> writing tests to prevent regressions.
Thanks for the quick fix!
I thought to submit a patch m
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 transactions regardless of chain depth.
>
>A desce
This has been confirmed as a bug. Thanks again for reporting. I've filed a
fix here (https://github.com/bitcoin/bitcoin/pull/6777), and will be
writing tests to prevent regressions.
On Wed, Oct 7, 2015 at 4:32 PM, James O'Beirne
wrote:
> Hey, Daniel.
>
> Patch author here. Thanks for the diligen
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 is
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 perform this attack once per day.
[ie wait for a non-upgraded mi
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 CLevelDBWrapper'
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 mined anyway should be the best of both
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 day. Since the attacker i
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 o
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
That's why it's important to measure miner adoptance. Note that this isn't a
vote - it's an adoption metric for what is presumably a fairly uncontroversial
upgrade. If there's contentious controversy amongst miner all bets are off.
Our current mechanisms are imperfect in this regard...as we've s
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 miners building newly invalid
> blocks to
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 problems as all the other soft forks - SPV
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
10734953ce486a820b6f
>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
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
https://www.reddit.com/r/Bitcoin/comments/3ntga9/bitcoindev_a_brilliant_post_on_defi
-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 mental
-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 excee
-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,
in
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, the
-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, b
22 matches
Mail list logo
