public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Bdimych Bdimych <bdimych@gmail.com>
To: "Jorge Timón" <jtimon@jtimon.cc>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Block size possible solution - to set minimum size
Date: Sun, 23 Aug 2015 09:04:27 -0500	[thread overview]
Message-ID: <CALNn0ZYDw+f1j+7PydnAaDqx+sP93EAxQDccisM1+R2UJc7Pog@mail.gmail.com> (raw)
In-Reply-To: <CABm2gDp2TONJxSVSdS7bq-WAXNVfQGZiKyhx2haerA3WkoaNxQ@mail.gmail.com>

I apologize, I'm not familiar with technical details, may be stupid,
only general thoughts:
-overlapped block sizes - two blockchains, uncertainty, unpredictable
results, trust gets down
-non-overlapped - single blockchain, determined growing, everybody
knows the schedule what and when will happen

---

You wrote "cheated",
but why?
If it will be possible to fill with zeroes
[transactions]+[zeroes]
or
[transactions]+[miner's dummy transactions]
why the second variant will be better for miner?
and why it will be not good for other users?


With Best Regards
Dmitry Bolshakov
bdimych@gmail.com


On Sun, Aug 23, 2015 at 1:40 AM, Jorge Timón <jtimon@jtimon.cc> wrote:
> A minimum block size does nothing to prevent the problems that come
> from schism hardforks.
> But also a minimum block size can be trivially cheated as recently
> explained on this list:
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010317.html
>
> "[...] miners can just pay to themselves to follow the minimum size
> block rule without risking anything.
> As long as they have a single matured satoshi they can just pay to
> themselves with it as many times as they need in the same block."
>
> It is good to search previous post before proposing or asking
> something (it could have been proposed/asked earlier):
>
> http://www.catb.org/esr/faqs/smart-questions.html
>
>
> On Sun, Aug 23, 2015 at 1:30 AM, Bdimych Bdimych via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>> Hi,
>> As I understand the main problem of the fork Core<->XT is possibility
>> of double spending:
>> -I run XT and spend my coins
>> -it is written in 8mb block
>> -Core does not accept this block
>> -I run Core and spend my coins again
>> -it is written in 1mb block
>> -but XT accepts this block too
>> so
>> -in the XT blockchain both blocks [8] and [1] contain my coins
>>
>> I thought that possible solution can be to set minimum block size
>> i.e.
>> 2016: 1mb <= blockSize < 2mb
>> 2017: 2mb <= blockSize < 3mb
>> 2018: 3mb <= blockSize < 4mb
>> etc
>>
>> Free space could be filled with zeroes and compressed.
>>
>> That's all, just an idea.
>>
>>
>> With Best Regards
>> Dmitry Bolshakov
>> bdimych@gmail.com
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


      reply	other threads:[~2015-08-23 14:04 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-22 23:30 [bitcoin-dev] Block size possible solution - to set minimum size Bdimych Bdimych
2015-08-23  6:40 ` Jorge Timón
2015-08-23 14:04   ` Bdimych Bdimych [this message]

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=CALNn0ZYDw+f1j+7PydnAaDqx+sP93EAxQDccisM1+R2UJc7Pog@mail.gmail.com \
    --to=bdimych@gmail.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=jtimon@jtimon.cc \
    /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