Washington state, usa.

I just made grapefruit / orange marmalade.

It is very tasty; I high-heat canned it in 8 oz new, clean jars. It was made with organic sugar and fruits, and has no added pectin.

125 BTC / jar plus shipping at cost (using bitcoinmarket's previous-day close for conversion rates)

Precisely! Bring on the offers. I'm happy to provide MS's excellent Compiler to the Bitcoin community.

To get to .04, I totaled up all the bids on bitcoinmarket starting with the highest one: so what I said isn't speculation, it's just a fact of the current market.

Your first block would sell for something like 0.06 or so, but there just isn't that much liquidity in the market, so by the time you were selling your 5000th bitcoin, you'd be pretty far down into the bid sheet.

It doesn't say MSDN on it, just Professional.

Okay, I updated a bit on how the Seller thinks about things.

I'm open to all offers.

But, let me do some math.

Selling 10,000 BTC on BitcoinMarket right now would drive the price down to .04 / BTC. Total amount generated would be $503.1 before any paypal transaction fees, and of course, you'd need to get paid by 21 people if I understand bitcoinmarket correctly.

Amazon lists the software at $499 in the typically competitive "used / new" market.  I do want to offer some discount to BTC users, so I'll reprice to BTC 8500 / Best Offer.

I won this MSVisual Studio 2008 at a developer contest earlier this year, and don't need it. It's never been installed.

It is an MS Company Store Purchase, and has a large 'not for resale' sticker on it. These stickers are a request from MS, not legally enforceable.


Price: 10,000 BTC + shipping at $.06/BTC.

I might describe it as the following conversation:

Buyer: "Hey, have you heard of account 24225...21?"

Seller: ... checks ... "yup."

Buyer: "So, we both know it has like 200 BTC in it, right?"

Seller: ... checks ... "yup."

Buyer: "So, I'm in control of that account, and I'm going to prove it by transferring 180BTC to you."

Seller: "Okay. I'm in control of account 1244...231. Tell everyone that you're moving 180BTC over to it."

Buyer: "Done."
Seller: ... checks ...  "Cool, here's your stuff."


--- Meanwhile ---
The Buyer has sent out a notification that 24225..21 should have 180 BTC transfered to 1244...231 and the rest should be transfered back to 24225...21. And he's proven that he has the rights to do this because he's signed the message with the private key for 24225...21, something nobody else should be able to do.

--- Also Meanwhile ---
As blocks are generated, this transaction is verified, and included in a block. At that point, the transfer becomes 'truth' and gains 'truthiness' the more blocks are generated on top of the one creating this transaction.

-- Is it Real? --
The seller knows that even one block confirmation from a generally trustworthy source means something, but as time goes on, he hears from more and more people that the block with the transaction is part of everyone's accepted reality. At some point, the seller concludes that it's really unlikely that the payment block was faked, and he turns over the goods, or stops worrying about it.

Actually, the Manga (and manga 'fan-fic') copyright situation is quite different in Japan than in America.

Japan has a much more tolerant view of derivative works than America does, as one example.

Also, historically with Anime at least, Japanese copyright holders have been happy to seed interest in their Anime in America through online trading. Anime filesharing has a long, occasionally uneasy relationship with these Japanese content creators. If you go to a site like animesuki.com, you'll see that they will take torrents down if Anime becomes licensed in the USA.

I'm not sure I have more to add of interest here, but it's not a good idea to apply RIAA/MPAA style thinking when you imagine Japanese copyright holders -- totally different culture.

Just a comment that this would be easier to test if difficulty were set to '1' in the client.

Anyone able to send me a compiled version of this for windows? I'm interested to try it out on my AMD server.

I encountered this as well: there's no documentation as to what auth string should be accepted in the case of no user.

It's probably best to require rpcuser and rpcpassword in future versions is my two cents. This is generally what's expected from an HTTP Auth anyway.

What you say is true, but urllib2 does send Content Length.

In my case, we had a datatypes problem which Gavin helped me find: params needs to get a list in python, so

"params" : []

will work.
"params" : ""

did not.

With that amendation, my second sample code works well now. Hope it's helpful to others.

Thanks for the pointer, interesting, but not what seems to be affecting me.

Here's my current code (running on Google App Engine)

postdata = jsonrpc.dumps({"method": 'getbalance', "params":'','id':'jsonrpc'})
req = urllib2.Request('http://127.0.0.1:8332', postdata)
userpass = 'user:a'.encode('base64')[:-1]
authheader =  "Basic %s" % userpass
req.add_header("Authorization",authheader)
handle = urllib2.urlopen(req)
json_response = handle.read()
self.response.out.write (json_response)

This yields a HTTPError: HTTP Error 500: Internal Server Error

from the GAE local python script.


using
   postdata = jsonrpc.dumps([{"jsonrpc": "2.0","method": 'getbalance', "params":'','id':'1'}])

Yields the same result.

Update: Here is the current state of my hackish code:

postdata = jsonrpc.dumps({"method": 'getbalance', "params":'','id':'jsonrpc'})

req = urllib2.Request('http://127.0.0.1:8332', postdata)
      

base64string = base64.encodestring( '%s:%s' % ('username','rpcpassword'))[:-1]
authheader =  "Basic %s ." % base64string
req.add_header("Authorization",authheader)
      
handle = urllib2.urlopen(req)
      
print handle.read()


If username or password is wrong, then I get an Authorization error from the server as expected.

Otherwise, I get nothing, just a closed connection.

Any leads or tips?

Hi all,

Does anyone have jsonrpc or something similar working with HTTP Authentication? I'm trying to hit up my bitcoin server with python over JSON-RPC, and of course, getting authorization errors from the new server.

I couldn't find much about this online, surprisingly, so thought I'd ask here.

One thought on this would be to keep the test network at a low difficulty, and have a big "TEST" vs "REAL" button in the client.

This would let someone futz around with the system and when they're ready move over to REAL, with the associated warnings (it can take a long time, we estimate it will take blah days..)

Also helps solve the abandoned bitcoin deflation problem.

I started working on a solution to this today. I'll update here when I have some news.

And, for those saying 'just keep your nose clean,' that's entirely not the point.

Regarding the US government, the Patriot Act really did make it much harder to get money outside of the US -- a move that was welcomed by large banks (it pushed small banks out of the international wire business), and the IRS alike. It did it via the mechanism I described. Ask your local banker if they will wire money to Afghanistan for you if you'd like to understand just how hard this is to accomplish in America.

Okay.

In that case, I revise my best practices to:

0) use all new bitcoin addresses
1) find a trustworthy bitcoin exchange market
2) transfer in
3) transfer out, if they delete logs
3a) if not, sell bitcoins for USD
3b) transfer out USD
3c) send money to trustworthy bitcoin exchange market
3d) purchase bitcoins

Comments?

Just to say, I currently believe based on reading the spec that everyone will know

1) Sender sent 100 BTC to _random_ip
2) Receiver's address sent 100 BTC to 'new_address'

But that these would not otherwise be correlated. Is this correct?