이메일 #141 - #145
원본 출처: Satoshi - Sirius emails 2009-2011
이메일 #141
Date: Thu, 04 Feb 2010 02:20:10 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Exchange ideas
To: Martti Malmi <[email protected]>
영어 원문
You could always exchange for Liberty Reserve. It's an online currency
similar to e-Bullion, Pecunix or Webmoney that allows exchanges no
questions asked and with privacy.
LR and the others are hard to buy but easy to cash out. Hard to buy
because exchangers are very cautious about getting ripped off by
reversed payments, so they require more details and holding time.
Cashing out is very easy. LR is non-reversible, so there are oodles of
exchanges eager to turn LR into any kind of payment.
Bitcoin is the reverse, in that it's easy to get Bitcoins just by
generating them. It would be easy for customers to go
bitcoin->LR->cash, bitcoin->LR->gold, bitcoin->LR->paypal or maybe they
just want to save the money, then just bitcoin->LR.
There's also the idea BTC2PSC had to sell paysafecards for bitcoins.
Either online delivery by sending the card number by e-mail, or delivery
of the unopened physical card in the mails. There are many variations
of these cards. In some countries, they're called Gift Cards, and can
be used wherever credit cards are accepted. I think they're used more
by people who don't have the credit history to get a real credit card,
so they buy gift cards themselves to pay for things that require a
credit card.
이메일 #142
Date: Thu, 04 Feb 2010 01:32:50 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Exchange options
To: Martti Malmi <[email protected]>
영어 원문
Don't rush ahead and get yourself rejected from all the payment options
before you've had time to see if there's a better approach. I suggest
you wait before contacting any more payment processors. You may get
ideas from things other users come up with and try.
Just some random incomplete ideas: There may be a way to position it as
an intermediate credit for micropayments for some virtual good or
something. Or maybe if the payments are only in one direction. If you
only buy bitcoins, then you're only sending money out not taking
people's money, that would still be useful to peg the currency. That
might be payment for computer time.
Credit card is only one way. Don't even talk about the idea of
returning money to customer's credit cards. Credit card companies hate
that.
In any case, any payment processor is going to expect you to be selling
something real.
Do you have electronic transfer or paper cheque in your country? (even
if only within Europe)
이메일 #143
Date: Wed, 03 Feb 2010 20:25:53 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: Bitcoin API
To: [email protected]
영어 원문
Is there any way to find out what the missing shared libraries are? It
would help to know.
It probably needs the gtk libraries, in which case you'll have the same
problem with the 64-bit version. I would like to have a single
executable that can also run on a UI-less system, but I'm not sure how
on linux to link to things but still be able to run and not use them if
the library is not present. Maybe we should statically link the GTK.
Licensewise, it's LGPL, but since it's only used on unix, that would be
OK. (we can't link LGPL stuff on windows because we provide the OpenSSL
DLL, but on linux OpenSSL comes with the OS)
My 64-bit (debug stripped) executable is attached. It includes untested
changes that are not in SVN yet: UI changes and the wallet fSpent flag
resync stuff.
I've been researching options for interprocess calling. I want
something that will be easy for a variety of server side languages to
call, particularly PHP. Cross-platform to windows is a plus.
I'm not sure if I want it to be something that can be accessed across
the network. That would introduce security issues. If it can only be
accessed on the local system, then local security authentication covers
it, and it is incapable of being hacked remotely.
At surface level, not looking into any details yet, the current front
runners are:
D-Bus:
local system only
used by qt, gnome and skype
bindings: c, python, java, c++,
php listed as "in progress"
.net listed as unmaintained
not sure how ready it is on windows
XML-RPC:
widely used, built in libraries on PHP
it's more for web clients to talk to server, transport is http, so
its a security question
Is it possible to open a socket that can only be accessed locally?
[email protected] wrote:
> Have you decided upon the inter-process calling method of the Bitcoin
> API yet? An easy solution would be the socket interface provided by
> wxWidgets: http://docs.wxwidgets.org/trunk/overview_ipc.html. The
> Bitcoin program running a wxServer could be then accessed by calling the
> bitcoin executable from the command line or by coding your own wxClient
> app.
>
> Another option would be to just use the plain BSD sockets.
>
> Can you send me a 64-bit Linux binary of Bitcoin if you have one? I
> tried compiling on the VPS, but it ran out of memory. Tried the 32-bit
> version (with ia32-libs) also, but it didn't find the shared libraries.
>
이메일 #144
Date: Thu, 04 Feb 2010 19:47:36 +0200
From: [email protected]
To: Satoshi Nakamoto <[email protected]>
Subject: Re: Bitcoin API
영어 원문
> Is there any way to find out what the missing shared libraries are? It
> would help to know.
This is what "ldd bitcoin" says:
linux-gate.so.1 => (0xf778c000)
libcrypto.so.0.9.8 => /usr/lib32/i686/cmov/libcrypto.so.0.9.8
(0xf762a000)
libgtk-x11-2.0.so.0 => not found
libgthread-2.0.so.0 => not found
libSM.so.6 => /usr/lib32/libSM.so.6 (0xf7621000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7533000)
libm.so.6 => /lib32/libm.so.6 (0xf750f000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7502000)
libc.so.6 => /lib32/libc.so.6 (0xf73b0000)
libdl.so.2 => /lib32/libdl.so.2 (0xf73ac000)
libgdk-x11-2.0.so.0 => not found
libXinerama.so.1 => /usr/lib32/libXinerama.so.1 (0xf73a8000)
libgdk_pixbuf-2.0.so.0 => not found
libX11.so.6 => /usr/lib32/libX11.so.6 (0xf72b9000)
libpango-1.0.so.0 => not found
libgobject-2.0.so.0 => not found
libglib-2.0.so.0 => not found
libpthread.so.0 => /lib32/libpthread.so.0 (0xf72a1000)
libpng12.so.0 => /usr/lib32/libpng12.so.0 (0xf727e000)
libz.so.1 => /usr/lib32/libz.so.1 (0xf7269000)
libICE.so.6 => /usr/lib32/libICE.so.6 (0xf7251000)
/lib/ld-linux.so.2 (0xf778d000)
libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7243000)
libxcb-xlib.so.0 => /usr/lib32/libxcb-xlib.so.0 (0xf7241000)
libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7229000)
libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7226000)
libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7220000)
Notfounds seem to be gtk-libraries indeed. I have those files in my
/usr/lib folder, but maybe they're ignored because they're 64bit, or
maybe only /usr/lib32 is searched. I haven't tested on other 64bit
machines.
> My 64-bit (debug stripped) executable is attached. It includes
> untested changes that are not in SVN yet: UI changes and the wallet
> fSpent flag resync stuff.
The package doesn't open, it says "not in gzip format".
> Is it possible to open a socket that can only be accessed locally?
Yes, you can use IPC sockets ("Unix domain sockets") which are local
only. That's done in the wx-api by using a filename in place of a port
number. I committed an example of how the wxServer-Client
communication is used, you can revert if you want to. Now there's the
-blockamount command line option which asks the running instance for
the block chain length.
I think this command line method could already be used from PHP, but
it might be lighter if php itself could call the socket server
directly. The wx's IPC overview mentions wxSocketEvent, wxSocketBase,
wxSocketClient and wxSocketServer as being "Classes for the low-level
TCP/IP API", which might be easier to use from php than what I used
now (wxServer, wxClient, wxConnection). I'll look more into it.
이메일 #145
Date: Thu, 04 Feb 2010 18:50:35 +0000
From: Satoshi Nakamoto <[email protected]>
Subject: Re: Bitcoin API
To: [email protected]
영어 원문
I must have accidentally typed j instead of z. It's bz2 format. Rename
to .tar.bz2 or just do tar -jxvf
> The package doesn't open, it says "not in gzip format".
>