The problem of pseudo-nodes will come over and over. The cat and mouse
chase is just beginning.
It has been discussed some times that the easiest solution world be to
request some kind of resource consumption on each peer to be allowed to
connect to other peers.
Gmaxwell proposed Proof of Storage
In building some CLTV-based contracts, it is often also useful to have a
method of requiring, instead of locktime-is-at-least-N,
locktime-is-at-least-N-plus-the-height-of-my-input. ie you could imagine
an OP_RELATIVECHECKLOCKTIMEVERIFY that reads (does not pop) the top
stack element, adds the
Repost of
https://www.reddit.com/r/Bitcoin/comments/2z9k5p/factom_announces_launch_date_for_software_token/cph0pvo
for archival/disclosure purposes:
I'm very skeptical about the long-term viability of Factom and the value of the
Factom token.
The idea behind Factom is to create a
Thanks Jan, we added several additional checks for non-standard protocol
responses, and also made the client revert to DNS seeding more quickly if
it runs into trouble, so it's now more robust against sybil/DOS attack. I
mentioned in the coindesk article that I didn't think what your nodes were
What we were trying to achieve was determining the flow of funds between
countries by figuring out which country a transaction originates from.
To do that with a certain accuracy you need many nodes. We chose a class C
IP range as we knew that bitcoin core and others only connect to one node
in
5 matches
Mail list logo
