--- Original Message ---
On Tuesday, November 8th, 2022 at 3:49 PM, Erik Aronesty wrote:
>> I think it's pretty clear that the "competitive nature of PoW" is not
>> referring to verification nodes
>
> cool, so we can agree there is no accepted centralization pressure for
> validating
--- Original Message ---
On Tuesday, November 8th, 2022 at 2:16 PM, Erik Aronesty wrote:
>> A) to not increase the workload of full-nodes
>
> yes, this is critical
>
>> given the competitive nature of PoW itself
>
> validating nodes do not compete with PoW, i think maybe you are not sure
> I think it's pretty clear that the "competitive nature of PoW" is not
referring to verification nodes
cool, so we can agree there is no accepted centralization pressure for
validating nodes then
> layers also add fees to users
source? i feel like it's obvious that the tree-like efficiencies
> A) to not increase the workload of full-nodes
yes, this is critical
> given the competitive nature of PoW itself
validating nodes do not compete with PoW, i think maybe you are not sure of
the difference between a miner and a node
nodes do validation of transactions, they do this for free,
--- Original Message ---
On Wednesday, October 19th, 2022 at 2:40 PM, angus wrote:
>> 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
--- Original Message ---
On Wednesday, October 19th, 2022 at 10:34 PM, G. Andrew Stone
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.
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.
You might quickly respond with a modification that changes or eliminates
the brick coinbase reward, but perhaps that
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
> 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
Hi,
On Wed, Oct 19, 2022 at 6:34 AM mm-studios via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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.
>
Check out the previous
> 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
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
12 matches
Mail list logo
