This topic is straying from Bitcoin development into general Bitcoin
governance, policy, or other meta-issues.
We have now the new bitcoin-discuss mailing list now, specifically for
these more free-flowing topics:
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss
Please take fur
Hi Greg,
>> Thank you for conceding on that point.
>
> You're welcome, but I would have preferred that you instead of your
> thanks you would have responded in kind and acknowledged my correction
> that other consensus inconsistencies discovered in implementations
> thus far (none, that I'm aware
On Sun, Nov 15, 2015 at 2:58 AM, Peter R wrote:
> I think you’re being intentionally obtuse here: accepting a block composed
> entirely of valid transactions that is 1.1 MB is entirely different than
> accepting a TX that creates a ten thousand bitcoins out of thin air. The
> market would love
> On Sunday, November 15, 2015 1:02:33 AM Peter R via bitcoin-dev wrote:
>> A group of us have been exploring this “meta-cognition” idea with Bitcoin
>> Unlimited. For example, Bitcoin Unlimited can be (optionally) made to
>> automatically fork to the longest chain if it “gets stuck” and can neit
On Sunday, November 15, 2015 1:02:33 AM Peter R via bitcoin-dev wrote:
> A group of us have been exploring this “meta-cognition” idea with Bitcoin
> Unlimited. For example, Bitcoin Unlimited can be (optionally) made to
> automatically fork to the longest chain if it “gets stuck” and can neither
>
> On Nov 14, 2015, at 6:10 PM, Gregory Maxwell wrote:
>
> On Sun, Nov 15, 2015 at 1:45 AM, Peter R wrote:
>> My previous email described how Type 1 consensus failures can be safely
>> dealt with. These include many kinds of database exceptions (e.g., the
>> LevelDB fork at block #225,430), o
Hi!
To anyone that followed the discussion (from some time ago) about the
proposed new URI for Blockchain references / exploration, I just wanted to
point out that I have collected the feedback provided, reworked the text,
put the BIP on GitHub and created a pull request:
https://github.com/Marco
On Sun, Nov 15, 2015 at 1:45 AM, Peter R wrote:
> My previous email described how Type 1 consensus failures can be safely dealt
> with. These include many kinds of database exceptions (e.g., the LevelDB
> fork at block #225,430), or consensus mismatches regarding the max size of a
> block.
Th
> On Nov 14, 2015, at 5:08 PM, Gregory Maxwell wrote:
>
> On Sun, Nov 15, 2015 at 1:02 AM, Peter R wrote:
>> Hi Greg,
>>
>> Like you said, the issue with using more than one database technology is not
>> that one node would prove that Block X is valid while the another node
>> proves that Bl
On Sun, Nov 15, 2015 at 1:02 AM, Peter R wrote:
> Hi Greg,
>
> Like you said, the issue with using more than one database technology is not
> that one node would prove that Block X is valid while the another node proves
> that Block X is NOT valid. Instead, the problem is that one node might sa
Hi Greg,
Like you said, the issue with using more than one database technology is not
that one node would prove that Block X is valid while the another node proves
that Block X is NOT valid. Instead, the problem is that one node might say
“valid” while the other node says “I don’t know.”
It i
I'd like to use service bit 28 for testing the block compression
prototype unless anyone has any objections or is using it already.
Thanks.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listi
On Friday, November 13, 2015 06:58:07 PM Jeff Garzik wrote:
> On Fri, Nov 13, 2015 at 4:48 PM, xor via bitcoin-dev <
>
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > This clearly says that funds can be frozen.
> > Can the BIP65-thing be used to freeze funds or can it not be?
>
> This languag
> It looks like some specific meta-level criteria would help more at this point
> than new proposals all exploring a different variants of block size increase
> schedules.
I agree. In fact, I’ll go meta on your meta and suggest that we should first
discuss how Bitcoin should be governed in the
On Saturday, November 14, 2015 9:15:07 PM Angel Leon wrote:
> "the economy does not necessarily include miners"
> so the money supply isn't part of the economy?
Not in the context of economic majority deciding hardforks. After all, the
outcome of the hardfork *determines* the money supply. So the
On Saturday, November 14, 2015 10:52:12 AM Jorge Timón via bitcoin-dev wrote:
> Currently bip99 recommends 95% miner upgrade confirmation with version bits
> (bip9) for uncontroversial hardforks just like it does for uncontroversial
> softforks. It is true that in the case of hardforks miners don't
> Date: Fri, 13 Nov 2015 11:37:51 -0500
> From: Emin G?n Sirer
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] How to evaluate block size increase
> suggestions.
> Message-ID:
>
> Content-Type: text/plain; charset="utf-8"
>
> By now, we have seen quite a few prop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I've seen two different BIP103's and choose to not write about it
because risk of ambiguity. One of them are proposing a linear growth and
the other one is proposing an exponential growth. The all-linear growth
is an option that will not work well in
I agree with the usefulness of at least trying to define a formal set
of criteria.
I'm afraid that with proposals that schedule future increases to the
blocksize consensus maximum or leave it for miners to decide (like
BIP100, BIP101 and BIP103) cannot be evaluated without making
assumptions about
Currently bip99 recommends 95% miner upgrade confirmation with version bits
(bip9) for uncontroversial hardforks just like it does for uncontroversial
softforks. It is true that in the case of hardforks miners don't decide and
it's the whole economy who has to upgrade before activation, but "the wh
There is a difference between miners signalling intent (as they have
been for various BIPs, which is mostly informational only - they are
mostly not running the code, and in some cases it is not implemented,
so they cant be) there is a difference between that and a 95% miner
majority consensus rule
Well I'd like to think that with an economy all parts of it interact with each
other in ways more complex than simplistic imperative logic.
I agree that the economic majority is essentially what matters in a hard fork
but everyone (miners,devs,public thought leaders,businesses) is part of th
I believe in the end it's the usability of bitcoin that matters.
For instance, a goal could be that no user on the network should wait more
than an hour to get 3 confirmations on the blockchain so that they can
actually have useful Bitcoins.
We can debate all we want about lots of technical aspec
On Friday, November 13, 2015 09:53:57 PM Gregory Maxwell wrote:
> The first text is explaining nlocktime without BIP65 in order to
> explain the reason for having BIP65.
Thanks. I would recommend changing the BIP65 to clarify what you just said,
this clearly is the missing piece of information th
24 matches
Mail list logo
