------- Original Message -------
On Wednesday, October 19th, 2022 at 10:34 PM, G. Andrew Stone
<g.andrew.st...@gmail.com> wrote:
> Consider that a miner can also produce transactions. So every miner would
> produce spam tx to fill their bricks at the minimum allowed difficulty to
> reap the brick coinbase reward.
except that, as I explained in a prev email, bricks don't contain reward. They
are meaningless unless they form a complete brickchain with an accumulated
difficulty that is equivalent to current block difficulty.
> You might quickly respond with a modification that changes or eliminates the
> brick coinbase reward, but perhaps that exact reward and the major negative
> consequence of miners creating spam tx needs careful thought.
since 1 block is equivalent to a brickchain, there exist only 1 coinbase tx
and since the brickchain is treated atomically as a whole, it follows the same
processing as a block.
The only observable difference (and the reason of augmentating throughput) in
the wire is that the information has been transmitted in streaming (decomposed
block spaced in time)
> See "bobtail" for a weak block proposal that produces a more consistent
> discovery time, and "tailstorm" for a proposal that uses the content of those
> weak blocks as commitment to what transactions miners are working on (which
> will allow more trustworthy (but still not foolproof) use of transactions
> before confirmation)... neither of which have a snowball's chance in hell
> (along with any other hard forking change) of being put into bitcoin :-).
thanks
Marcos
> Andrew
>
> On Wed, Oct 19, 2022 at 12:05 PM mm-studios via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Thanks all for your responses.
>> so is it a no-go is because "reduced settlement speed is a desirable
>> feature"?
>>
>> I don';t know what weights more in this consideration:
>> A) to not increase the workload of full-nodes, being "less difficult to
>> operate" and hence reduce the chance of some of them giving up which would
>> lead to a negative centralization effect. (a bit cumbersome reasoning in my
>> opinion, given the competitive nature of PoW itself, which introduce an
>> accepted centralization, forcing some miners to give up). In this case the
>> fact is accepted because is decentralized enough.
>> B) to not undermine L2 systems like LN.
>>
>> in any case it is a major no-go reason, if there is not intention to speed
>> up L1.
>> Thanks
>> M
>>
>> ------- Original Message -------
>> On Wednesday, October 19th, 2022 at 3:24 PM, Erik Aronesty <e...@q32.com>
>> wrote:
>>
>>>> currently, a miner produce blocks with a limited capacity of transactions
>>>> that ultimately limits the global settlement throughput to a reduced
>>>> number of tx/s.
>>>
>>> reduced settlement speed is a desirable feature and isn't something we need
>>> to fix
>>>
>>> the focus should be on layer 2 protocols that allow the ability to hold &
>>> transfer, uncommitted transactions as pools / joins, so that layer 1's
>>> decentralization and incentives can remain undisturbed
>>>
>>> protocols like mweb, for example
>>>
>>> On Wed, Oct 19, 2022 at 7:34 AM mm-studios via bitcoin-dev
>>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> Hi Bitcoin devs,
>>>> I'd like to share an idea of a method to increase throughput in the
>>>> bitcoin network.
>>>>
>>>> Currently, a miner produce blocks with a limited capacity of transactions
>>>> that ultimately limits the global settlement throughput to a reduced
>>>> number of tx/s.
>>>>
>>>> Big-blockers proposed the removal of limits but this didn't come with
>>>> undesirable effects that have been widely discussed and rejected.
>>>>
>>>> The main feature we wanted to preserve is 'small blocks', providing
>>>> 'better network effects' I won't focus on them.
>>>>
>>>> The problem with small blocks is that, once a block is filled
>>>> transactions, they are kept back in the mempool, waiting for their turn in
>>>> future blocks.
>>>>
>>>> The following changes in the protocol aim to let all transactions go in
>>>> the current block, while keeping the block size small. It requires changes
>>>> in the PoW algorithm.
>>>>
>>>> Currently, the PoW algorithm consists on finding a valid hash for the
>>>> block. Its validity is determined by comparing the numeric value of the
>>>> block hash with a protocol-defined value difficulty.
>>>>
>>>> Once a miner finds a nonce for the block that satisfies the condition the
>>>> new block becomes valid and can be propagated. All nodes would update
>>>> their blockchains with it. (assuming no conflict resolution (orphan
>>>> blocks, ...) for clarity).
>>>>
>>>> This process is meant to happen every 10 minutes in average.
>>>>
>>>> With this background information (we all already know) I go on to describe
>>>> the idea:
>>>>
>>>> Let's allow a miner to include transactions until the block is filled,
>>>> let's call this structure (coining a new term 'Brick'), B0. [brick=block
>>>> that doesn't meet the difficulty rule and is filled of tx to its full
>>>> capacity]
>>>> Since PoW hashing is continuously active, Brick B0 would have a nonce
>>>> corresponding to a minimum numeric value of its hash found until it got
>>>> filled.
>>>>
>>>> Fully filled brick B0, with a hash that doesn't meet the difficulty rule,
>>>> would be broadcasted and nodes would have it on in a separate fork as
>>>> usual.
>>>>
>>>> At this point, instead of discarding transactions, our miner would start
>>>> working on a new brick B1, linked with B0 as usual.
>>>>
>>>> Nodes would allow incoming regular blocks and bricks with hashes that
>>>> don't satisfy the difficulty rule, provided the brick is fully filled of
>>>> transactions. Bricks not fully filled would be rejected as invalid to
>>>> prevent spam (except if constitutes the last brick of a brickchain,
>>>> explained below).
>>>>
>>>> Let's assume that 10 minutes have elapsed and our miner is in a state
>>>> where N bricks have been produced and the accumulated PoW calculated using
>>>> mathematics (every brick contains a 'minimum hash found', when a series of
>>>> 'minimum hashes' is computationally equivalent to the network difficulty
>>>> is then the full 'brickchain' is valid as a Block.
>>>>
>>>> This calculus shall be better defined, but I hope that this idea can serve
>>>> as a seed to a BIP, or otherwise deemed absurd, which might be possible
>>>> and I'd be delighted to discover why a scheme like this wouldn't work.
>>>>
>>>> If it finally worked, it could completely flush mempools, keep
>>>> transactions fees low and increase throughput without an increase in the
>>>> block size that would raise other concerns related to propagation.
>>>>
>>>> Thank you.
>>>> I look forward to your responses.
>>>>
>>>> --
>>>> Marcos Mayorgahttps://twitter.com/KatlasC
>>>>
>>>> _______________________________________________
>>>> bitcoin-dev mailing list
>>>> bitcoin-dev@lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
