1657q3…z3ML

Peace and Love

How about if you complain about the software, protocol or documentation not being open source? Can you drop the link again I might try it this weekend if I can find time.

Went to answer a question about your favorite computer games, couldn't remember the name of one, Arcadians.

Ended up at the riemann zeta function after a wiki wander, happens a lot to me.

https://en.wikipedia.org/wiki/Voynich_manuscript
https://en.wikipedia.org/wiki/Zipf%27s_law
https://en.wikipedia.org/wiki/Zeta_distribution
https://en.wikipedia.org/wiki/Riemann_zeta_function

https://en.wikipedia.org/wiki/Voynich_manuscript
https://en.wikipedia.org/wiki/Zipf%27s_law
https://en.wikipedia.org/wiki/Zeta_distribution
https://en.wikipedia.org/wiki/Riemann_zeta_function

Went to answer a question about your favorite computer games, couldn't remember the name of one, Arcadians.
Ended up at the riemann zeta function after a wiki wander, happens a lot to me.

Right.

https://twetch.app/t/28d30906aed9fd60b75820fd9969089b7d354142382c552796e96deb0cd181db

Well OC, so close.

FWIW I'm in LA too, but I don't get out much nowadays.

Come to think of it, another speed of light limit is time for transactions to saturate the mempool, and hence have some probability of confirming (limited security). I guess that's a more obvious/relevant one.

There're tricks involved too as I recall. To measure hash rate of nodes on the network requires taking advantage of transaction malleability. Sending different versions of the same tx to different miners to measure their hash rate. It's a feature not a bug

The honest hash should reject double spend attempts (conflicting tx's) and accept other tx's. If honest hash is in majority then the tx should go through, with some probability depending on honest hash percentage. But this all requires MinerId.

This is based on my recollection of conversations with CSW who kindly responded to my DM's, years ago. As I recall he explained that the merchant provides a payment template to the customer, and the template is used to send the tx to honest hash (nodes).

It might also require BSV to have majority hash rate. (This is to protect against double spend attempts on unconfirmed transactions, even for merchants that can't expect support from legal authorities, and don't want to enforce KYC requirements).

I would like a low cost/effort insurance service for merchants to protect them from double spends. But I believe this requires mapping the hash power of nodes that have established a reputation of not double spending. This wasn't possible before MinerId.

I set up several full nodes (around the world) and in the code where conflicting 'in-memory' transactions are detected I logged the transaction and had another machine that would consolidate the logs into one log to see global double spend attempts.

Maybe attempted double spend would be better terminology as only one tx will be confirmed. Oh, and BTW I expect OP_RETURN is covered in the normal code that disconnects on get failures, as I don't remember any special code for OP_RETURN.

Have you ever modified the bitcoin source code to enable full nodes to detect and report double spends (of unconfirmed transactions) in real time?

Only as part of a pool, if that counts. I haven't had much luck solo mining, although I have run several full nodes while working on a double spend detection system.

As I mentioned in another reply, pruning, failing to reply to requests for data from other nodes will get a pruning node disconnected (direct connections) from other nodes. This means pruning nodes get blocks slower and are less profitable. I think.

Not sure this is necessary due to the anti-pruning penalty I mentioned a couple of posts ago.

Maybe I'm missing something but there is no fee (in satoshi's) for getting data from 'other miners', so this argument doesn't make sense to me.

This is just from memory, I'm haven't looked at the code to confirm it applies to OP_RETURN for instance. Please someone let me know if I'm wrong. I'm currently responsible for vast amounts of medical data and are interested in moving it onchain.

IIRC nodes that repeatedly fail to return requested data are penalized as they are marked as bad by nodes directly connected, and those connections are closed & replaced. This slows down block propagation to the pruning node making it less profitable.

'tinker' is putting it nicely. As an example they abandoned Satoshi's approach to securing zero confirmed transactions, namely MinerId. Zero conf is broken on BCH as well as BTC. They have demonstrated a fundamental lack of understanding of the protocol.

'The BCH/BSV split was not primarily over ideology but rather changes to the transaction ordering that ... BCH ... wanted to add but ... didn't understand how that would impact the entire protocol.'

Yes, great video, except I disagree with the narrator Healey on the cause of the split and instead agree with the comment by J Paulus.