Yea, with a 0.001 BTC (~$1.42) minimum, this 100x100 pixel pilot could generate $14,200 if all pixels are colored and no pixels are contested. If it scales, in both pixels and interest, a decent amount of donations could be generated.
That said, cryptocurrency is much more niche than, say, an open-access canvas requiring only a Reddit account.
> I think it could be a great way to raise money for some kind of cause though.
I'd like to see some proof that the charity-runner isn't going to abscond with the money once it was done, either due to maliciousness, or even something like getting stressed out over success (like some Kickstarters have done.)
(And yeah, I know - it's not like it's a Bitcoin/blockchain only problem - but at least with "real" money, there's typically a system in place where you can at least start trying to get the money back.)
Another user suggested using Ethereum smart contracts for this. I'm not terribly familiar with Ethereum, but I wonder if the contract could be designed to automatically forward to a Charity-held wallet, or even the wallet of a reputable intermediary like Watsi.
I've done no research, I don't really know much about the whole... ledgersphere?
Seems like it just puts in a mechanism for changing the protocol without forking the chain, but I'm not sure why people couldn't continue running the old protocol, effectively forking it anyway (other than a "look, we all agreed to no forks, you're explicitly a dick if you fork it, not just someone with a disagreement" angle.)
Oh well I was pointing out to the part where their whole codebase is formally prove, plus their Smart Contract language Michelson is functional and can be used very easily to be formally proven (there by leading to writing more secure smart contracts), since you're earlier concern was security.
Would have been much easier with an ethereum smart contract. No gimmicky address list, it's a crowdsourced picture in the blockchain.
contract Place {
struct Pixel {
bytes3 color;
uint lastPayment;
}
Pixel[10000][10000] board;
modifier onBoard(uint x, uint y) {
if (x > 10000 || y > 10000) {
throw;
}
_;
}
// Accepts funds, if the funds sent are greater than funds for that pixel last, change the color.
function colorPixel(uint x, uint y, bytes3 color) payable onBoard(x, y) {
Pixel p = board[x][y];
if (msg.value > p.lastPayment) {
msg.sender.send(p.lastPayment); // refund previous price of pixel
p.color = color; // set the color
p.lastPayment = msg.value; // set new cost to whatever the person sent in
} else {
throw;
}
}
}
May contain an error or two, but that's the general gist of it.
IUUC the current code accumulate the payment to each pixel and whatever color has more accumulated money is chosen.
IIUC your code only consider the last payment and to replace the old color you have to outbid it, without any consideration of the previous payments.
Another strategies:
Penny auction: Whatever color received the last payment is the chosen one. This is more similar to /r/place
Generals.io: If someone adds money to the current color, then increase the accumulated money in that color. If someone adds money to another color the amount is discounted. Unless the result is negative and the color changes.
It's not equivalent to what OP made, the logic is slightly different. It took 5 minutes and it was just to demonstrate how easy it would be to make something similar. If you wanted to mirror OP you could build out the pixel struct to have a color to value mapping.
The penny auction one is even easier:
bytes3[10000][10000] board;
function colorPixel(uint x, uint y, bytes3 color) onBoard(x, y) {
board[x][y] = color;
}
Users would only have to pay the gas cost of using the ethereum network, the contract wouldn't hold any funds itself. Again, it's pretty much whatever you make out of it. You're not really constrained when it comes to building in logic into these contracts, anything (logically) you can do with any other languages is possible here.
> msg.sender.send(p.lastPayment); // refund previous price of pixel
This code suffers from Recursive calling vulnerability (same bug which caused the DAO to be hacked).
You're sending the money BEFORE you're updating the balances.
There is a better way to write the payment code (and also wouldn't take you more than 5 minutes to write).
Here is one way to do it:
function colorPixel(uint x, uint y, bytes3 color) payable onBoard(x, y) {
Pixel p = board[x][y];
lastPayment = p.lastPayment;
p.lastPayment = msg.value;
if (msg.value > lastPayment) {
if(!msg.sender.send(lastPayment)) throw; // refund previous price of pixel
p.color = color; // set the color
} else {
throw;
}
}
Another shorter way:
function colorPixel(uint x, uint y, bytes3 color) payable onBoard(x, y) {
Pixel p = board[x][y];
require(msg.value > p.lastPayment);
if(!msg.sender.send(p.lastPayment)) throw; // refund previous price of pixel
p.color = color; // set the color
p.lastPayment = msg.value; // set new cost to whatever the person sent in
}
Good analysis of the code, and nice correction. Agreed that you should always check your sends' return values, too! In this example you have to send more than the last guy, so I think a recursive call would still put in more ether than would be withdrawn. Still undesired though.
If it were fleshed out more it should probably return the ether to the last depositor instead of the purchaser.
Thanks for the feedback!; I'm tempted to turn this into an example Dapp later today.
It's not obvious enough how to see the image. It's linked from the image at the top and there is a link at the bottom, but you should add something more obvious like "look at the current image!!!"
Also, it would be nice that the image at the top is live, something like a gif autogenerated once a minute.
It'd be fun to make a free version using the same concept by rolling your own proof of work system. You could do something like requiring a unique proof of work to be submitted for each pixel change. To change a pixel you need to generate a random number which hashes to a lower value (when interpreted as a bignum) than the existing holder of the pixel.
The UI for something like that would be great - your client could just constantly generate random hashes and buffer a list of the best values its has come up with. Then the screen could highlight all pixels you can edit. As you wait longer (and generate better and better hashes), you can edit more 'valuable' pixels.
(Of course, that would only work if each hash could only be used once. You could embed the pixel value into the hash's input, but then you'd need to decide which pixels you want to edit before you start generating hashes. And that would be way less fun.)
Hello! Good day, Have you been looking for a Legit Loan Lender? Do you need an Urgent loan or business Loan? Have you be denied of a loan from your bank or any Financial Firm?
We offer private,business,finance, commercial and personal loans with very low annual interest rates as low as 3% in one year to 20 years repayment period and to anywhere in the world. We offer loans of any amount. Our loans are well insured for maximum security is our priority. Are you losing sleep at nights worrying how to get a legit loan lender? Instead of biting your nails,and you can also contact via our email (frankmarkson2@gmail.com) now
28 comments
[ 3.6 ms ] story [ 73.6 ms ] threadThat said, cryptocurrency is much more niche than, say, an open-access canvas requiring only a Reddit account.
I'd like to see some proof that the charity-runner isn't going to abscond with the money once it was done, either due to maliciousness, or even something like getting stressed out over success (like some Kickstarters have done.)
(And yeah, I know - it's not like it's a Bitcoin/blockchain only problem - but at least with "real" money, there's typically a system in place where you can at least start trying to get the money back.)
Seems like it just puts in a mechanism for changing the protocol without forking the chain, but I'm not sure why people couldn't continue running the old protocol, effectively forking it anyway (other than a "look, we all agreed to no forks, you're explicitly a dick if you fork it, not just someone with a disagreement" angle.)
> Updates to the protocol can be required to carry formal proofs indicating that they respect agreed core principles agreed upon by the stakeholders.
Which doesn't really make sense; how do you write a formal proof that something align with someone's core principles?
IUUC the current code accumulate the payment to each pixel and whatever color has more accumulated money is chosen.
IIUC your code only consider the last payment and to replace the old color you have to outbid it, without any consideration of the previous payments.
Another strategies:
Penny auction: Whatever color received the last payment is the chosen one. This is more similar to /r/place
Generals.io: If someone adds money to the current color, then increase the accumulated money in that color. If someone adds money to another color the amount is discounted. Unless the result is negative and the color changes.
The penny auction one is even easier:
Users would only have to pay the gas cost of using the ethereum network, the contract wouldn't hold any funds itself. Again, it's pretty much whatever you make out of it. You're not really constrained when it comes to building in logic into these contracts, anything (logically) you can do with any other languages is possible here.This code suffers from Recursive calling vulnerability (same bug which caused the DAO to be hacked).
You're sending the money BEFORE you're updating the balances.
There is a better way to write the payment code (and also wouldn't take you more than 5 minutes to write).
Here is one way to do it:
Another shorter way:If it were fleshed out more it should probably return the ether to the last depositor instead of the purchaser.
Thanks for the feedback!; I'm tempted to turn this into an example Dapp later today.
Also, it would be nice that the image at the top is live, something like a gif autogenerated once a minute.
Also, how would you protect against faked transactions? Certainly waiting for confirmations is out of the question.
This is not as dynamic as Reddit Place, the code is waiting for 1 confirmation before the pixel is colored.
The UI for something like that would be great - your client could just constantly generate random hashes and buffer a list of the best values its has come up with. Then the screen could highlight all pixels you can edit. As you wait longer (and generate better and better hashes), you can edit more 'valuable' pixels.
(Of course, that would only work if each hash could only be used once. You could embed the pixel value into the hash's input, but then you'd need to decide which pixels you want to edit before you start generating hashes. And that would be way less fun.)