<unnamed>

Public Key

npub14gv4tc4w0zkzyrfa5u2gvsajqlf3cgevux3xth46ukfrnqlcl8xqru4vq6

Profile Code

nprofile1qqs25x24u2h83tpzp576w9yxgweq05cuyvkwrgn9m6awty3es0u0nnqprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvlptpvj

Publishing to

relay.snort.social

Last Notes

2023-06-07 17:34:47 UTC

- reply

📅 Original date posted:2015-08-13
📝 Original message:A concern I have is about security (hash rate) as a function of block size.
I am assuming that hash rate is correlated with revenue from mining.
Total revenue from fees as a function of block size should be a curve. On
one extreme of the curve, if blocks are too big, fee revenue tends towards
0 as there is no competition for block space. At the other extreme, if
blocks are too small, fee revenue is limited only to what the most valuable
use case(s) can afford. Somewhere in the middle there should be a sweet
spot where fee revenue is maximised. It's not a static curve though, it
should change as demand for block space changes.
Failing to scale the block size as demand grows might be forfeiting
potential miner revenue and hence security.
(I don't think that should be a primary concern though since
decentralisation should come first, but I'm just pointing it out as a
secondary concern).
On Wed, Aug 12, 2015 at 7:59 PM, Jorge Timón <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> I believe all concerns I've read can be classified in the following groups:
>
> > 1) Potential indirect consequence of rising fees.
>
> - Lowest fee transactions (currently free transactions) will become
> more unreliable.
> - People will migrate to competing systems (PoW altcoins) with lower fees.
>
> > 2) Software problem independent of a concrete block size that needs to
> > be solved anyway, often specific to Bitcoin Core (ie other
> > implementations, say libbitcoin may not necessarily share these
> > problems).
>
> - Bitcoin Core's mempool is unbounded in size and can make the program
> crash by using too much memory.
> - There's no good way to increase the fee of a transaction that is
> taking too long to be mined without the "double spending" transaction
> with the higher fee being blocked by most nodes which follow Bitcoin
> Core's default policy for conflicting spends replacements (aka "first
> seen" replacement policy).
>
> I have started with the 3 concerns that I read more often, but please
> suggest more concerns for these categories and suggest other
> categories if you think there's more.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150813/fc22e19a/attachment.html>

2023-06-07 15:46:42 UTC

- reply

2023-06-07 15:37:37 UTC

- reply

📅 Original date posted:2015-06-14
📝 Original message:Economic policy sounds like a dirty word in the context of Bitcoin, but as
Jeff Garzik said, choosing a block size cap is unfortunately an economic
policy that has to be chosen somehow. Enabling users to incentivise the
voting process is an interesting tool to have in the toolbox, but I think
it would be sensible to first observe how the miner-only voting system
behaves on its own.
If, for example, the hashing majority tended to favour a move towards
centralization (big blocks), user preferences could potentially hasten this
move by further punishing marginal miners through reduced fees. On the
other hand, if user preferences tended to oppose the preferences of miners,
then such a system might function well in keeping a balance between
usability and security (although it's not clear how this balance might
change over time as the block subsidy drops).
In short, I think it's wise to keep it simple and implement one mechanism
at a time.
On Sat, Jun 13, 2015 at 4:11 AM, Peter Todd <pete at petertodd.org> wrote:
> Jeff Garzik recently proposed that the upper blocksize limit be removed
> entirely, with a "soft" limit being enforced via miner vote, recorded by
> hashing power.
>
> This mechanism within the protocol for users to have any influence over
> the miner vote. We can add that back by providing a way for transactions
> themselves to set a flag determining whether or not they can be included
> in a block casting a specific vote.
>
> We can simplify Garzik's vote to say that one of the nVersion bits
> either votes for the blocksize to be increased, or decreased, by some
> fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
> nVersion bit in transactions themselves, also voting for an increase or
> decrease. Transactions may only be included in blocks with an
> indentical vote, thus providing miners with a monetary incentive via
> fees to vote according to user wishes.
>
> Of course, to cast a "don't care" vote we can either define an
> additional bit, or sign the transaction with both versions. Equally we
> can even have different versions with different fees, broadcast via a
> mechanism such as replace-by-fee.
>
>
> See also John Dillon's proposal for proof-of-stake blocksize voting:
>
>
> https://www.mail-archive.com/[email protected]/msg02323.html
>
> --
> 'peter'[:-1]@petertodd.org
> 0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
>
>
> ------------------------------------------------------------------------------
>
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150614/253e3f4d/attachment.html>

2023-06-07 15:22:03 UTC

- reply

📅 Original date posted:2014-05-24
📝 Original message:On Sat, May 24, 2014 at 1:27 PM, Ashley Holman <dscvlt at gmail.com> wrote:
>
> * Skip the inv/getdata sequence for new blocks - just push them out
> directly to save 1 roundtrip per hop
>
Upon further reflection, I remove this from my proposal. It's an unrelated
optimisation that probably distracts from the main point which is the
cut-through forwarding. The rest of the proposal still works if the
inv/getdata sequence is retained.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140524/ae751af3/attachment.html>

2023-06-07 15:22:03 UTC

- reply

📅 Original date posted:2014-05-24
📝 Original message:Hi,
On this list there has been some discussion around techniques to speed up
block propagation, with a particular focus on reducing the extra orphan
risk carried by larger blocks.
The current store-and-forward method means that larger blocks will
propagate with higher latency. One proposed solution has been to broadcast
two separate messages: a fast, fixed-size header message, and a 2nd, slower
body message containing the full block. Whilst this allows larger blocks
to compete equally with smaller blocks on the "which came first" rule, it
creates a new area of uncertain delay between receiving the header, and
receiving the body, where there may be perverse incentives to mine empty
blocks on top of not-yet-valid headers.
So I would like to propose another method which is hopefully a less
significant change to the existing protocol rules, but should help reduce
the latency gap between large and small blocks.
* Skip the inv/getdata sequence for new blocks - just push them out
directly to save 1 roundtrip per hop
* When receiving a new block from a peer, as soon as we have the first 80
bytes (header) we can validate the PoW and, with only a low-level change to
the networking code, begin streaming that block to our peers (in the style
of cut-through switching).
* No other rules need to change. Block primacy can still be determined as
of the moment they are fully validated and accepted, but now the latency
caused by larger blocks is only (1 * BlockSize * BottleneckHopSpeed),
instead of (Sum[n=0 to NumHops](BlockSize * NodeBandwidth(n))).
* As far as I can tell, this shouldn't change any game theory or incentives
because nodes still receive blocks exactly as they do now, just sooner.
The difference is, invalid blocks that meet the PoW will be broadcast to
everyone, but this is nothing new since someone can peer with you and send
you an invalid block already. Network DoS should not be a possibility
since it is very expensive to make invalid blocks that meet network PoW.
Thoughts?
Thanks
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140524/62e3e230/attachment.html>