📅 Original date posted:2013-11-07
📝 Original message:What I want is configurable 1/10/100 millisecond ticks, and accurate
flow of information.
It doesn't seem necessary to really emulate the whole protocol, nor to
be overly concerned with the content of messages, nor to simulate every
little housekeeping step or network message.
I'm not looking for a bitcoin-network-in-a-bottle, I just want to see
flows. In the current situation, how often does a miner win if they
hold their block until they see another one? How does that change with
various numbers of remote sensors?
Other applications in the future could very well involve transaction
spread, double spends, network partitions, transaction replacement, etc.
If the simulation run in question involves blocks, I'd like realistic
latencies for blocks. If it is about transactions, the latencies should
be realistic for transactions.
What is realistic for those? That brings me to...
I'll kick in another 1 BTC for an instrumentation package for the
reference client. Same conditions as before. A runtime option,
disabled by default, that collects data for the simulator. If this
creates an uproar, I'll also accept a compile-time option. Support
dumping to a file that can be uploaded to a parser as the bare minimum,
and if you are feeling clever, add automatic uploads to a server
specified in the conf file, or whatever. All data should be anonymous,
of course. Local file should be in a format that humans can read (JSON,
XML, CSV, etc) so that people can verify that the data is indeed anonymous.
I want stats on peers (number, turnover, latency, in/out, etc), stats on
local operations (I/O stats, sigs per second when verifying a block,
fraction of sig cache hits when validating, etc) and whatever else might
be useful to a simulator. Each parameter should collect min, max, mean,
std. deviation, etc so that the simulator can provide realistic virtual
nodes.
Also, I don't want anyone to think that they need to satisfy me
personally to collect on either of these two bounties. I will pay mine
for a product that is generally along the lines I have laid out, if a
couple of the core devs (Gavin, Greg, Jeff, sipa, Luke, etc) agree that
your work is useful.
Christophe Biocca wrote:
>
> I might try building this sometime soon. I think it may also serve an
> educational purpose when trying to understand the whole network's
> behaviour.
>
> What level of accuracy are we looking for though? Obviously we need to
> fully emulate the steps of the network protocol, and we need to be
> able to specify time taken for transmission/processing for each node.
> Do we care about the actual contents of the messages (to be able to
> simulate double spend attempts, invalid transactions and blocks, SPV
> node communication), and their validation (actual signatures and proof
> of work)?
>
> I imagine the latter is pretty useless, beyond specifying that the
> signature/proof of work is valid/invalid.
>
> If we could build up a set of experiments we'd like to run on it, it
> would help clarify what's needed.
>
> Off the top of my head:
>
> - Peter Todd's miner strategy of sending blocks to only 51% of the
> hashpower.
> - Various network split conditions, and how aware of the split nodes
> would be (and the effect of client variability).
> - Testing the feasability of network race double spends, or Finney
> attacks.
> - Various network partition scenarios.
> - Tricking SPV nodes.
>
> On Nov 6, 2013 6:37 AM, "Jeff Garzik" <jgarzik at bitpay.com
> <mailto:jgarzik at bitpay.com>> wrote:
>
> I will contribute 1 BTC to this bounty, under same terms and
> expiration.
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming
> models. Explore
> techniques for threading, error checking, porting, and tuning. Get
> the most
> from the latest Intel processors and coprocessors. See abstracts
> and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> <mailto:Bitcoin-development at lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
>
> ------------------------------------------------------------------------------
> November Webinars for C, C++, Fortran Developers
> Accelerate application performance with scalable programming models. Explore
> techniques for threading, error checking, porting, and tuning. Get the most
> from the latest Intel processors and coprocessors. See abstracts and register
> http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk
>
>
> _______________________________________________
> 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/20131106/ba3e152f/attachment.html>;
Kyle Jerviss [ARCHIVE] /
npub154…w8pjr
2023-06-07 15:09:08
in reply to nevent1q…maez
Author Public Key
npub1545ndtu0dzkpr5tef46wpa4x47lds2t7tw7htm4l654sskf5zshsfw8pjrPublished at
2023-06-07 15:09:08Event JSON
{
"id": "b89fa786f66c6c3cd8e7b957386ad4a4753edddca7b6247cd195eb8da676623d",
"pubkey": "a56936af8f68ac11d1794d74e0f6a6afbed8297e5bbd75eebfd52b085934142f",
"created_at": 1686150548,
"kind": 1,
"tags": [
[
"e",
"611b40c00c89917ae0d0580c6e585e209ad17a08c94565936733ec9071434e29",
"",
"root"
],
[
"e",
"b99570c849b4652a514d550e828bb51dbf004d2cf9f0ce3028e84a28062f30dd",
"",
"reply"
],
[
"p",
"f05699fae959fb582a8bd56a55b613bafd61c2c239a00bc5ea66faf0cb7a2aa8"
]
],
"content": "📅 Original date posted:2013-11-07\n📝 Original message:What I want is configurable 1/10/100 millisecond ticks, and accurate \nflow of information.\n\nIt doesn't seem necessary to really emulate the whole protocol, nor to \nbe overly concerned with the content of messages, nor to simulate every \nlittle housekeeping step or network message.\n\nI'm not looking for a bitcoin-network-in-a-bottle, I just want to see \nflows. In the current situation, how often does a miner win if they \nhold their block until they see another one? How does that change with \nvarious numbers of remote sensors?\n\nOther applications in the future could very well involve transaction \nspread, double spends, network partitions, transaction replacement, etc.\n\nIf the simulation run in question involves blocks, I'd like realistic \nlatencies for blocks. If it is about transactions, the latencies should \nbe realistic for transactions.\n\nWhat is realistic for those? That brings me to...\n\nI'll kick in another 1 BTC for an instrumentation package for the \nreference client. Same conditions as before. A runtime option, \ndisabled by default, that collects data for the simulator. If this \ncreates an uproar, I'll also accept a compile-time option. Support \ndumping to a file that can be uploaded to a parser as the bare minimum, \nand if you are feeling clever, add automatic uploads to a server \nspecified in the conf file, or whatever. All data should be anonymous, \nof course. Local file should be in a format that humans can read (JSON, \nXML, CSV, etc) so that people can verify that the data is indeed anonymous.\n\nI want stats on peers (number, turnover, latency, in/out, etc), stats on \nlocal operations (I/O stats, sigs per second when verifying a block, \nfraction of sig cache hits when validating, etc) and whatever else might \nbe useful to a simulator. Each parameter should collect min, max, mean, \nstd. deviation, etc so that the simulator can provide realistic virtual \nnodes.\n\nAlso, I don't want anyone to think that they need to satisfy me \npersonally to collect on either of these two bounties. I will pay mine \nfor a product that is generally along the lines I have laid out, if a \ncouple of the core devs (Gavin, Greg, Jeff, sipa, Luke, etc) agree that \nyour work is useful.\n\n\nChristophe Biocca wrote:\n\u003e\n\u003e I might try building this sometime soon. I think it may also serve an \n\u003e educational purpose when trying to understand the whole network's \n\u003e behaviour.\n\u003e\n\u003e What level of accuracy are we looking for though? Obviously we need to \n\u003e fully emulate the steps of the network protocol, and we need to be \n\u003e able to specify time taken for transmission/processing for each node. \n\u003e Do we care about the actual contents of the messages (to be able to \n\u003e simulate double spend attempts, invalid transactions and blocks, SPV \n\u003e node communication), and their validation (actual signatures and proof \n\u003e of work)?\n\u003e\n\u003e I imagine the latter is pretty useless, beyond specifying that the \n\u003e signature/proof of work is valid/invalid.\n\u003e\n\u003e If we could build up a set of experiments we'd like to run on it, it \n\u003e would help clarify what's needed.\n\u003e\n\u003e Off the top of my head:\n\u003e\n\u003e - Peter Todd's miner strategy of sending blocks to only 51% of the \n\u003e hashpower.\n\u003e - Various network split conditions, and how aware of the split nodes \n\u003e would be (and the effect of client variability).\n\u003e - Testing the feasability of network race double spends, or Finney \n\u003e attacks.\n\u003e - Various network partition scenarios.\n\u003e - Tricking SPV nodes.\n\u003e\n\u003e On Nov 6, 2013 6:37 AM, \"Jeff Garzik\" \u003cjgarzik at bitpay.com \n\u003e \u003cmailto:jgarzik at bitpay.com\u003e\u003e wrote:\n\u003e\n\u003e I will contribute 1 BTC to this bounty, under same terms and\n\u003e expiration.\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e November Webinars for C, C++, Fortran Developers\n\u003e Accelerate application performance with scalable programming\n\u003e models. Explore\n\u003e techniques for threading, error checking, porting, and tuning. Get\n\u003e the most\n\u003e from the latest Intel processors and coprocessors. See abstracts\n\u003e and register\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=60136231\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e \u003cmailto:Bitcoin-development at lists.sourceforge.net\u003e\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e November Webinars for C, C++, Fortran Developers\n\u003e Accelerate application performance with scalable programming models. Explore\n\u003e techniques for threading, error checking, porting, and tuning. Get the most\n\u003e from the latest Intel processors and coprocessors. See abstracts and register\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=60136231\u0026iu=/4140/ostg.clktrk\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131106/ba3e152f/attachment.html\u003e",
"sig": "8e3db42be60745d3af564aa62396699372fa4dac374298f6014ee04c1abddc9f0e1d43e5e9204fd64215f424896750bb23bd1e638e3e95fb4d11e52c6a99c751"
}