* [bitcoin-dev] A possible solution for the block size limit: Detection and rejection of bloated blocks by full nodes.
@ 2015-06-30 23:41 Peter Grigor
2015-06-30 23:43 ` Luke Dashjr
2015-06-30 23:45 ` Pieter Wuille
0 siblings, 2 replies; 4+ messages in thread
From: Peter Grigor @ 2015-06-30 23:41 UTC (permalink / raw)
To: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1170 bytes --]
The block size debate centers around one concern it seems. To wit: if block
size is increased malicious miners may publish unreasonably large "bloated"
blocks. The way a miner would do this is to generate a plethora of private,
non-propagated transactions and include these in the block they solve.
It seems to me that these bloated blocks could easily be detected by other
miners and full nodes: they will contain a very high percentage of
transactions that aren't found in the nodes' own memory pools. This
signature can be exploited to allow nodes to reject these bloated blocks.
The key here is that any malicious miner that publishes a block that is
bloated with his own transactions would contain a ridiculous number of
transactions that *absolutely no other full node has in its mempool*.
Simply put, a threshold would be set by nodes on the allowable number of
non-mempool transactions allowed in a solved block (say, maybe, 50% -- I
really don't know what it should be). If a block is published which
contains more that this threshold of non-mempool transactions then it is
rejected.
If this idea works the block size limitation could be completely removed.
[-- Attachment #2: Type: text/html, Size: 1556 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] A possible solution for the block size limit: Detection and rejection of bloated blocks by full nodes.
2015-06-30 23:41 [bitcoin-dev] A possible solution for the block size limit: Detection and rejection of bloated blocks by full nodes Peter Grigor
@ 2015-06-30 23:43 ` Luke Dashjr
2015-06-30 23:45 ` Pieter Wuille
1 sibling, 0 replies; 4+ messages in thread
From: Luke Dashjr @ 2015-06-30 23:43 UTC (permalink / raw)
To: bitcoin-dev
On Tuesday, June 30, 2015 11:41:29 PM Peter Grigor wrote:
> The block size debate centers around one concern it seems. To wit: if block
> size is increased malicious miners may publish unreasonably large "bloated"
> blocks. The way a miner would do this is to generate a plethora of private,
> non-propagated transactions and include these in the block they solve.
>
> It seems to me that these bloated blocks could easily be detected by other
> miners and full nodes: they will contain a very high percentage of
> transactions that aren't found in the nodes' own memory pools. This
> signature can be exploited to allow nodes to reject these bloated blocks.
> The key here is that any malicious miner that publishes a block that is
> bloated with his own transactions would contain a ridiculous number of
> transactions that *absolutely no other full node has in its mempool*.
>
> Simply put, a threshold would be set by nodes on the allowable number of
> non-mempool transactions allowed in a solved block (say, maybe, 50% -- I
> really don't know what it should be). If a block is published which
> contains more that this threshold of non-mempool transactions then it is
> rejected.
>
> If this idea works the block size limitation could be completely removed.
This is easily defeated simply by broadcasting the bloat beforehand...
Luke
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] A possible solution for the block size limit: Detection and rejection of bloated blocks by full nodes.
2015-06-30 23:41 [bitcoin-dev] A possible solution for the block size limit: Detection and rejection of bloated blocks by full nodes Peter Grigor
2015-06-30 23:43 ` Luke Dashjr
@ 2015-06-30 23:45 ` Pieter Wuille
2015-07-01 2:52 ` Jeremy
1 sibling, 1 reply; 4+ messages in thread
From: Pieter Wuille @ 2015-06-30 23:45 UTC (permalink / raw)
To: Peter Grigor; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 1977 bytes --]
The problem with this approach is that you need 100% exact behaviour for
every node on the network in their decision to reject a particular block.
So we need a 100% mempool synchronization across all nodes - otherwise just
an attempted double spend could result in a fork in the network because
some nodes saw it and some didn't. And actually, if we had 100% mempool
synchronization, we wouldn't need a blockchain in the first place, because
we could just use "first to enter mempool" as validity criterion.
On Wed, Jul 1, 2015 at 1:41 AM, Peter Grigor <peter@grigor•ws> wrote:
> The block size debate centers around one concern it seems. To wit: if
> block size is increased malicious miners may publish unreasonably large
> "bloated" blocks. The way a miner would do this is to generate a plethora
> of private, non-propagated transactions and include these in the block they
> solve.
>
> It seems to me that these bloated blocks could easily be detected by other
> miners and full nodes: they will contain a very high percentage of
> transactions that aren't found in the nodes' own memory pools. This
> signature can be exploited to allow nodes to reject these bloated blocks.
> The key here is that any malicious miner that publishes a block that is
> bloated with his own transactions would contain a ridiculous number of
> transactions that *absolutely no other full node has in its mempool*.
>
> Simply put, a threshold would be set by nodes on the allowable number of
> non-mempool transactions allowed in a solved block (say, maybe, 50% -- I
> really don't know what it should be). If a block is published which
> contains more that this threshold of non-mempool transactions then it is
> rejected.
>
> If this idea works the block size limitation could be completely removed.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 2819 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [bitcoin-dev] A possible solution for the block size limit: Detection and rejection of bloated blocks by full nodes.
2015-06-30 23:45 ` Pieter Wuille
@ 2015-07-01 2:52 ` Jeremy
0 siblings, 0 replies; 4+ messages in thread
From: Jeremy @ 2015-07-01 2:52 UTC (permalink / raw)
To: Pieter Wuille; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3148 bytes --]
A simple hack to achieve this would be phase shifting the transaction fees
by one block. There may be other problems, but also potential
benefits, with that though.
This hack works because then a miner would orphan a block which didn't
properly reward them, which makes it very costly for even a miner to put in
a bunch of transactions for free. This phase can be adjusted to different
amounts, spread over multiple blocks, or even randomly selected at the time
of mining from a pool of un-fee claimed blocks (although this would require
some seeding to create a pool of any size greater than 1).
Again, this is probably a bad idea and I haven't thought it through
completely, but just tossing it out there.
Ps sorry if you're seeing this many times I think it bounced due to the
not-subscribed rule (sent from my other account)
On Wednesday, July 1, 2015, Pieter Wuille <pieter.wuille@gmail•com> wrote:
> The problem with this approach is that you need 100% exact behaviour for
> every node on the network in their decision to reject a particular block.
> So we need a 100% mempool synchronization across all nodes - otherwise just
> an attempted double spend could result in a fork in the network because
> some nodes saw it and some didn't. And actually, if we had 100% mempool
> synchronization, we wouldn't need a blockchain in the first place, because
> we could just use "first to enter mempool" as validity criterion.
>
> On Wed, Jul 1, 2015 at 1:41 AM, Peter Grigor <peter@grigor•ws
> <javascript:_e(%7B%7D,'cvml','peter@grigor•ws');>> wrote:
>
>> The block size debate centers around one concern it seems. To wit: if
>> block size is increased malicious miners may publish unreasonably large
>> "bloated" blocks. The way a miner would do this is to generate a plethora
>> of private, non-propagated transactions and include these in the block they
>> solve.
>>
>> It seems to me that these bloated blocks could easily be detected by
>> other miners and full nodes: they will contain a very high percentage of
>> transactions that aren't found in the nodes' own memory pools. This
>> signature can be exploited to allow nodes to reject these bloated blocks.
>> The key here is that any malicious miner that publishes a block that is
>> bloated with his own transactions would contain a ridiculous number of
>> transactions that *absolutely no other full node has in its mempool*.
>>
>> Simply put, a threshold would be set by nodes on the allowable number of
>> non-mempool transactions allowed in a solved block (say, maybe, 50% -- I
>> really don't know what it should be). If a block is published which
>> contains more that this threshold of non-mempool transactions then it is
>> rejected.
>>
>> If this idea works the block size limitation could be completely removed.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> <javascript:_e(%7B%7D,'cvml','bitcoin-dev@lists•linuxfoundation.org');>
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>
--
--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
[-- Attachment #2: Type: text/html, Size: 5132 bytes --]
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2015-07-01 2:57 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-06-30 23:41 [bitcoin-dev] A possible solution for the block size limit: Detection and rejection of bloated blocks by full nodes Peter Grigor
2015-06-30 23:43 ` Luke Dashjr
2015-06-30 23:45 ` Pieter Wuille
2015-07-01 2:52 ` Jeremy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox