Hi there, Dnia czwartek, 19 marca 2015 07:54:22 Logan Streondj pisze: > > I don't think this is viable. "Contribution" is hard to define well > > enough,
> to quantify it, we can say a contribution is a patch that is accepted > to the mainline. But that's exactly my point. Proof-of-work in the blockchain *has to be* completely automatic and easily *automagically* verifiable. Also, it has to be achievable in a predictable amount of time (from the whole network perspective, not necessarily from the perspective of a particular peer/agent/developer). "Accepted to the mainline" does not satisfy any of these. > > and "test" thoroughly enough. In the end it would always have to be people > > that assess this. And the power of Bitcoin/blockchain is how automatic it > > is. *However*, we should definitely continue to try finding a better work > > for the proof-of-work scheme. > > the line between what people and computers can do, is regularly > blurred. If for instance feature-requests are written in SPEL or > another language both computers and humans can have fluency in, > then it would quite possible to automatically generate the required > tests, and once the tests are made, then it's a combination of brute > force and heuristic AI's to find code that passes the in-outs and > performance metrics. > (...) I think writing a blockchain- and DHT-based GitHub replacement is already a bunch of innovation, maybe we should not get ahead of ourselves... > > So, these "librecoins" you're talking about, and the blockchain, are two > > different beasts, used for two different purposes. Mixing them, I feel, > > might not help at all. > > > > > > The former one, the "librecoin"/"upvote" scheme, is a *social* process in > > which users tell developers which features/bugs are most important. > > > > > > The latter, the blockchain, is a "mechanical", technological solution to > > the problem of lack of a trusted third party verifying who owns what. > > right, but developers want to get paid, and they could get paid on the > blockchain, by the DAC, who bases payment based on upvotes and > donations to issues. This is not feasible to do in the blockchain itself for the reasons I outlined before. Also, there is no good reason to actually do that on the blockchain -- upvotes, etc, can be a separate system, not tied directly to the (crucial) functionality of the blockchain/ledger. The blockchain has a single crucial function: keeping the ledger of who owns what. This *has to* be done automagically, and should not be tied to any additional functionalities, as that would possibly jeopardize this crucial task. > currently payment is based on proof of work for computing blocks, > which "generates" coins, i.e. the bitcoin DAC gives coins for blocks. > in proof-of-stake the DAC gives transaction-fee derived coins based > on current holdings. While I agree there has to be an incentive to actually do the work for the proof-of-work, it doesn't have to be a payout. Twister gives the user that "mines" another block the right to post a non-blockable message to all Twister users (following them or not). And (at least for now) that is enough. > > I think Twister does it right. Blockchain is used for "who owns which > > account", and DHT is used for Twists, etc. A decentralized issue tracking > > system could build upon that. > > yep, so it would be similar, accounts and payment transactions would > be kept on the blockchain, wheras the content of issues, code, and > related media would be on the DHT. Yep. I would just take the "payment" out of it, as it has been taken out of Twister too. I don't think we need that particular social dynamic in there... > > > For complicated issues, may need to break up solution into parts, > > > for instance a test-maker can come along to figure out what the > > > input/output is going to look like, and on acceptance get some of > > > the coin. Then someone/thing would write the code, pass the tests, > > > and get the rest of the coin. This would open the door for automatic > > > code-generators, which could harness the FPGA's, GPU's, and other > > > hardware hardcore bitcoiners like to use. > > > > I think that's too far out for now. But having a proof-of-work in the form > > of compiling and *verifying* a verifiable build -- that would sound like > > a *great* idea! > > if it adds value, okay, for instance porting to a new platform. > but otherwise I don't think of compiling for the sake of doing > "something" as a worthwhile endeavour. Compiling and verifying reproducible builds has immense value: https://wiki.debian.org/ReproducibleBuilds https://www.youtube.com/watch?v=5pAen7beYNc https://www.youtube.com/watch?v=ca0DWaV9uNc It's also crucial to the free software movement, as probably the single most effective measure against "trusting trust" problems: https://www.ece.cmu.edu/~ganger/712.fall02/papers/p761-thompson.pdf https://www.schneier.com/blog/archives/2006/01/countering_trus.html > Though perhaps you mean to verify that a patch works as intended, > then I would certainly agree that is worthwhile. Problem with this is that first the tests would have to be written, and these have to be written by a programmer, and again we land in something that cannot be (easily) automagically verified. Unless we include a caveat of "running tests if they are written", but then the blockchain can be blocked by lack of tests... -- Pozdrawiam, Michał "rysiek" Woźniak Zmieniam klucz GPG :: http://rys.io/pl/147 GPG Key Transition :: http://rys.io/en/147
signature.asc
Description: This is a digitally signed message part.
