Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2013-11-14 📝 Original message:On 11/08/13 06:46, Mike ...
📅 Original date posted:2013-11-14
📝 Original message:On 11/08/13 06:46, Mike Hearn wrote:
> I took a brief look at the code - it's looking very reasonable. You can
> replace any construct like
>
> try {
> Thread.sleep(1000);
> } catch (InterruptedException e) {
> throw new RuntimeException(e);
> }
>
> which is quite verbose, just with
> Uninterruptibles.sleepUninterruptably(1000, TimeUnit.MILLISECONDS); (and
> of course static imports help too)
Thanks, fixed.
>
> I think for this concept to take off, you'd need a website and to
> recruit someone to help you market it. Pool operators won't reach out to
> you.
Yes, I've done some initial outreach and plan on doing another major
round now that the initial network is up and Im working on running some
relay time benchmarks. Finding someone to help push peering would be
nice, if you have any suggestions, Im all ears.
>
> I still find it perhaps more elegant to just boost the connectivity of
> the existing network with bitcoind changes, but this can help for now.
Agreed, improving relay times across the regular P2P network would be
nice, however I really dont see this as a part of the P2P network. Its
more of a backup relay network that just happens to follow the P2P
protocol (mostly, it doesnt do full block verification, so technically
it breaks spec). In this model, this is really a nice augment to the P2P
network no matter what improvements are made. Having more protocols/ways
blocks are relayed is always nice (anyone wanna launch a satellite?)
Matt
Published at
2023-06-07 15:09:13Event JSON
{
"id": "d6c1295ca4aec89a91f7cee86948d29b0432e5bd7199bcfeafc0b547a9740cae",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686150553,
"kind": 1,
"tags": [
[
"e",
"1a98a3cfd54df3ed479efd51703516524134bdfd6bb00267750e15ea4fca3178",
"",
"root"
],
[
"e",
"41322ec5904694ecfdc74f65772d03dd7c182bf5e2b94fd27a963d222cfd4286",
"",
"reply"
],
[
"p",
"f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2"
]
],
"content": "📅 Original date posted:2013-11-14\n📝 Original message:On 11/08/13 06:46, Mike Hearn wrote:\n\u003e I took a brief look at the code - it's looking very reasonable. You can\n\u003e replace any construct like\n\u003e \n\u003e try {\n\u003e Thread.sleep(1000);\n\u003e } catch (InterruptedException e) {\n\u003e throw new RuntimeException(e);\n\u003e }\n\u003e \n\u003e which is quite verbose, just with\n\u003e Uninterruptibles.sleepUninterruptably(1000, TimeUnit.MILLISECONDS); (and\n\u003e of course static imports help too)\n\nThanks, fixed.\n\n\n\u003e \n\u003e I think for this concept to take off, you'd need a website and to\n\u003e recruit someone to help you market it. Pool operators won't reach out to\n\u003e you.\n\nYes, I've done some initial outreach and plan on doing another major\nround now that the initial network is up and Im working on running some\nrelay time benchmarks. Finding someone to help push peering would be\nnice, if you have any suggestions, Im all ears.\n\n\u003e \n\u003e I still find it perhaps more elegant to just boost the connectivity of\n\u003e the existing network with bitcoind changes, but this can help for now.\n\nAgreed, improving relay times across the regular P2P network would be\nnice, however I really dont see this as a part of the P2P network. Its\nmore of a backup relay network that just happens to follow the P2P\nprotocol (mostly, it doesnt do full block verification, so technically\nit breaks spec). In this model, this is really a nice augment to the P2P\nnetwork no matter what improvements are made. Having more protocols/ways\nblocks are relayed is always nice (anyone wanna launch a satellite?)\n\nMatt",
"sig": "99d2fd168dcb71cf7787b0a772998e4463983db37c56b0449a0b1a0c8bf66f52f015c6d2b39b8054593cdc149f5a56823d419b1f2624308bf0076fb1f9596ef6"
}