liamzebedee

* There was an account/wallet that was created a week after Bitcoin mining 'commenced' in 2009.

* SN was known to have been active in the early mining. However so was Hal Finney (inventor of RPOW). They refer to it as the founder's wallet, but I think it would be more appropriate to think of it as the wallet of an early miner.

* This early miner's accumulated into it over 77,600 BTCs (mostly from mining operations)

* During June 2011 (4/6/2011 - 28/6/2011) almost all of these bitcoins were moved into a second account

* On the transaction graph, on one path, 45% of these bitcoins are are transferred to another wallet over the course of late 2012 to new year 2013. On the other path, the remaining 55% is sent to another wallet over the course of early 2012 to the same day new year 2013.

* The 45% wallet has a little of its funds sent to the 55% wallet, and then has laid dormant since a month back. In the 45% wallet in March'13, a fifth of the wallet is sent to the 55% wallet. Again, from the 14/9/13 to 23/10/13, another 15% is sent to the 55% wallet.

* However, if we look at the 55% wallet, we can see a clear link to DPR's wallet. In March'13, the 55% wallet sends 6 transfers totalling 2.5% of its balance ($1000) to another wallet, which sends this to DPR's account (as we know from the FBI's discovery of the wallet).

The authors suggest that all of these accounts belonged to the same person, this same early miner they call the founder. This is a possible flaw in their argument, as there were multiple early miners, Hal Finney being one of them.

The transactions that divided this wallet into the 45% and 55% wallets could have also split the ownership.

Lastly, it's very important to understand that while it may not be publicly recorded in the blockchain, these accounts could've changed hands by manually exchanging the private keys, and thus could bring into question the basis of this speculation.

That's an issue I've looked at while developing BitWeav [1]. Basically you can either make it a requirement that nodes store content or get them to do it voluntarily.

In the former circumstance, Bitcoin basically makes it a requirement that blocks are stored in the blockchain for the functioning of the payment system (correct me if I'm wrong, but that's the gist of it).

So the other more feasible alternative is incentives. The main approach I took with BitWeav is severing the connection to the node if they don't store certain messages for the benefit of the network. To explain briefly, BitWeav is a scalable decentralised and P2P microblogging system, and when nodes send a message in reply to another message, they MUST store and serve it if required, for the purposes of improving the quality of service. If they don't, they will be 'booted' from the network, a fair exchange. It is also worth noting that there are always people who donate resources to the network selflessly.

To finish off with a quote that comes from the early days of the Bitcoin mailing list: "Yes, [we will not find a solution to political problems in cryptography,] but we can win a major battle in the arms race and gain a new territory of freedom for several years." — Satoshi Nakamoto. Cryptography is not the end-all solution to all our problems, but it is good for escalating the situation until people enact change. We should solve the problem at its root.

[1] - http://bitweav.org

Now, to comment on the actual project. It seems here that we have another person attempting another decentralized project with a vision but no planning. It can be done, as somewhat shown by Tox [1] which was started off a /g/ thread on 4chan, but I'm not liking it so far. Generally you either start with some innovative ideas and get people to help you develop them, or you develop something and get people to help test it. Nonetheless, I wish the author the best, as we have similar goals.

On this note I'd like to end with a plug for my project [2], which is somewhat similar to Trsst but uses a P2P publish-subscribe overlay for distributing messages (it's more of an experiment than a product).

[1] - http://tox.im

[2] - http://bitweav.org

Still, props to the guy for creating the article. I didn't know that you could serialise/manipulate the SDP session descriptions before I read it.

What I was referring to was the lack of any API for signalling over already obtained network information (such as IP) rather than using a server for the initial signalling when you could use direct communications immediately after NAT has been traversed.

WebRTC is inherently dependant on centralised servers.

Unlike in traditional P2P, where there is simply the problem of bootstrapping the node (getting some initial connections into the network), in WebRTC this style of doing things is barely supported.

Instead you need to exchange RTCSessionDescription's (SDP blobs) through a createAnswer/Reply API, which is doesn't facilitate your typical 'connect to a node by their IP'. These session descriptions need be tweaked according to who is connecting and what parameters, so it also doesn't allow for a node to forward another nodes details (to form an overlay).

I've been researching the process of building a true P2P application on top of web technologies, but sadly and frustratingly this is stumping my progress. The only solution would be to expose a more 'raw' connection API by creating an RTCSessionDescription based on IP addresses. It's possible to hack together a solution whereby you tweak the data in the SDP blob (see http://en.wikipedia.org/wiki/Session_Description_Protocol), but this is too cumbersome.

  <!-- jQuery? more like crayQuery -->