Hey Sabunir!
Hope you are well!
Interested in purchasing some of your pictures.
Cant message you because Im a newbie.
Thanks in advance!
Bap
Topic: A newb's test - anyone want to buy a picture for $1? (Read 21371 times)
So was this the first ever btc sale? https://twitter.com/lohstroh/status/1149746138573987840
It would appear so, thus predating Laslo's Pizza Party by a few months.
*HISTORY*
Popular consensus in Twitter spaces 2023 says, yes it is, now predating Laszlo's Pizza.
Perhaps it was overlooked in the past because the pizza was a "real world good" and this jpeg wallpaper was "only digital".
How times change.
So was this the first ever btc sale? https://twitter.com/lohstroh/status/1149746138573987840
It would appear so, thus predating Laslo's Pizza Party by a few months.
*HISTORY*
So was this the first ever btc sale? https://twitter.com/lohstroh/status/1149746138573987840
I assume you tested it, then, and it did not work? What about decimal? Can I send 0.01 cents? Just give the idea. I will not hang on decimals. That does not seem to be necessary. I think people will use Bitcoin addresses more often than IP addresses when sending or receiving coins. That seems less than ideal. Now, if anyone sends 500 coins and tells me in Private Message when they send it, I'll reply with a link to the picture. Posted by the bitcoin address into the transaction to the network and the receiver discovers it from the network. I would love to find a way to include a short message, but the problem is, the whole world will be able to see the message. Unfortunately, ECDSA can only sign the signature, it can not encrypt the message, and we need the small size of ECDSA.
I don't want to buy the wallpaper for the same reasons I don`t want to buy wallpapers for real money:
There are free sources for very good wallpapers, so why spend money for it ?
There are free sources for very good wallpapers, so why spend money for it ?
Indeed. We could expect more in exchange of our crypto currency and specially for the bitcoin. Buying picture is not big industry and even professional image creators are like uploading their pics over the blog and you can claim them without any copy rights action.
If you want to test it anyway then why not offer some licensed software or something that you have brought and want to resell for some reason. Someone might be interested in doing that kind of trade. You will get your money back as well as you will have the whole thing tested for it.
Hello all. I've decided to give Bitcoin a try. As a test, I want to see if I can make $1 USD from selling a picture. According to this, 500 Bitcoins should roughly be a dollar (after PayPal fees), right?
Does the offer still stand? I need a new background for my iMac.
500 BTC, right? No problem.
Let me just check under the cushions of my couch real quick...
Very interesting. I will inquire more.
I don't want to buy the wallpaper for the same reasons I don`t want to buy wallpapers for real money:
There are free sources for very good wallpapers, so why spend money for it ?
There are free sources for very good wallpapers, so why spend money for it ?
It seems apparent that this offer is not desired. In interest of refining future attempts: Why?
- You don't like the picture?
- You don't accept the price?
- Other reasons?
- You don't like the picture?
- You don't accept the price?
- Other reasons?
I have modified the instructions for payment on my website. Thanks for the suggestion.
The main issue is that the bitcoin application was designed as an end-user P2P program. (And a proof of concept?) I see it being highly successful in this arena.
However, from the perspective of the merchant (myself, and others) payment automation is currently impossible. :/ We could fork off a console-only version or perhaps just put in some defines that can be switched on at compile time to remove the X11/wxwidgets stuff and switch on a control API. I hope for the latter.
Payment automation needs to be addressed to expand the market that accepts bitcoin as a payment method.
Thanks.
However, from the perspective of the merchant (myself, and others) payment automation is currently impossible. :/ We could fork off a console-only version or perhaps just put in some defines that can be switched on at compile time to remove the X11/wxwidgets stuff and switch on a control API. I hope for the latter.
Payment automation needs to be addressed to expand the market that accepts bitcoin as a payment method.
Thanks.
The recommended ways to do a payment for an order:
1) The merchant has a static IP, the customer sends to it with a comment.
2) The merchant creates a new bitcoin address, gives it to the customer, the customer sends to that address. This will be the standard way for website software to do it.
RSA vs ECDSA: it's not the size of the executable but the size of the data. I thought it would be impractical if the block chain, bitcoin addresses, disk space and bandwidth requirements were all an order of magnitude bigger. Also, even if using RSA for messages, it would still make sense to do all the bitcoin network with ECDSA and use RSA in parallel for only the message part. In that case, everything that's been implemented up to now would be implemented exactly as it has been.
We can figure out the best way to do this much later. It could use a separate (maybe existing) e-mail or IM infrastructure to pass messages, and instead of RSA, maybe just put a hash of the message in the transaction to prove that the transaction is for the order described in the message. The message would have to include a salt so nobody could brute force the hash to reveal a short message.
1) The merchant has a static IP, the customer sends to it with a comment.
2) The merchant creates a new bitcoin address, gives it to the customer, the customer sends to that address. This will be the standard way for website software to do it.
RSA vs ECDSA: it's not the size of the executable but the size of the data. I thought it would be impractical if the block chain, bitcoin addresses, disk space and bandwidth requirements were all an order of magnitude bigger. Also, even if using RSA for messages, it would still make sense to do all the bitcoin network with ECDSA and use RSA in parallel for only the message part. In that case, everything that's been implemented up to now would be implemented exactly as it has been.
We can figure out the best way to do this much later. It could use a separate (maybe existing) e-mail or IM infrastructure to pass messages, and instead of RSA, maybe just put a hash of the message in the transaction to prove that the transaction is for the order described in the message. The message would have to include a salt so nobody could brute force the hash to reveal a short message.
Right now I require an email message from customers who send me bitcoins. This is not ideal because if another person knew about a transaction that was occurring, they could take credit for the transaction by sending a message before the person who sent the bitcoins.
Why don't you make them send the email before the transaction? Then you could reply to that email with a new and unique bitcoin address. You don't even need to use email, it would be equally secure, although not that anonymous, to announce the customers email together with the bitcoin address on the frontpage of your site.
The method you are using now is equal to someone sending you cash in an envelope anonymously, including a note with the time he posted it, after which you send goods back to the first person calling you stating the time and amount in the envelope. (Including the mailman and anyone who has access to you mailbox).
Sending the email before the transaction is equal to someone calling you, getting a unique box address which to send the money to. When the money arrives to that post box, you send the goods to the customer.
A balance between extended transaction data while NOT becoming an instant messenger client would be nice.
I certainly wouldn't mind a larger Bitcoin application if it meant we could send an encrypted message along with each transaction. Right now I require an email message from customers who send me bitcoins. This is not ideal because if another person knew about a transaction that was occurring, they could take credit for the transaction by sending a message before the person who sent the bitcoins. About how many MB do you think it would add? Of course these messages will add to the size of the confirmation blocks being stored, so there should probably be a maximum size. Perhaps 256 characters would be a good maximum since the maximum size of an email address is 254 characters.
It would also be nice if transactions included a return address so that if a product or service being purchased can't be delivered the seller could more easily and reliably refund the bitcoins.
It would also be nice if transactions included a return address so that if a product or service being purchased can't be delivered the seller could more easily and reliably refund the bitcoins.
Yes, encryption of messages would be a very good thing... So the problem is not that you can't store the message on the network, but rather, that you do not yet have a good way of encrypting it?
Yes, it's a technical limitation. Sending by bitcoin address enters the transaction into the network and the recipient discovers it from the network. You don't connect directly with them and they don't have to be online at the time.
I very much wanted to find some way to include a short message, but the problem is, the whole world would be able to see the message. As much as you may keep reminding people that the message is completely non-private, it would be an accident waiting to happen.
Unfortunately, ECDSA can only sign signatures, it can't encrypt messages, and we need the small size of ECDSA. RSA can encrypt messages, but it's many times bigger than ECDSA.
I very much wanted to find some way to include a short message, but the problem is, the whole world would be able to see the message. As much as you may keep reminding people that the message is completely non-private, it would be an accident waiting to happen.
Unfortunately, ECDSA can only sign signatures, it can't encrypt messages, and we need the small size of ECDSA. RSA can encrypt messages, but it's many times bigger than ECDSA.
You can't send messages to Bitcoin users unless it's the IP? That seems unnecessary. Any reasoning behind this? I think people will use Bitcoin addresses a lot more often than the IP address when sending or receiving coins.
I think it was some technical limitation. Satoshi could tell more about this?
No messages that way? That seems less than ideal. Very well, what would be a more correct way to do this?
For now, if anyone sends 500 coins and tells me in Private Message the time they sent it, I shall respond with a link to the picture.
For now, if anyone sends 500 coins and tells me in Private Message the time they sent it, I shall respond with a link to the picture.
Jump to: