Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - earthbound

Pages: [1]
Here's my first swipe at what I hope will evolve into an eBook about crypto-equity, and or what I might term the Blockchain Revolution:

I welcome feedback and/or added resources/references, hither or yon.

BitShares PTS / Miner list--updating
« on: January 19, 2014, 03:52:53 am »
Edit: sorry, that web spreadsheet has inconvenient limitations. Urgh.

The following links to an editable public spreadsheet, to keep track of so much software. Information which the spreadsheet lacks is left blank. Please update it with any relevant information you have or can find.

I've gone back and forth about this, and I feel I must say this.

All of the code which dga used in his development (of a GPU-enabled ProtoShares miner) is either copyleft or open, with the only exception being his original code itself, which simply claims his copyright. However, the expected terms of use of dga's code have been very clearly expressed in the forum. bytemaster paid a very substantial ProtoShares bounty (1,000!) to dga with the express hope that it would lead to open development of a GPU-enabled ProtoShares miner. dga has himself also expressed his wish for others to openly develop modifications to his work. I do not speak for bytemaster or dga, but I will comment on the nature of their comments: their expressions form a very clear verbal license which states that if you produce derived works from dga's source code, you must make the sources for your derived works available.

It is therefore only right that you should make your sources available, or else stop distributing the resultant binaries. Although my modifications to dga's work are only in a development stage, I have made those source modifications publicly available. But I am the only programmer who has released my modified sources.

Programmers: you should either make your modified sources (from dga's work) available, or else stop distributing the resultant binaries.

Your better option is to release your sources, since it was the expectation to begin with that you do so. Moreover, the community will gladly continue to donate to you from their mining proceeds.

Community: if you have not been liberally sharing some of your proceeds to these programmers, please reconsider. They deserve compensation for their hard work.

Aside: I earlier posted a philosophical rant arguing for Invictus to release their sources to the Public Domain. But now I see how sadly necessary express copyleft can be :(

An excellent passphrase is crucial in order to secure anything important (and which can be secured by a passphrase, e.g. a Keyhotee Profile/ID).

To more easily create such passphrases, I coded the following:

Feel free, anyone, to hork it and work it up wherever you will, for whatever purpose (all of the javascript can be viewed simply by bringing up the page source in a web browser).

I discovered only after coding this that this has perhaps been been better done by others--I had searched around for a tool like this, but of course only found what I was looking for after bothering to code this. Still, this helps suit my purposes.

An excellent observation about a problem was raised in the thread "Transition from PTS [ProtoShares] to BitShares." The problem is that anyone who does not directly control private keys for their ProtoShares funds cannot inherit the percent of those funds which is clones to any new DAC which honors the BitShares (?) Social Contract. A related problem is that users cannot directly control funds at exchanges, pools etc. when the hosts of the same possess the private keys (and users do not). If you understand these problems already, you can skip the PROBLEM section, and go straight to the SOLUTION section.


-- which problem is also underscored in the thread "Exact time of forking from protoshare to BitShares:

The problem surrounds the following situation. Suppose a developer makes a new DAC, let's just call it DAC X, and she decides to honor the BitShares (?) Social Contract in doing so. Therefore, to initialize the genesis block of DAC X, she developer takes a snapshot of e.g. ProtoShares at the time of block Y. This shapshot is of all the stakes (addresses) in the ProtoShares blockchain at a given time. She uses this snapshot as a basis of DAC X, instantly allocating ten percent of all stakes in DAC X proportionally to every stakeholder of ProtoShares at that time. The way that these stakes are awarded is that all ProtoShares stakeholders import their private keys from ProtoShares to their new wallets in DAC X; they thus claim their control of their new inheritance in DAC X.

A problem that arises in this is that anyone whose stakes in ProtoShares are controlled by a third party (at the time the DAC X genesis block is initialized) risks missing inheritance of their stakes in DAC X. For example, every ProtoShares stakeholder who has funds stored at an exchange or at a mining pool does not have direct control over those funds: they entrust the private keys which control those funds to others. Only the exchange or pool operators control the private keys associated with their funds. When the DAC X genesis block is initialized, these stakeholders therefore lose even peripheral control of their stakes. To claim their stakes, they will need to ask the exchange or pool operators to copy the private keys to them, and then transfer those funds to some private/public key pair which they fully control. This situation also runs the risk that the exchange or pool operators could refuse to honor their trust, and simply steal the funds by importing the private keys into their own new wallet for DAC X (without honestly giving the private keys to the proper owner).

This is also the general problem with hosted wallets: users trust third parties to not abuse the private keys. Heist after heist has originated in people either abusing that trust or outright cracking into virtual spaces, unwelcome, and abusing the keys to move cryptoccurency to their own wallets.


I've run across a "Bitcoin Address Utility," which is apparently both free and open-source:

-- which utility makes use of a mechanism, which I can only suppose was created by others in order to address this very type of situation. What this utility reveals is solution called Intermediate Passphrases.

The tool itself explains:

Enter a passphrase, and [click the "Encode passphrase" button, and an Intermediate Passphrase Code will be generated. You can give this code to someone else, and they can use it to create encrypted Bitcoin addresses that require your original passphrase to spend. The other party can add funds to the addresses but cannot spend funds from them.

So, for example, I can bring up this tool and enter the following in the Passphrase field:

Code: [Select]
youtube spawns ineloquent buffoons
-- and then click the "Encode Passphrase" button, and it spits out something like this:

Code: [Select]
Apparently, it is possible to code a mechanism which can use that (long, wonderfully garbled nonsense of a) passphrase, which would allow a user to have third parties deposit funds on their behalf, at the same time that it would only be possible for the user (not the third party, nor any other party) to spend the funds. I don't understand it myself, but here is the technical proposal, and apparently also an outline of how to achieve this:

Implementing this with a standardized codebase, and maybe even an API to execute this--this would solve one Huge problem and another (at least) Big Problem. The Huge Problem is the risk of losing funds which cannot always be secured by third parties (for example, cryptocurrency history is so far littered with so many terrible heists--from exhanges, web wallets, and even mining pools--which the practice of using Intermediate Passphrase Codes could have avoided). The Big Problem it would solve is that anyone who holds ProtoShares at exchanges, pools etc. which were deposited at addresses derived of Intermediate Passphrase Codes--holders of ProtoShares at such addresses would be able to control the funds of a new DAC which gives them an inheritance from a ProtoShares blockchain snapshot, immediately, without having to bother at all with whether the inherited funds derive from wallets at exchanges vs. a wallet they personally, directly control.

Please, will someone brilliant (or some brilliant team) code a standardized toolset which would make implementation of this relatively easy for both web-based and client-based wallet developers? I could suggest, even, that this would be a very worth Bounty for Invictus to throw out there; they would benefit from it a lot . . .

Pages: [1]