public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Matthew Mitchell <matthewmitchell@godofgod•co.uk>
To: Mike Hearn <mike@plan99•net>,
	Gregory Maxwell <gmaxwell@gmail•com>,
	"bitcoin-development@lists•sourceforge.net"
	<bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Segmented Block Relaying BIP draft.
Date: Thu, 13 Sep 2012 15:05:29 +0100	[thread overview]
Message-ID: <FC0AF926-2CBD-49BA-A3B7-AF9D70A83CE4@godofgod.co.uk> (raw)
In-Reply-To: <CANEZrP0HHhSXyN9pWODtTxHMfRB4B0w-eSdvNHH13WwLVgECrw@mail.gmail.com>

On 13 Sep 2012, at 09:42, Mike Hearn <mike@plan99•net> wrote:

> For what it's worth I disagree with Gregory on nearly all these
> points, so don't take it as some kind of consensus from the Bitcoin
> community ;)
> 
> Matts change is reasonable but I think we all agree it has minimal
> impact at the moment relative to other things, so something even more
> complex than that seems like a non-starter. Bloom filtering is a lot
> more important.

Sure other things may be done before this, I was seeing this as a change somewhere down the line but not urgent.

@Gregory

> But you only need to request the transactions you don't have. Most of
> time you should already have almost all of the transactions.

Yes, my proposal allows you to do this. You skip out transactions your already have. My proposal is simply better than others because it takes full advantage of the merkle tree structure with minor additions that are simple to implement. How hard is it to get the hashes at a particular level of a merkle tree? Not hard at all. How hard is it to place a selection of transactions from a block into a message Not hard at all. Implementation of the protocol requirements would be a piece of cake. The harder bit would be to create an algorithm to determine the best level of segmentation but this is not required to comply with the protocol.

> Because there is no motivation not to set them to zero, if you don't
> someone else will

The motivation to incentivise miners and maintain stronger security? The difficulty only has to be high enough to prevent a cartel of malicious miners taking control of the network, something that is potentially a problem today with the large mining pools. Remember that the more transactions there are the more fees there can be for miners to collect. The more people that are using bitcoin, the greater bitcoins will be worth. A bigger network should be good for miners when relying on fees.

> And yes, of course, you schedule the change
> for the future, but as you note that it doesn't solve the problem of
> people opposing it.

If it's so controversial that it creates a split making two separated currencies then I'd see it turning out like the format wars (VHS vs Betamax and Blu-ray vs HD-DVD). Eventually people will move towards one or the other since it's better for people to have universalised agreement on a system.


  reply	other threads:[~2012-09-13 14:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-11 19:07 Matthew Mitchell
2012-09-11 19:42 ` Gregory Maxwell
2012-09-11 21:48   ` Matthew Mitchell
2012-09-11 23:22     ` Gregory Maxwell
2012-09-13  8:42       ` Mike Hearn
2012-09-13 14:05         ` Matthew Mitchell [this message]
2012-09-13 15:16           ` Gregory Maxwell
     [not found]             ` <2B95CF41-4304-4D2A-9ABF-198D97B7449B@godofgod.co.uk>
2012-09-13 15:46               ` Matthew Mitchell
     [not found]               ` <CAAS2fgQi8QFwU2M=wLiDodt3SmO48vUV5Sp3YCb1OmGJ5m=E7Q@mail.gmail.com>
2012-09-13 17:49                 ` Matthew Mitchell
2012-09-13 18:59                   ` Pieter Wuille
2012-09-13 20:24                     ` Matthew Mitchell
  -- strict thread matches above, loose matches on Subject: below --
2012-09-10 15:07 Matthew Mitchell
2012-09-10 15:14 ` Gregory Maxwell
2012-09-10 16:29   ` Matt Corallo
2012-09-10 18:59 ` Luke-Jr
2012-09-10 19:34   ` Matthew Mitchell
2012-09-10 19:53     ` Matt Corallo
2012-09-10 20:00       ` Gregory Maxwell

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=FC0AF926-2CBD-49BA-A3B7-AF9D70A83CE4@godofgod.co.uk \
    --to=matthewmitchell@godofgod$(echo .)co.uk \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=gmaxwell@gmail$(echo .)com \
    --cc=mike@plan99$(echo .)net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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