there's no time, so whose to say I didn't mine them and the network just didn't hear about it

you could mine on top of older sidechain blocks, as long as you mine on current mainchain tip

but then all your blocks will be included as uncles and you'll get less reward for them

roight, so better to try to mine on the tip

which incentivizes you to improve your network setup :P

even though its more likely that a tip block will get orphaned, but then thats no worse than mining on old sharechain blocks

tip block is unlikely to get orphaned because everyone tries to extend it with a new block

yeah. i assume sharechain is effectively monero, so fluffyblocks are used?

of course different miners can have different idea of the "tip block" depending on their latency

well there's no txs. nvermind.

sharechain stores only block templates + some additional data

in a sense, it's fluffyblocks (only transaction hashes)

plus miner tx payout doesn't have to be sent over the network at all because it's calculated from consensus

zmq notify will do lots here

yes, it uses zmq heavily

nice

so really each sidechain block will take at most 5-6 KB over the network

I could go to extremes like sending only first 4 bytes of each tx hash first and the send the rest

then each node could restore full block after receiving only first 1 KB of data

which fits into network MTU which is nice

is there any downside to that?

*could restore with like 99.9% probability

and will have to wait for the full data in other 0.1%

if there are some tx in mempool with identical first 4 bytes of hash

but this is not for the first release

sech1: I know the game theory terms because I had to learn them. Sometimes I wish I could forget. That was partly a trolling comment on my part, but it's also a real critique of claims that some behavior is predicted by "game theory". In even the basic Nash equilibrium concept, the equilibrium is in general not guaranteed to be unique.

I wrote down my reasoning

It's not guaranteed and really depends on distribution of miner hashrate percentages

if you take 25% from uncle block, "small" miners are everyone with less than 25%. As long as no miner is more than 25% of the pool, it's guaranteed

gingerpolous, this encoding will be ambiguous in case of many txs with the same hash prefix

so then it becomes similar to "51%"

yes, first 4 bytes are ambiguous (in theory), I just plan to send them first and then the rest 28 bytes for each tx

so as soon as you receive the first packet (less than 1 KB, fits into MTU), you can try to restore full block

should be efficient

your mempool might not even have some transactions from that block (latency) which is more realistic case of when you can't restore full hash from first 4 bytes

<sech1> "but then all your blocks will be..." <- Why aren’t “small” miners with lower hash rate than their share of the uncle reward incentivized to only try to mine orphans on an individual level? Isn’t that the individual small miner’s profit maximizing strategy?

Imagine you're a miner with 0.05% of pool's hashrate, you can barely mine 1 block in the PPLNS window. If you include some other uncle block, you suddenly receive 125% of your usual reward from that block you mined

so including uncles increases your reward by 25% on average. As your hashrate increases, this reward increase gets less and less

and if you have more than 25% of pool's hashrate, your reward starts decreasing if you include uncles (think of the case when you have 100% hashrate)

but even if you have high % of hashrate and don't include, someone else will include that uncle block and 100% of that block's reward will be in the PPLNS window

but 25% of it won't go to you which will reduce your reward more compared to the case when you included it as a big miner

but hey, ultimately, its open source and permissionless so folks could create an uncle-free separate p2pool, and the market will decide

so, potato potato

I might even make it a knob in pool's config, right?

ooooh knobs.

this will change consensus and create a separate p2pool chain

there will definitely be more than 1

A knob to turn the potato into a banana for gingeropolous.

flags. all the flags

no one mispells bananannaa

because if everyone's on p2pool, it's not fun even with 10 second blocks

I want to leave an option to adjust consensus (like genesis block hash and some other params) so everyone can just mine their own separate chain

yeah, and even just an ID

yes, an ID in each block that must be set to predefined value

taken from config

it might be even just a string, essentially a pool name

"anonpuddle24"

I'm thinking of more like local p2pools

"WestcoastPool420"

because network latency

yep. awesome.

.merges

"github.com/monero-project/monero/blob/master/CMakeLists.txt#L500", hyc, that zeromq was always linked with shared libs

so `make release-static` doesn't make any sense

"monero-project/monero #6824" at least after this commit, since krb5 package doesn't even have static libs in debian/ubuntu

Does Monero have more than one full node implementation? I am aware that BCH has 6 full node implementations and I'm wondering about Monero.

Not that I’m aware of.

Ok. I'm thinking down the road it may make sense for me to write an R package for RPCing monerod. I wanted to see if I would have to take into account another implementation.

wfaressuissia[m]: yeah the gssapi/krb5 deps are all dynamic paste.debian.net/1207114