Arnoud Kouwenhoven - Pukaki Corp [ARCHIVE] / is on Nostr

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

Last Notes

2023-06-07 17:33:17

- reply

📅 Original date posted:2015-08-05
📝 Original message:Thanks for this (direct) feedback. It would make sense that if blocks can
be submitted using ~5kb packets, that no further optimizations would be
needed at this point. I will look into the relay network transmission
protocol to understand how it works!
I hear that you are saying that this network solves speed of transmission
and thereby (technical) block size issues. Presumably it would solve speed
of block validation too by prevalidating transactions. Assuming this is all
true, and I have no reason to doubt that at this point, I do not understand
why there is any discussion at all about the (technical) impact of large
blocks, or why there are large numbers of miners building on invalid blocks
(SPV mining, https://bitcoin.org/en/alert/2015-07-04-spv-mining), or why
there is any discussion about the speed of block validation (cpu processing
time to verify blocks and transactions in blocks being a limitation).
Our proposal aims at solving all three issues.
Now I would be glad if the suggestions we made are already implemented,
especially if that is in a more elegant approach. Great! Yet we still see
all three discussions, which is a surprise if they have been solved.
On Wed, Aug 5, 2015 at 2:16 PM, Gregory Maxwell <gmaxwell at gmail.com> wrote:
> On Wed, Aug 5, 2015 at 7:53 PM, Arnoud Kouwenhoven - Pukaki Corp via
> bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Thanks for the reply. My understanding is that the bitcoin relay network
> is
> > a backbone of connected high speed servers to increase the rate at which
> > transactions and new blocks propagate - and remove a number of delays in
> > processing. But it would still require the miners to download the entire
> > block before building on top of it with any degree of confidence.
>
> Your understanding is outdated.
>
> The relay network includes an optimized transmission protocol which
> enables sending the "entire" block typically in just a smal number of
> bytes (much smaller than the summaries you suggest, which still leave
> the participants needing to send the block).
>
> E.g. block 000ce90846 was 999950 bytes and the relay network protocol
> sent it using at most 4906 bytes.
>
> No trust is required in this scheme because the entire block is
> communicated using only a couple packets.
>
> The current scheme is highly simplified and its efficiency could be
> increased greatly with small improvements, or if miners created blocks
> in an aware manner.... but with a maximum size blocks turning into 5kb
> with the current setup, there hardly appears to be a reason to do so
> right now.
>
> Ultimately there is no need for information communicated with a block
> at discovery time proportional to the size of the block; with the
> right affordances it can be accomplished with a small constant amount
> of data.
>
> If not for this already being deployed I personally believe the
> network would have already fallen into complete centeralization as a
> response to larger blocks: this was constructed and deployed in order
> to pull the network back from having a single pool with more than half
> the hashrate.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150805/bff71600/attachment.html>

2023-06-07 17:33:16

- reply

📅 Original date posted:2015-08-05
📝 Original message:Thanks for the reply. My understanding is that the bitcoin relay network is
a backbone of connected high speed servers to increase the rate at which
transactions and new blocks propagate - and remove a number of delays in
processing. But it would still require the miners to download the entire
block before building on top of it with any degree of confidence. With a
tweak to only send the required information for other miners to build on
top of that block, this is a step towards what we propose, yet would
require trust that the header information sent is accurate. The bitcoin
relay network website states that blocks are not fully verified and should
be checked by the miners before building on top of them.
What we propose is more complex (granted!), yet that complexity serves a
purpose. We reduce (and hopefully eliminate) the adverse incentive to
entice miners to build on inaccurate data. This is achieved by making the
financial losses of fake messages outweigh the financial gains of such
attack vectors. It could also help in the block size debate if this
proposed solution would eliminate the disadvantages of large blocks.
On Wed, Aug 5, 2015 at 1:27 PM, Matt Corallo <lf-lists at mattcorallo.com>
wrote:
> See-also: Bitcoinrelaynetwork.org. It's already in use my the majority of
> large miners, is publicly available to anyone, and the protocol is rather
> simple and the client could be tweaked easily to keep exactly it's block
> ready to quickly relay to the nearest server (ie only have to relay the
> header, the coinbase transaction, and only small other data... Experience
> shows this is really easy to fit into one packet on the wire). It's not
> nearly as complicated as your suggestion, but may still marginally favor
> well-connected miners, but hopefully not much (when you're taking about
> single packets, it should all be latency, and the servers are well
> distributed). If you feel so inclined, there are some todos to make it
> really meet is efficiency limits filled on
> github.com/TheBlueMatt/RelayNode, feel free to rewrite the protocol if
> you really want :).
>
> Matt
>
> On August 5, 2015 9:07:44 PM GMT+02:00, Arnoud Kouwenhoven - Pukaki Corp
> via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Hello all.
>>
>> We’d like to share an idea we have to dramatically increase the bitcoin
>> block propagation speed after a new block has been mined for the first time.
>>
>> Efficient bitcoin block propagation
>> A proposed solution to provide near-instantaneous block propagation on
>> the bitcoin network, even with slow network connections or large block
>> sizes. Increasing mining efficiency for everyone while decreasing
>> transaction confirmation times and strengthening the distributed nature of
>> bitcoin.
>>
>> Short summary: we propose to introduce bitcoin-backed guarantees
>> (“Guarantee Messages”) between miners. This would allow miners to mine on
>> blocks that are not yet fully transmitted. This reduces the effect of slow
>> internet connections, leveling the playing field between the 1st world
>> fiberoptic datacenter miners and the rest of the world. We also believe it
>> strengthens the bitcoin network by using existing processing power that is
>> currently wasted into further securing the blockchain, and it reduces the
>> likelihood of transactions becoming confirmed, then unconfirmed and then
>> -hopefully- confirmed again (due to different miners finding competing
>> blocks with different transactions at approx the same time).
>>
>> It is possible to implement our idea as a fork of bitcoind, or as layer
>> between the standard bitcoind and the mining equipment. In the future it
>> could be incorporated in the bitcoin core if and when that becomes a
>> priority, but that step would not make sense until it becomes a priority.
>>
>> There are a lot of nuances in this idea, and the first reaction is quite
>> probably that this is a crazy idea. We have attempted to address the most
>> important nuances in our proposal, which is currently at v.0.2.
>>
>> We cannot guarantee that there are no ‘hidden devils in the details’ and
>> we invite you to be critical in a friendly and constructive manner. We will
>> do our best to answer all questions that arise.
>>
>> The ‘official’ proposal is at:
>> PDF: http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.pdf
>> HTML: http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.html
>>
>> -- Arnoud Kouwenhoven
>>
>> ------------------------------
>>
>> 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/20150805/8a133c4e/attachment.html>

