Ashley Holman [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-04-21 to 2015-08-13
💬 Posted a total of 7 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:34:47

- 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

- reply

2023-06-07 15:37:37

- 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/bitcoin-development@lists.sourceforge.net/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:13

- reply

📅 Original date posted:2014-06-03
📝 Original message:There is a relevant post from Satoshi on this:
https://bitcointalk.org/index.php?topic=191.msg1585#msg1585
Quote:
"If SHA-256 became completely broken, I think we could come to some
agreement about what the honest block chain was before the trouble started,
lock that in and continue from there with a new hash function.
If the hash breakdown came gradually, we could transition to a new hash in
an orderly way. The software would be programmed to start using a new hash
after a certain block number. Everyone would have to upgrade by that time.
The software could save the new hash of all the old blocks to make sure a
different block with the same old hash can't be used."
On Tue, Jun 3, 2014 at 9:21 PM, Ethan Heilman <eth3rs at gmail.com> wrote:
> An attack on the mining difficulty algorithm does not imply violation of
> the typical security properties of a cryptographic hash function*.
>
> Assume someone discovers a method which makes it far easier to discover
> new blocks, this method: may or may not be implementable by the current
> SHA256 ASIC hardware.
>
> 1. If it is usable by the mining hardware, then there will be brief period
> of overproduction and then difficulty will adjust. If the attack is so bad
> that difficulty can't scale and we run out of a leading zero's, then the
> SHA256 collision resistance is broken and we have bigger problems. Under
> this scenario, everyone would see the need to immediately switch to new
> hardware as people could create cycles and irreconcilable forks in the
> block chain
>
> 2. If the attack is not usable by the mining hardware, then the miners
> will need to switch to new ASICs anyways and the hash function can be
> changed without resistance.
>
> But lets ignore all that and say, for some unspecified reason, the bitcoin
> community wants to switch hash functions and has some lead time to do so.
> One could require that miners find two blocks, one computed using SHA256
> and one computed using the new hash function. We could then slowly shift
> the difficulty from SHA256 to the new hash function. This would allow
> miners a semi-predicable roadmap to switch their infrastructure away from
> SHA256.
>
> * It would be a distinguisher which would be bad, but collision resistance
> could be merely weakened.
>
>
> On Tue, Jun 3, 2014 at 12:52 AM, Luke Dashjr <luke at dashjr.org> wrote:
>
>> On Tuesday, June 03, 2014 4:29:55 AM xor wrote:
>> > Hi,
>> >
>> > I thought a lot about the worst case scenario of SHA256d being broken
>> in a
>> > way which could be abused to
>> > A) reduce the work of mining a block by some significant amount
>> > B) reduce the work of mining a block to zero, i.e. allow instant mining.
>>
>> C) fabricate past blocks entirely.
>>
>> If SHA256d is broken, Bitcoin as it is fails entirely.
>>
>> Luke
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Graph Databases - Download FREE O'Reilly Book
>> "Graph Databases" is the definitive new guide to graph databases and their
>> applications. Written by three acclaimed leaders in the field,
>> this first edition is now available. Download your free book today!
>> http://p.sf.net/sfu/NeoTech
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> 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/20140604/287312fb/attachment.html>

2023-06-07 15:22:04

- reply

📅 Original date posted:2014-05-24
📝 Original message:On Sun, May 25, 2014 at 8:29 AM, Bernd Jendrissek <bitcoin at bpj-code.co.za>
wrote:
>
> The difference is that with cut-through forwarding of blocks, a
> sufficiently motivated attacker (being willing to blow 25BTC's worth
> of electricity on the effort) can subjugate the entire Bitcoin network
> to its DoS attack, rather than having to connect to every node
> individually and then still have those individual nodes reject that
> invalid block without relaying any knowledge of its existence.
>
That is true, but they could also apply the same hash power to mine valid
blocks and would achieve the same outcome (their blocks would go to
everyone), except they would get paid for it. I wonder if it should even
be called DoS, due to the extreme and costly rate-limiting thats implied.
> An attack could also take the form of a block body that never arrives
> - a sort of teergrube attack, where the goal is to get the network
> mining empty block upon empty block on top of that valid-PoW header
> whose body never arrives. It doesn't have to be with an explicitly
> invalid block.
>
Thank you for raising this, as I share this concern. There is another
similar attack: if I send you a new block very slowly, I occupy all your
upstream peer slots indefinitely until the block is complete, because there
is no out-of-band messaging capability or ability to cancel a message.
There is also sub-optimal logic in choosing to download a block only from
the first person to offer it. It means you are fetching it from the lowest
latency path, but what really matters is who can give it to you fastest.
If there are multiple people who can send you a block at once, and you
have some idea of your spare upstream bandwidth capacity, why not let two
or more peers compete to send you the block fastest?
So to implement this type of thing, the p2p protocol should allow for
multiplexing of messages. Something like HTTP chunked encoding. It could
be in the form of:
<msgid><chunksize><rawbytes>, <msgid><chunksize><rawbytes>, etc etc
You only send a chunk once you've got the whole chunk in your buffer, so
it's not possible to get hung up on a single slow message. One block can
overtake another along the same hop path if it is being streamed faster.
On Sun, May 25, 2014 at 8:46 AM, Gregory Maxwell <gmaxwell at gmail.com>
wrote:
>
> If you want to go full out crazy in optimizing in this space, there
> are fancier things that can be done to further reduce latency and
> increase efficiency:
> https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding ... but
> some of this stuff really should be done as a seperate protocol. There
> is no need to have Bitcoin transport all using a single protocol, and
> we can get better robustness and feature velocity if there are a
> couple protocols in use (you could just run a block-transport-protocol
> daemon that connects to your local node via the classic protocol).
What about a separate project which is a mesh router specifically designed
for low-latency transmission of blocks? It could support things like a
more sophisticated/configurable routing table, and have some kind of
discovery where it tries to optimise its topology. There could even be
some way for nodes to prove their hash power, so pools can find each other
and directly peer / prioritise sends.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140525/b81d24be/attachment.html>

2023-06-07 15:22:03

- 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

- 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>

2023-06-07 15:19:11

- reply

📅 Original date posted:2014-04-21
📝 Original message:On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd <pete at petertodd.org> wrote:
>
> That is mistaken: you can't mine on top of just a block header, leaving
> small miners disadvantaged as they are earning no profit while they wait
> for the information to validate the block and update their UTXO sets. This
> results in the same problem as before, as the large pools who mine most
> blocks can validate either instantly - the self-mine case - or more quickly
> than the smaller miners.
>
>
Under the headers first scenario, wouldn't the full block still reach
everyone in the same time as it would under the current rules? So the
small miner loses nothing in terms of updating their UTXO set, but gains an
early "heads up" alert that a new block is coming. This allows them spend
the propagation time working more productively on an empty block in the new
chain rather than wasting time on an orphan. It's true that it doesn't
solve the problem of larger pools vs smaller pools, but if it doesn't make
it any worse then headers-first propagation would be a net benefit to the
network since it removes the incentive to make small blocks.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/55badfcc/attachment.html>