* [bitcoin-dev] Block size possible solution - to set minimum size @ 2015-08-22 23:30 Bdimych Bdimych 2015-08-23 6:40 ` Jorge Timón 0 siblings, 1 reply; 3+ messages in thread From: Bdimych Bdimych @ 2015-08-22 23:30 UTC (permalink / raw) To: bitcoin-dev 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Block size possible solution - to set minimum size 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 0 siblings, 1 reply; 3+ messages in thread From: Jorge Timón @ 2015-08-23 6:40 UTC (permalink / raw) To: Bdimych Bdimych; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [bitcoin-dev] Block size possible solution - to set minimum size 2015-08-23 6:40 ` Jorge Timón @ 2015-08-23 14:04 ` Bdimych Bdimych 0 siblings, 0 replies; 3+ messages in thread From: Bdimych Bdimych @ 2015-08-23 14:04 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Dev 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2015-08-23 14:04 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 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 is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox