Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jun 20 2016 02:11
    @alexvandesande banned @algotrader2013
  • Jun 05 2016 10:31
    @alexvandesande banned @adamskee
Benjamin Z
@benjyz
employment contract => detail means of payment, date of payment, .. and more
there is a feedback loop issue with paying in network currency, e.g. in Dash the resources available fluctuate widely with price
Benjamin Z
@benjyz
Nick Savers
@nicksavers
Good idea. Put the money in a Smart Contract when pledging it.
Lane Rettig
@lrettig
“put your money where your mouth is” -> “put your ETH where your code is” :)
Jean Cyr
@jean-m-cyr
A more current version, or so it would seem: “put your mouth where your money is” -> “put your code where your ETH is”
MaxSemenchuk
@MaxSemenchuk
hey guys, is it live still?
if so would like to get you perspective on using Kialo for different Ethereum governance debates. E.g. https://www.kialo.com/ethereum-ecosystem-should-be-funded-through-some-form-of-taxation-30287?path=30287.0~30287.1
Brent Allsop
@BrentAllsop
Still here. Looking forward to meeting you at blockchain week.

Canonizer seeks to collaborate with everyone, including Kialo, especially since they have such a nice user interface, something Canonizer could use some help with. But it hasn’t been a priority since like everything else on the internet, it just polarizes people. At every level of the T-Bar structure they use, there is nothing but polarizing to one side or the other. Whereas with Canonizer’ s camp tree structure, you can push the polarizing issues to lower level sub camps that are still supporting the super camp, keeping the important consensus stuff at the top. Since everyone only talks about what they disagree on, everywhere else this is completely lost, as a collateral damage from continuous arguments on lessor important issues. At canonizer you discover that on almost every polarizing issue, there is far more important stuff that can be found that everyone agrees on.

Take the flat earth topic, for example. There are many arguments listed on the “flat” side of the argument, including any that anyone can collect, regardless of whether anyone values them or not, so it gets more weight than it should. At canonizer, you can measure the value of the argument or results, by how many people they convert. The best ones rise to the top.

Also, there is no real measure of consensus for any of the sides or arguments. There is no way to find out if anyone’s beliefs have been falsified (as can be measured on Canonizer when people jump camps) and so on. You need to find out, concisely and quantitatively, what everyone wants, when working to build and track consensus, so you can work to win everyone over to the same camp. It’s all about falsifiability, at Canonizer.com, we get each side to focus on what it would take to ‘falsify their side’ or get them ‘on board’. Then it is up to the experimentalists to do the experiment, forcing “scientific consensus’ that can rigorously be tracked. (Did they all actually jump camps or what else may still be required?)

Adam Schmideg
@adamschmideg
@BrentAllsop Do you have a flat earth topic on Canonizer? I couldn’t find it. It would be easier to compare Kialo and Canonizer if we look at the same topics processed differently.
Brent Allsop
@BrentAllsop

@adamschmideg , Canonizer is still fairly new/prototype so not a lot of content yet. The well developed proof of concept topic is the one on “Theories of Consciousness. About the closest topic to this on Kialo is the one on “Are ghosts real”.

With canonizer you can see there is a surprizing amount of consensus forming around the new falsifiable state of the art “expert consensus” “Representational Qualia Theory”. Notice that this topic shows there is a near unanimous consensus defining ghosts, or at least “conscious knowledge of ghosts” in an approachable via science way. Where as on kialo you get ghost are not real arguments like: “There is no scientific evidence for ghosts” which many people would reject, and arguments that are just clearly wrong like “There is no mainstream religions that says ghosts are real.

At canonizer the focus is on falsifiability. Each camp is encouraged to describe what could falsify their camp (or negotiate what would be required to get them on board). This is what makes it such a powerful theoretical tool. Once the experimentalists do the experiment, it forces a scientific consensus. You can see just how powerful arguments and evidence are by how many people they definitively convert. For example we’ve seen people abandon theories of consciousness camps due to data coming out of the large hadron collider.

Marquard Dirk Pienaar
@mdpienaar
Can someone inform please; when will the Proof of Stake be implemented, reducing transactions costs and speeding up the network?
Bob Summerwill
@bobsummerwill
Hey everyone!
Just moving here from All Core Devs on ProgPOW and governance concerns that raises for me.
My blog post from yesterday, for anybody who has only seen the Twitter noise in response and not read what I actually said. It includes links to press releases, screenshots, videos, etc:
https://bobsummerwill.com/2019/09/17/progpow-author-kristy-leigh-minehan-uninvited-from-etc-summit/

Something which came out of this for me was how strongly I feel that we are missing safegrounds around the EIP process which are common for mature client codebases. For example, Hyperledger Besu, like all other Linux Foundation projects uses DCO (Developer Certificate of Origin) declarations for all contribution. And those are with real legal names, not pseudonyms.

For EIPs, all we have are required CC0 licensing. No patent protection.

There was a proposal on the patent part, which is good:
https://ethereum-magicians.org/t/patent-covenant-for-eip-submissions/2901

But I think we do need to get a lot more risk-focussed, and recognize that the EIP process will be an attack vector for bad actors. Is that the case for ProgPOW? Some people think so, some do not, but the fact is that we don't have consistent armor in our process to defend against these social and political attacks.
https://github.com/hyperledger/besu/blob/master/DCO.md

Tim Beiko
@timbeiko

For example, Hyperledger Besu, like all other Linux Foundation projects uses DCO (Developer Certificate of Origin) declarations for all contribution. And those are with real legal names, not pseudonyms.

So I think there’s a big difference between EIPs and clients here

Bob Summerwill
@bobsummerwill
What is that difference?
Aren't the stakes even higher for the protocol definition than for implementations of that protocol?
Tim Beiko
@timbeiko
Sure, specific clients, like Besu, may want DCOs, but requiring this at the “Ethereum-level” seems wrong. IMO Ethereum should remain permissionless and I’m not sure we gain much by adding overhead at that level.

Aren't the stakes even higher for the protocol definition than for implementations of that protocol?

INAL, but the protocol doesn’t “belong” to anybody. It’s not a product, it’s a spec.

Bob Summerwill
@bobsummerwill
DCOs aren't about ownership. They are about risk management for a shared resource. In this case, an incredibly valuable one.
Marius van der Wijden
@MariusVanDerWijden
I agree with @timbeiko. I don't think we should force anonymous open source contributers to sign CLAs/DCOs. The blo
Bob Summerwill
@bobsummerwill
What do IETF and W3C do around this sort of stuff, I wonder?
Tim Beiko
@timbeiko
That’s a good question.
IMO the real name requirement is overkill, and it’s worth keeping in mind that Ethereum is a valuable shared ressource in large part because it acts somewhat separated from a lot of legal, financial, etc. infratructure. Obviously, this is where the protocol/client difference is most apparent.
Bob Summerwill
@bobsummerwill
IETF especially, where (like Ethereum Magicians) you have an organization without any formal membership, where individuals speak as themselves, but they are collectively building protocols and standards. Very analogous to our own situation.

The nightmare scenario is for patents to get inserted into the protocol.
Lesser scenarios, but which are entirely plausible is for proposals which economically favor particular parties to be inserted by them.

I understand that this stuff is "the whole game" for bodies like the ISO, with companies like IBM being masters at playing it. Pushing "their thing" as a standard, because they have a huge business built on top of that or whatever.

It would be naive to think, with the sums of money at stake around Ethereum, that everybody is going to play fair here. You absolutely will see parties gaming the EIP process.

Bob Summerwill
@bobsummerwill
Changing the hash algorithm is obviously the example here, but there will be many more as there are more and more business building on top of Ethereum.
I don't know whether dropping "real name" essentially nullifies the benefits of DCO, patent covenants and other IP law best practices. Probably. Because what real world leverage is there against bobbyrandom@gmail.com and his declaration that he made this EIP and he pinky promises it is above board.
Brent Allsop
@BrentAllsop
@bobsummerwill, Sorry, what is "DCO"?
Jean Cyr
@jean-m-cyr
Ethereum, unlike the IETF, doesn't have the notion of a formal chairman per group with the final decision authority. The comparison is weak.
As for gaming the process, I think you're already seeing it in the case you cite (changing the PoW)
Greg Colvin
@gcolvin
The Magicians can form working groups and organize them as they choose, including designating a chaiir, @jean-m-cyr. It’s just less formal the IETF, at least at this stage. Even in the IETF the chair doesn’t have final authority, but that’s a long discussion in itself.
Bob Summerwill
@bobsummerwill
@BrentAllsop
DCO = Developer Certificate of Origin
See https://developercertificate.org/
Essentially asking that each contributor to a project (using a real name) asserts that they authored the code and have the right to contribute it under the licensing which the project is using.
Nick Savers
@nicksavers
@bobsummerwill what's stopping people from writing patented code in an Ethereum contract and claim revenue from the ETH holder?
Bob Summerwill
@bobsummerwill
I think that the law there, @nicksavers, is likely analogous to running applications on an operating system.
It is the potential of patents or other badness getting into the platform itself which is the issue which I think we need to address.
Brent Allsop
@BrentAllsop

@bobsummerwill, You are bringing up some very important stuff. We’re working on what were calling the “Ethereum Consensus Project” (https://canonizer.com/topic/210-Ethereum-Consensus-Project/1) at Canonizer.com. It would be great to start a topic to see if some consensus can be built around some of your ideas. For example, we need to get a topic started around the Ether EIP process. Would you mind helping us craft a topic around your ideas so we can find out how many people do and do not agree with this?

Also, as we tweeted here: https://twitter.com/StallionCornell/status/1174439694643298304, we need help tracking consensus for (or against) ProgPoW.

Micah Zoltu
@MicahZoltu
FWIW: If the EIP process (or any other part of Ethereum development) required a DCO I would immediately stop contributing.
I'm in this space because I'm sufficiently frustrated with "the real world" and I want to create a new, better world.
I don't want to just make a copy of "the real world" that sucks in all of the same ways.
Part of that world I want to live in is one without patents/copyrights, where everything is just public domain and there are no patents.
Another part is that the participants in the system are valued based on their contribution, not based on the ability to use threats of violence against them to get them to capitulate.
Separately, a DCO doesn't actually solve anything since anyone can trivially lie on it. Even if you require full KYC, such measures are not that hard to bypass by a motivated actor. This means that a DCO effectively reduces to legal theater, where companies are just saying "well, we tried, if someone sneaks a patent into our code it isn't our fault" when they get taken to court.
TL;DR: Patents bad. Copyright bad. DCO is legal theater. Old world sucks. New world is good.
Marius van der Wijden
@MariusVanDerWijden
I have also not found any legal disputes that suggest that DCOs would have solved the problem.
Which means that DCOs would probably not help us in a legal dispute with people contributing copyrighted code.
Regarding patents: Patents can not be applied in reverse. Once something is published, you can not get a patent on it anymore, so the argument that Craig Wright or someone would hold a patent on ProgPoW is invalid.
Micah Zoltu
@MicahZoltu
@MariusVanDerWijden I believe the argument is that someone patents something, and then submits code that is beholden to that patent to some open source project.
After the project is released, they then demand royalties from the aforementioned project.