2023-06-07 17:33:15

- reply

📅 Original date posted:2015-08-05
📝 Original message:Hello all.
We’d like to share an idea we have to dramatically increase the bitcoin
block propagation speed after a new block has been mined for the first time.
Efficient bitcoin block propagation
A proposed solution to provide near-instantaneous block propagation on the
bitcoin network, even with slow network connections or large block sizes.
Increasing mining efficiency for everyone while decreasing transaction
confirmation times and strengthening the distributed nature of bitcoin.
Short summary: we propose to introduce bitcoin-backed guarantees
(“Guarantee Messages”) between miners. This would allow miners to mine on
blocks that are not yet fully transmitted. This reduces the effect of slow
internet connections, leveling the playing field between the 1st world
fiberoptic datacenter miners and the rest of the world. We also believe it
strengthens the bitcoin network by using existing processing power that is
currently wasted into further securing the blockchain, and it reduces the
likelihood of transactions becoming confirmed, then unconfirmed and then
-hopefully- confirmed again (due to different miners finding competing
blocks with different transactions at approx the same time).
It is possible to implement our idea as a fork of bitcoind, or as layer
between the standard bitcoind and the mining equipment. In the future it
could be incorporated in the bitcoin core if and when that becomes a
priority, but that step would not make sense until it becomes a priority.
There are a lot of nuances in this idea, and the first reaction is quite
probably that this is a crazy idea. We have attempted to address the most
important nuances in our proposal, which is currently at v.0.2.
We cannot guarantee that there are no ‘hidden devils in the details’ and we
invite you to be critical in a friendly and constructive manner. We will do
our best to answer all questions that arise.
The ‘official’ proposal is at:
PDF: http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.pdf
HTML: http://pukaki.bz/efficient-bitcoin-block-propagation-v.0.2.html
-- Arnoud Kouwenhoven
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150805/4b94b1ad/attachment-0001.html>

2023-06-07 15:45:26

- reply

2023-06-07 15:45:26

- reply

2023-06-07 15:45:25

- reply