public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: "Jorge Timón" <jtimon@jtimon.cc>
To: Peter R <peter_r@gmx.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>,
	Gregory Maxwell <gmaxwell@gmail.com>,
	telemaco <telemaco@neomailbox.net>
Subject: Re: [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db
Date: Sun, 15 Nov 2015 11:12:22 +0100	[thread overview]
Message-ID: <CABm2gDrEymffZXRqkYij0eCR3Rg6x1w_=AUJpb3NxHwQ-q48aQ@mail.gmail.com> (raw)
In-Reply-To: <2C8EBBD8-51B7-4F47-AFFA-3870DBD6C4EA@gmx.com>

[-- Attachment #1: Type: text/plain, Size: 2124 bytes --]

On Nov 15, 2015 5:10 AM, "Peter R via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> What rules does Bitcoin obey?

Thanks to the worl of many people, part of the consensus rules are finally
encapsulated in the libbitcoinconsensus library. I'm currently writing a
document to complete the encapsulation of the specification of the
consensus rules.

> I am not convinced that Bitcoin even *has* a block size limit, let alone
that it can enforce one against the invisible hand of the market.

You keep insisting that some consensus rules are not consensus rules while
others "are clearly a very different thing". What technical difference is
there between the rule that impedes me from creating transactions bigger
than X and the rules that prevent me frm creatin new coins (not as a miner,
as a regular user in a transaction with more coins in the outputs than in
the inputs)? What about property enforcement? If the invisible hand of the
market is what decides consensus rules instead of their (still incomple)
specification (aka libconsensus), then the market could decide to stop
enforcing ownership.
Will you still think that Bitcoin is a useful system when/if you
empirically observe the invisible hand of the market taking coins out of
your pocket?

You also keep assuming that somehow it is a universal law that users must
eventually converge under the most-work chain. People follow the most-work
VALID chain, but if they consciously decide to implement different rules
(different definitions of "valid block") then their chains can diverge, and
once they do they won't converge again (unless/until one group decides to
implement the rules of the other exactly again), just like when the
implementation of the rules diverge in a unintentional consensus fork. But
in this case they could decide to never implement the same rules.
See bip99 and specially the "schism hardforks" section for more details.

> You were the one who just brought up politics, Greg.  Not I.

Please, read the thread again. I think it is pretty clear that you did.
Nothing wrong with that, just move it to the discussion ml.

[-- Attachment #2: Type: text/html, Size: 2397 bytes --]

  reply	other threads:[~2015-11-15 10:12 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-29  6:57 [bitcoin-dev] [patch] Switching Bitcoin Core to sqlite db telemaco
2015-10-29  8:03 ` Luke Dashjr
2015-10-30  3:04   ` Simon Liu
2015-10-30  3:35     ` Gregory Maxwell
2015-10-30  4:04       ` Peter R
2015-10-30  4:28         ` Gregory Maxwell
2015-11-15  1:02           ` Peter R
2015-11-15  1:08             ` Gregory Maxwell
2015-11-15  1:45               ` Peter R
2015-11-15  2:10                 ` Gregory Maxwell
2015-11-15  2:58                   ` Peter R
2015-11-15  3:30                     ` Gregory Maxwell
2015-11-15  4:10                       ` Peter R
2015-11-15 10:12                         ` Jorge Timón [this message]
2015-11-15 11:28                           ` Jorge Timón
2015-11-15 15:48                             ` Peter R
2015-11-15 17:06                           ` Peter R
2015-11-17 13:54                             ` Tamas Blummer
2015-11-17 15:24                               ` Tom Harding
2015-11-17 22:17                                 ` telemaco
2015-11-20 14:15                                   ` Jorge Timón
2015-11-16  1:52                     ` Rusty Russell
2015-11-15  3:04             ` Luke Dashjr
2015-11-15  3:17               ` Peter R
2015-10-29  8:17 ` Gregory Maxwell
  -- strict thread matches above, loose matches on Subject: below --
2015-10-22 21:26 Jeff Garzik
2015-10-22 21:54 ` Patrick Strateman
2015-10-22 21:56 ` Joseph Gleason ⑈
2015-10-23  6:53 ` Jonas Schnelli
2015-10-23  7:45 ` Lucas Betschart
2015-10-28 20:28   ` Sean Lynch
2015-10-28 21:11     ` Jeff Garzik
2015-10-23 10:30 ` Tom Zander
2015-10-26 18:06   ` Douglas Roark
2015-10-28 15:52     ` Tom Zander
2015-11-18  0:06     ` Jonathan Wilkins

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABm2gDrEymffZXRqkYij0eCR3Rg6x1w_=AUJpb3NxHwQ-q48aQ@mail.gmail.com' \
    --to=jtimon@jtimon.cc \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=gmaxwell@gmail.com \
    --cc=peter_r@gmx.com \
    --cc=telemaco@neomailbox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox