dapp architecture consulting - 30 min to 1 hourAs the developer of Toastycoin and the CryptoPrimitive initiative (producing the BurnChat and CrowdServe dapps), I have experience in rapid, experimental dapp design.
After the payer has committed, we will arrange a 30-minute video or voice call. We will go over your ideas or questions for dapps, and I will highlight the largest obstacles and best approaches to make it a reality. I can also share insight on the technical process of creating the "full stack" of a dapp: smart contracts as the back-end, with web3 libraries acting to communicate between the contract and the front-end.
If the payer funds an additional 0.03 ETH, I can extend the meeting to an hour total.
blockchain project analysis - 2 hoursI will analyze any specified blockchain project for 2 hours, then deliver to you either a 1-2 page summary or up to 30 minutes of video/voice chat on my findings. I will deliver within 3 days of the Payer specifying the project via a payer statement (or email at coinop.logan@gmail.com)
I focus on technical viability of the economics of the project, and the level of awareness the project demonstrates with regard to the current, rapidly changing industry. I do not focus on team background or marketing strategy.
I may release my findings publicly unless we come to some other agreement.
Generate buzz for the TC Burnable Service upgradeWorker should have experience in PR / buzz generation. I expect a ballpark of 2 hours of work for the ether in this payment, but will likely add more funds and release in chunks if the work is effective.
I will only burn the funds if there seems to be no added exposure as a result of the work. I expect quick work--within 24 hours after commitment I should see some effect.
Feel free to contact me at coinop.logan@gmail.com after commitment, or post updates as worker statements.
$200 of ETH has been released as agreed for the initial delivery of the product. $190 is left in the initial agreement, to be released after the code is more fully examined.
BP for Daniel Lee's front-end workDo not commit if you're not Daniel Lee!!
Daniel Lee has committed to producing front-end work on the CrowdServe contract, and I have committed to paying him the amount in this BP for the first chunk of work on this project.
Create an abstract version of billiards as a dapp (web3py or web3js)Here are the basic rules:
The table has some number of pockets, and there is a set of billiards that have initial positions. The placement of pockets and initial billiards' positions don't need to be anything we're used to.
There is some number of players (you decide) who rotate through turns. Each can impact one billiard ball with some vector. (If the resulting collision is too complex, the dapp will run out of gas and abort. That's fine, and will serve as a natural limit to how strongly a ball can be hit.)
The billiards balls act as points (0 width). When colliding with walls or testing for hole collision this is simple. For collision detection between billiard balls, you may either simply assume some nonzero width, or think up something more creative (for example, the closer a two billiards get, the greater the probability of a collision, using the blockheader to as a source of randomness to resolve this probability into hit / not hit)
Game input can be command-based or gui, whichever makes most sense. Rules on scoring and endgame can either be traditional or something new. The user should be able to see the current board state and info such as whose turn it is, but animating the intermediate effects of a move (billiards balls moving around and colliding) is not necessary.
All code must be clear, clean, and easy to modify and upgrade. The worker must be reasonably aware of current security challenges (i.e. re-entrancy exploits) and best practices. (mining advantages can be ignored, however; assume all users have insignificant mining power.) If the contract has a severe vulnerability, a significant portion of the payment will be burned.
All code will be treated as licenseless.
The core contract and a pilot interface must be completed two weeks after commitment. If the dapp is functional, stable and meets the above requirements, I will release the payment within one week after delivery.
I recommend you do some beginning design work on the project before committing, to ensure you have a good idea of its scope.
Create an email notifier for newly created BPsCreate a simple server/website where users can enter their email, and will thereafter receive an email notification whenever a new BP has been created. The site must offer two filtering options: 'minimum payment amount' and 'maximum service deposit'; only BPs that meet these filters should trigger a notification to the user.
- The website must be functional within 1 week after commitment, with source code provided.
- It must then operate for an additional week; after this, funds will be released.
- The service must be free to use for this first week.
- The system must be easily reproduced by and independently setup by me (I use Amazon EC2 regularly).
- Code must be reasonably clean and well-documented.
- If the system uses a third-party service to fetch blockchain data, this service must be reasonably expected to continue serving this data in the long-term (i.e. etherscan is fine).
By committing, Worker agrees to give up any creative rights to this project.
Any of the above 'must' clauses not being met will result in a partial or complete burning of the payment.
Email coinop.logan@gmail.com with any questions.
The issue is ALMOST solved. It runs when I test it locally. However, when I upload it to github, I get an error "Only secure origins allowed". See https://github.com/mozilla/pdf.js/issues/8767
I'm releasing the payment, but there is still one small issue. To solve the above issue, the Ethereum backup node needs to be HTTPS enabled. I'm happy to just get an EC2 Ethereum node up and running, unless it's easy for you to enable HTTPS?
30 minute consultation of intermediate/advanced cryptokitties mechanics/trends from an expertI know the basic mechanics of cryptokitties. But there's clearly much more I can learn, if I want to dig in: what attributes seem to be popular? How valuable are the earlier-gen kitties? What other/third-party tools are useful?
Worker must have spent a good amount of time with cryptokitties, to where they could call themselves an "expert" (inasmuch as one can be an expert in a 1-week-old game). They must have useful insights to share beyond basic mechanics--roughly enough to fill a 30-minute voice call of Q&A (it's okay if the call ends early, as long as I feel the education was a good one).
After commitment, email me at coinop.logan@gmail.com to arrange a voice call over Whatsapp or some other messenger. I expect to have a voice call within 5 days after commitment. I will be in the UTC+7 timezone.
I will release the entire payment if the call was entirely satisfactory. I will only burn parts of the payment if the insight seems lacking. I will make this burn/release decision at most 7 days after the consultation.
Email me at coinop.logan@gmail.com with any questions. Serious inquiries only.
That would be a great solution. If the site does explode with popularity, we can deal with it then. If it is getting to such popularity, it would make finding funding easier, part of which could go to funding the node (and possibly the node maintainer?)
I can use an Infura node, and it loads "current" BP action just fine, but can't load the events. Infura doesn't support events; see:
https://github.com/INFURA/infura/issues/13
https://github.com/INFURA/infura/issues/10
Can you possibly find another way of getting events here? I know toastycoin beta (https://gianlucaschoefer.github.io/) does it through etherscan, but if I recall correctly, the APIs don't exactly match up, so it might not be a simple substitution.
Describe plausibility/limits/challenges of decompiling the GeneScience bytecode in cryptokittiesCryptokitties has become something of a phenomenon. It's a fascinating dapp.
Say I wanted to have someone decompile the [GeneScience code](https://etherscan.io/address/0xf97e0a5b616dffc913e72455fde9ea8bbe946a2b#code) that cryptokitties uses to determine the traits of the offspring of a given pair of kitties. Assuming I could find someone knowledgeable enough to attempt this task:
- What are the limits, fundamentally speaking, of decompiling EVM bytecode (or bytecode in general)? For example, I know one can't recover variable/function/class names.
- How difficult is the task in general, assuming the worker has some experience with this sort of thing? If you can translate this into a rough estimation of how much an expert might charge, that'd be great.
I'm really trying to figure out if it's worth opening up a BP to accomplish the task of demystifying the fundamental logic behind cryptokitty breeding.
I'm not going to ask for a specific word count, and the above questions are just my first stabs at the "right" questions. I'm well-versed in computer science (I'm the creator of BPs/Toastycoin), but haven't looked much into anything that happens after compilation.
I'm including 0.8 ETH. I'll release 0.4 ETH each for two responses from the worker--one initial response, and one response after I've asked clarifying questions. The SD will be released unless I get no response at all or the worker clearly has no idea what they're talking about.
For each response, I'm not looking for intensive essays. Maybe a short paragraph or three. Imagine I'm an acquaintance or coworker who's asked in passing, and you have five or ten minutes to spare for a brief overview.
The first response from the worker must be submitted within 12 hours of commitment. The second response must be submitted within 3 days after my follow-up questions. If the worker includes their email I'd be happy to notify them of when I've asked the follow-up questions.
Hey, this looks good. I'm releasing 1.6 ETH total, and will release another 0.3 ETH if the following changes are made within a week from this log:
- Change "Burnable open Payment" to "Burnable Payment" (The images you were using as reference were using the out-of-date and redundant "open"; we're trying to move away from that). Similarly, change all instances of "BOP" to "BP"
- Change the 1/2/3/4/5 steps near the beginning in the following ways:
-- remove the "agreement" step
-- Add a ? after delivery: "delivery?"
-- Change "payment" to "pay/burn"
- Change the background color of the box with the text "If the ether is burned..." to red.
- Change the text of the last, yellow box to "If the payment isn't released or burned by the "auto-release" deadline, funds automatically go to the contractor. This auto-release countdown can be reset by the payer."
Other than that I'm happy with it. Thanks!
I couldn't find any detailed documentation on the metamascara API, so I opened an issue asking whether there was a way to specify via the api to use the mainnet: https://github.com/MetaMask/mascara/issues/14
I've double-checked the commit and burn times, and by 1 week after commitment, Worker had not delivered the work. Worker could have easily written down the time of commitment; "timezone confusion" is a poor excuse. Worker also could have posted some sort of proof of progress, or even a statement apologizing for being late--in either case I'd have either burned a small "warning" amount or even moved the deadline with no burn at all, depending. But with no update at all, combined with the very lazy interpretation of the original request at first, the best assumption was that the work would not be completed. This is why I burned the payment.
Having said all of that, Worker did indeed provide the service. Ignoring the deadline, it meets all my requirements and is even artistically impressive. Seeing the completed product, I'm reluctant to leave Worker at a loss. But at the same time, I've already spent 0.5 ETH, and I'm reluctant to spend *further* ether.
I'm going to add 0.2 ETH to the payment and release it. 0.1 from the service deposit, and an additional 0.1 for project costs. On one hand, I thank Worker for the service. But I want to stress that I'm spending an additional 0.2 ETH that I had not planned to.
The current solution does not allow a new user to view BP data right away. As someone who's never used metamascara before, when I tried out the solution, metamascara seemed to default to a network other than Ropsten or mainnet (network 4, whichever that is).
The ideal solution would be for metamascara to default to the mainnet, but is that possible to specify via the metamascara api? I'd like the worker to look into this, or other simple solutions.
I'd like a timely response from the worker, but the previous deadline can be ignored.
Worker successfully deposited $185 into my bank account. There were problems locating my account, and Worker made several trips to two different banks before making a deposit. For this extra effort I'm adding 0.05 ETH before releasing the full payment.
Solve TC bug at https://github.com/coinop-logan/coinop-logan.github.io/issues/3See issue at https://github.com/coinop-logan/coinop-logan.github.io/issues/3
Figure out what the problem is, submit a pull request that fixes the error, and I'll release the payment.
The reason I immediately burned the majority of the payment is because there is no valid form of Haiku that has a 5/6/6 syllable style. My original request didn't ask for much, but what it did as for was a valid Haiku.
Maybe the worker wasn't aware of what a "favicon" is: https://www.google.com.pe/search?q=define+favicon&rlz=1C1CHBF_enUS750US750&oq=define+favicon&aqs=chrome..69i57j0l5.3012j0j7&sourceid=chrome&ie=UTF-8
The submitted work doesn't look so good scaled down to favicon size. The smoke goes away, so all that's left is a dark orange lower-case T against a black square... https://i.imgur.com/7iQ4j5I.png
The clearly put some effort in, but the result is not satisfactory. I'm returning the service deposit of 50 mETH and an additional 30 mETH for the effort, and burning the rest.
Detailed summary (~1000w) of the major challenges and current progress concerning building a meshnetThe current political status of net neutrality is a bit worrying. If the Internet as we know it becomes crippled, how close are we to building some sort of decentralized alternative?
The Worker must have expert-level understanding of the field, although I don't necessarily require certifications. After delivery of the writeup, I will do a bit of research and get some second opinions as to the validity and worthiness of the writeup, which will greatly inform my burn/release decision.
I'm looking for about 1000 words. Here are some guidelines:
- Links to other completed works, with an included summary, would be great--but I want more than references; I want a good amount of "meta-analysis" as well.
- Quotes are great, but will not count toward the ~1000 word count.
- Plagiarism is obviously not tolerated, but paraphrasing is fine **as long as it's demarcated as such and credited.**
- Commentary on how "close" we are, given certain assumptions, would be nice. For example "If we had 1000 engineers for 3 years"; "with all the money in the world"; "given no governmental influence".
Post your writeup as a Worker statement. Note that markdown formatting, while not yet supported, should be a feature added fairly soon and will retroactively apply.
This should be completed no more than two weeks after commitment. Partial updates (i.e., part 1 of 3) are acceptable, and will receive partial release/burns.
I will fund and release up to an additional 1 ETH if the writeup is not only satisfactory, but outstanding.
After the writeup is posted and the funds are released, I might add additional funds and ask additional questions, and may continue on in this manner for many rounds. However, the initial commit will only be seen as a commitment to the original request.
Email me at coinop.logan@gmail.com with any questions. Serious inquiries only.
If the work is not completed, I'll burn everything. However, there is a roundabout way the Worker might recover his deposit. See the following reddit comments:
https://www.reddit.com/r/ethereum/comments/7dtq1u/introducing_toastycoin_frontier_where_payers_get/dq1rjhs/
Note that if you contribute funds to this BP, you are **trusting me to not recover() the BP while it remains in the Open state**. I realized this when I recover()'d an old version of this BP (http://toastycoin.com/interact.html?address=0xf2d8f4090807c2d7e0f6bf1b15848ec0fc37f45c) to redeploy with a higher service deposit. An unfortunate side effect is that since the original BP was suicided via recover(), so even the record of the donation might disappear. For the record, 0xdc2cf5cbfa31958ed32c3ace696ee6bf1a6a19f4 contributed 5 mETH to this Payment.
Interface upgrade to Toastycoin for a modified version of the Burnable PaymentThe worker must be able to write clean javascript web3 code for modified versions of the create, browse, and interact pages on Toastycoin.
Within 3 days after commitment, I will create a modified version of the Burnable Payment factory, which supports an alternative way of opening up a Burnable Payment. When I deliver this to the worker, the worker must, within 2 weeks, modify the Toastycoin interface to support this behavior. I will give a bonus for an early product.
The new behavior is this: A Worker can initiate a Burnable Payment in an Open state, where it waits for a Payer to commit. The Worker specifies the payment amount the Payer must deposit in order to become the contract's committed Payer. This change only impacts the Open state; Committed and Closed behavior remains unchanged.
Feel free to email me at coinop.logan@gmail.com with questions before commitment.
I will periodically add funds to this payment, and invite others to contribute if they'd like to see this developed as well (see the "Add Funds" button)
I asked for a spraypainted Ethereum wizard. Digital art definitely does not count as spraypainted.
Rather than burn the entire payment, I'll give the worker a chance to spraypaint (meaning with spraypaint cans, in real life) an Ethereum wizard somewhere. It doesn't even have to be good, to get most of the payment now contained in the BP. The original deadline applies.
According to the wikipedia article, a 5/6/6 pattern does not qualify as a Haiku.
The new Haiku qualifies, and I admit I do see a bit more of the symbolism with the new one. I'm adding 10 mETH and releasing the entire payment.
The first stanza of the Haiku doesn't have the 5/7/5 syllable pattern required of a Haiku, and is instead 5/6/6. Also, the last stanza has nothing to do with BPs. Maybe this is a good example of a service deposit that's too low relative to payment (3 mETH for 50 mETH)?
Burning 40 mETH now. I'll release the remainder if the above issues are fixed by the original deadline.
Make an email notification server for BPsWorker must design and implement a server that facilitates email notifications for Burnable Payments.
The user should be able to input an Ethereum user address and email address, and receive notifications via email when any web3 event occurs for any BP they are a Worker or Payer of. The server can charge a fee: I suggest an "X ETH per Y notifications" model.
**The server must use a local Ethereum node to watch for contract events**, rather than scraping Toastycoin/etherscan/etc.
This should be completed no more than 10 days after commitment.
Clean code and decent comments are a must, and the work must be open-source.
Spraypaint an Ethereum wizardSee the Bitcoin Wizard art contest entries at http://whybitcoiniscool.wordpress.com/
The worker must spraypaint an "Ethereum Wizard" somewhere publicly visible. Take one picture of the artwork itself, then one or more to show that it is publicly visible.
I'll release the entire payment if the artwork is reasonably good. I'll burn up to 0.25 if it's not good, but release the rest as long as it's recognizable as an Ethereum Wizard.
The work should be completed/uploaded/linked within 1 week after commitment.
Record a "satanic" video worshiping Game TheoryKneel in the middle of a burning pentagram, raise your arms to the sky and yell "ALL HAIL GAME THEORY!". Clothing optional. The pentagram shape should be clearly visible in the video, and the speech should be understandable. Upload somewhere and submit the link in a worker statement.
The video should be uploaded and linked no more than 1 week after commitment.
Create a tiny Toastycoin icon (favicon)The icon will be used as the favicon for Toastycoin. Should look nice up there. Maybe a tiny coin with smoke drifting off. Should be completed 2 days after commitment.
Create infographics for BP usageSee the "a simple example" page linked to at the top-right of Toastycoin. The worker must produce an infographic that conveys the same information, and which meets the following criteria:
- Easy to read and nice to look at.
- Covers all points seen in the "simple example" page.
- Visible/readable without the user having to zoom in.
- No spelling/grammar errors.
- (briefly) defines what it means to "burn" ether.
The infographic can assume the reader is at least somewhat familiar with Ethereum and smart contracts.
The following two images are good examples of what I'm looking for:
http://imgur.com/I2wADYp
http://imgur.com/SrjpcG4
But these are rather busy and wordy, and far too wide, as well as being out-of-date. I'd also like the new infographics to be a bit more colorful. Feel free to re-use any parts of these old infographics, as long as the above criteria are met.
By submitting this work, Worker agrees to give up all licensing control, but may include credit / contact info (in the image directly, or for me to include after the image).
Worker must submit the infographics no more than two weeks after commitment.
Of the 1.6 I've put into the BP, I'll release 1.4 for a satisfactory infographic, and up to 1.6 if I really like it. The 0.4 deposited via commitment will be released unless Worker does very little or no work at all.
Write a 3-stanza (9-line) Haiku about Burnable PaymentsI'll release the entire payment if it qualifies as a Haiku and isn't total crap. Worker should submit Haiku 24 hours after commitment.