ok do all that with this- Thanks for starting that topic on ASC, your understanding of bitcoin is
spot on.  Some of their responses were rather Neanderthal, although I
guess they're so used to being anti-fiat-money that anything short of
gold isn't good enough.  They concede that something is flammable, but
argue that it'll never burn because there'll never be a spark.  Once
it's backed with cash, that might change, but I'd probably better
refrain from mentioning that in public anymore until we're closer to
ready to start.  I think we'll get flooded with newbies and we need to
get ready first.
What we need most right now is website writing.  My writing is not that
great, I'm a much better coder.  Maybe you could create the website on
sourceforge, which is currently blank.  If you can write a FAQ, I can
give you a compilation of my replies to questions in e-mail and forums
for facts and details and ideas.
Codewise, there's not much that's easy right now.  One thing that's
needed is an interface for server side scripting languages such as Java,
Python, PHP, ASP, etc.  Bitcoin would be running on the web server, and
server side script could call it to do transactions.  It's Windows, so I
guess OLE/COM is the interface.
One easy thing that really helps is to run a node that can accept
incoming connections (forward port 8333 on your firewall) to make sure
that new users who try it out have someone to connect to.  If they run
it and get no connections, they'll probably just give up.
That would be great!  I added you (dmp1ce) as a dev to the sourceforge
project and gave you access to edit the web space and everything.
Definitely.  This will be an absolutely essential feature once things
get going, making it so you can lock your wealth up with strong
encryption and back it up more securely than any physical safe.  So far
I've been putting it off in favour of other features because it's not
crucial yet until bitcoins start to have value.
I plan to work on the escrow feature next, which is needed to make
actual trades for physical stuff safer and before backing the currency
with fiat money can begin.
Thanks!  Right now there are a lot of people on the network who can't
receive incoming connections, so every node that can really helps.
Having more helps keep down the "(not accepted)" issue for now until I
reduce the chances of that happening in v0.1.6.
I guess one answer for the FAQ should be how to set up your firewall to
forward port 8333 so you can receive incoming connections.  The question
could be something like "what if I have 0 connections" and that could be
the answer that it might be because the nodes you can connect with is
limited if you don't set that up.
Here's a compilation of questions I've answered in forums and e-mail
that should help you see what questions are frequently asked and some
answers I've used.  It's not intended to use all or most of the material
here, just pick and choose.  This is just a dump of everything I've
answered.
Some issues that we don't have easy answers for are best not to bring
up.  Casual users seems content to assume that the system works as
stated (which it does), and getting into the design details just opens a
can of worms that can't be answered without a deep understanding of the
system.  The advanced questions I've received have mostly been unique
per person and best answered individually.
It's the total number of blocks in the block chain, meaning the
network's block chain, which everyone has a copy of.  Every Bitcoin node
displays the same number and it goes up about every 10 minutes whenever
someone generates a block.  When you haven't had it running for a while,
once you're connected it spins up rapidly as it downloads what was
generated while you were gone to catch up.  I'm not sure exactly how to
describe it (that would fit on the status bar in 1 word, maybe 2 words
max), any ideas?
The blocks number in the status column next to your transactions is the
number of blocks that have come after that transaction.  Your
transaction is essentially "in" that many blocks.
Right.  I'm trying to think of more clear wording for that, maybe "%d
network blocks" or "%d block chain".
What rate of not-accepted did you see?  I didn't see anything unusual on
my end.  If you had more than, say, 4 in a row, that would be abnormal
and probably a loss of network communication.  If it's scattered and
less than 25%, just random bad luck.  It's normal and harmless to
randomly get some per cent of not-accepted, and of course randomness can
sometimes bunch up and look like a pattern.
The idea of an option to View/Hide unaccepted blocks is a good one, as
well as View/Hide all generated blocks so you can more easily see
incoming transactions.  Seeing the unaccepted blocks is just annoying
and frustrating.  Everyone faces the same rate of unaccepted, it's just
a part of the process.  It would probably be best to default to hide
unaccepted blocks, so as not to show giving and taking away something
that never was, and not show new generated blocks at all until they have
at least one confirmation.  It would only mean finding out you have a
generated block 15 minutes later than normal, and then you still have
119 blocks to go before it matures anyway.  This is on the to-do list
for v0.1.6.
[note: I have some improvements in 0.1.6 to reduce this problem somewhat,
and it'll also improve when the network is larger]
Transactions sent to a bitcoin address will always say "from: unknown".
The transaction only tells who it's to.  Sending by bitcoin address
has a number of problems, but it's so nice having the fallback option to
be able to send to anyone whether they're online or not.  There are a
number of ideas to try to improve things later.  For now, if things work
out like the real world where the vast majority of transactions are with
merchants, they'll pretty much always make sure to set up to receive by
IP.  The P2P file sharing networks seem fairly successful at getting a
large percentage of their users to set up their firewalls to forward a port.
I badly wanted to find some way to include a comment with indirect
transfers, but there just wasn't a way to do it.  Bitcoin uses EC-DSA, which
was essential for making the block chain compact enough to be practical with
today's technology because its signatures are an order of magnitude smaller
than RSA.  But EC-DSA can't encrypt messages like RSA, it can only be used
to verify signatures.
The "Generated (not accepted)" normally happens if two nodes find a
block at close to the same time, one of them will not be accepted.  It's
normal and unavoidable.  I plan in v0.1.6 to hide those, since they're
just confusing and annoying and there's no reason for users to have to
see them.  While the network is still small like it is now, if you can't
receive incoming connections you're at more of a disadvantage because
you can't receive block announcements as directly.
Right, the credit field stays 0.00 until it matures, then it'll be
50.00.  BTW, you can doubleclick on a line for details.
There is only one global chain.
The existing Visa credit card network processes about 15 million
Internet purchases per day worldwide.  Bitcoin can already scale much
larger than that with existing hardware for a fraction of the cost.  It
never really hits a scale ceiling.  If you're interested, I can go over
the ways it would cope with extreme size.
By Moore's Law, we can expect hardware speed to be 10 times faster in 5
years and 100 times faster in 10.  Even if Bitcoin grows at crazy
adoption rates, I think computer speeds will stay ahead of the number of
transactions.
I don't anticipate that fees will be needed anytime soon, but if it
becomes too burdensome to run a node, it is possible to run a node that
only processes transactions that include a transaction fee.  The owner
of the node would decide the minimum fee they'll accept.  Right now,
such a node would get nothing, because nobody includes a fee, but if
enough nodes did that, then users would get faster acceptance if they
include a fee, or slower if they don't.  The fee the market would settle
on should be minimal.  If a node requires a higher fee, that node would
be passing up all transactions with lower fees.  It could do more volume
and probably make more money by processing as many paying transactions
as it can.  The transition is not controlled by some human in charge of
the system though, just individuals reacting on their own to market forces.
A key aspect of Bitcoin is that the security of the network grows as the
size of the network and the amount of value that needs to be protected
grows.  The down side is that it's vulnerable at the beginning when it's
small, although the value that could be stolen should always be smaller
than the amount of effort required to steal it.  If someone has other
motives to prove a point, they'll just be proving a point I already concede.
My choice for the number of coins and distribution schedule was an
educated guess.  It was a difficult choice, because once the network is
going it's locked in and we're stuck with it.  I wanted to pick
something that would make prices similar to existing currencies, but
without knowing the future, that's very hard.  I ended up picking
something in the middle.  If Bitcoin remains a small niche, it'll be
worth less per unit than existing currencies.  If you imagine it being
used for some fraction of world commerce, then there's only going to be
21 million coins for the whole world, so it would be worth much more per
unit.  Values are 64-bit integers with 8 decimal places, so 1 coin is
represented internally as 100000000.  There's plenty of granularity if
typical prices become small.  For example, if 0.001 is worth 1 Euro,
then it might be easier to change where the decimal point is displayed,
so if you had 1 Bitcoin it's now displayed as 1000, and 0.001 is
displayed as 1.
Ripple is interesting in that it's the only other system that does
something with trust besides concentrate it into a central server.
For the actual risk, multiply the 0.1% by the probability that the buyer
is an attacker with a huge network of computers.
For micropayments, you can safely accept the payment immediately.  The
size of the payment is too small for the effort to steal it.
Micropayments are almost always for intellectual property, where there's
no physical loss to the merchant.  Anyone trying to steal a micropayment
would probably not be a paying customer anyway, and if they want to
steal intellectual property they can use the file sharing networks.
Currently, businesses accept a certain chargeoff rate.  I believe the
risk with 1 or even 0 confirming blocks will be much less than the rate
of chargebacks on verified credit card transactions.
The usual scam against a merchant that doesn't wait for confirming
blocks would be to send a payment to a merchant, then quickly try to
propagate a double-spend to the network before the merchant's copy. What
the merchant can do is broadcast his transaction and then monitor the
network for any double-spend copies.  The thief would not be able to
broadcast during the monitoring period or else the merchant's node would
receive a copy.  The merchant would only have to monitor for a minute or
two until most of the network nodes have his version and it's too late
for the thief's version to catch up and reach many nodes.  With just a
minute or two delay, the chance of getting away without paying could be
made much too low to scam.  A thief usually needs a high probability of
getting an item for free to make it worthwhile.  Using a lot of CPU
power to do the brute force attack discussed in the paper in addition to
the above scam would not increase the thief's chances very much.
Anything that grants access to something, like something that takes a
while to download, access to a website, web hosting, a subscription or
service, can be cancelled a few minutes later if the transaction is
rejected.
It's not communicated.  The formula is hardcoded in the program and
every node does the same calculation to know what difficulty is required
for the next block.  If someone diverged from the formula, their block
would not be accepted by the majority.
It's free open source.  It's the MIT license, which just requires some
disclaimer text be kept with the source code, other than that you can do
just about anything you want with it.  The source is included in the
main download.
I'll always announce new versions there.  Automatic update, or at least
notification of new versions, is definitely on the list.
[this inflation discussion was before the transaction fee mechanism and
fixed plan of 21 million coins was posted, so it may not be as
applicable anymore]
You're still thinking as if the difficulty level will be so easy that
people will be able to generate all the bitcoins they want.
Imagine you have to run your computer 24/7 for a month to generate 1
cent.  After a year, you could generate 12 cents.  That's not going to
make it so people can just generate all the bitcoin they want for spending.
The value of bitcoins would be relative to the electricity consumed to
produce them.  All modern CPUs save power when they're idle.  If you run
a computational task 24/7, not letting it idle, it uses significantly
more power, and you'll notice it generates more heat.  The extra wattage
consumed goes straight to your power bill, and the value of the bitcoins
you produce would be something less than that.
No, they can't make money that way.  It would cost them more in
electricity than they'd be selling the bitcoins for.
Historically, people have taken up scarce commodities as money, if
necessary taking up whatever is at hand, such as shells or stones.  Each
has a kernel of usefulness that helped bootstrap the process, but the
monetary value ends up being much more than the functional value alone.
Most of the value comes from the value that others place in it.  Gold,
for instance, is pretty, non-corrosive and easily malleable, but most of
its value is clearly not from that.  Brass is shiny and similar in
colour.  The vast majority of gold sits unused in vaults, owned by
governments that could care less about its prettiness.
Until now, no scarce commodity that can be traded over a communications
channel without a trusted third party has been available.  If there is a
desire to take up a form of money that can be traded over the Internet
without a TTP, then now that is possible.
Actually, that is handled.  There's a moving average that compensates
for the total effort being expended so that the total production is a
constant.  As computers get more powerful, the difficulty increases to
compensate.
There's gold for one.  The supply of gold increases by about 2%-3% per
year.  Any fiat currency typically averages more inflation than that.
to solve the proof-of-work problem faster?
The difficulty is controlled by a moving average that compensates for
the total effort being expended to keep the total production constant.
As computers get more powerful, the difficulty increases to compensate.
Identities are not used, and there's no reliance on recourse.  It's all
prevention.
There is no reliance on identifying anyone.  As you've said, it's
futile and can be trivially defeated with sock puppets.
The credential that establishes someone as real is the ability to
supply CPU power.
This is a version 2 problem that I believe can be solved fairly
satisfactorily for most applications.
The race is to spread your transaction on the network first.  Think 6
degrees of freedom -- it spreads exponentially.  It would only take
something like 2 minutes for a transaction to spread widely enough
that a competitor starting late would have little chance of grabbing
very many nodes before the first one is overtaking the whole network.
During those 2 minutes, the merchant's nodes can be watching for a
double-spent transaction.  The double-spender would not be able to
blast his alternate transaction out to the world without the merchant
getting it, so he has to wait before starting.
If the real transaction reaches 90% and the double-spent tx reaches
10%, the double-spender only gets a 10% chance of not paying, and 90%
chance his money gets spent.  For almost any type of goods, that's
not going to be worth it for the scammer.
Information based goods like access to website or downloads are
non-fencible.  Nobody is going to be able to make a living off
stealing access to websites or downloads.  They can go to the file
sharing networks to steal that.  Most instant-access products aren't
going to have a huge incentive to steal.
If a merchant actually has a problem with theft, they can make the
customer wait 2 minutes, or wait for something in e-mail, which many
already do.  If they really want to optimize, and it's a large
download, they could cancel the download in the middle if the
transaction comes back double-spent.  If it's website access,
typically it wouldn't be a big deal to let the customer have access
for 5 minutes and then cut off access if it's rejected.  Many such
sites have a free trial anyway.
[in response to a question about scale]
100,000 block generating nodes is a good ballpark large-scale size
to think about.  Propagating a transaction across the whole network
twice would consume a total of US$ 0.02 of bandwidth at today's
prices.  In practice, many would be burning off excess allocated
bandwidth or unlimited plans with one of the cheaper backbones.
There could be millions of SPV clients.  They only matter in how
many transactions they generate.  If they pay 1 or 2 cents
transaction fees, they pay for themselves.  I've coded it so you
can pay any optional amount of transaction fees you want.  When the
incentive subsidy eventually tapers off, it may be necessary to put
a market-determined transaction fee on your transactions to make
sure nodes process them promptly.
To think about what a really huge transaction load would look like,
I look at the existing credit card network.  I found some more
estimates about how many transactions are online purchases.  It's
about 15 million tx per day for the entire e-commerce load of the
Internet worldwide.  At 1KB per transaction, that would be 15GB of
bandwidth for each block generating node per day, or about two DVD
movies worth.  Seems do-able even with today's technology.
Important to remember, even if Bitcoin caught on at dot-com rates
of growth, it would still take years to become any substantial
fraction of all transactions.  I believe hardware has already
recently become strong enough to handle large scale, but if there's
any doubt about that, bandwidth speeds, prices, disk space and
computing power will be much greater by the time it's needed.
It's not like a race where if one car is twice as fast, it'll always
win.  It's an SHA-256 that takes less than a microsecond, and each guess
has an independent chance of success.  Each computer's chance of finding
a hash collision is linearly proportional to it's CPU power.  A computer
that's half as fast would get half as many coins.
[question about what to backup]
The files are in "%appdata%\Bitcoin", that's the directory to
backup.
%appdata% is per-user access privilege.  Most new programs like
Firefox store their settings files there, despite the headwind of
Microsoft changing the directory name with every Windows release
and being full of spaces and so long it runs off the screen.
[question about what to backup]
The directory is "%appdata%\Bitcoin"
It has spaces in it so you need the quotes
On XP it would typically be:
Backup that whole directory.  All data files are in that
directory.  There are no temporary files.
[question about what to backup]
The crucial file to backup is wallet.dat.  If bitcoin is running
then you have to backup the whole %appdata%\bitcoin directory
including the database subdirectory, but even if it's not running
it certainly feels safer to always backup the whole directory.
The database unfortunately names its files "log.0000000001".  To
the rest of the world, "log" means delete-at-will, but to database
people it means delete-and-lose-everything-in-your-other-files.  I
tried to put them out of harm's way by putting them in the
database subdirectory.  Later I'll write code to flush the logs
after every wallet change so wallet.dat will be standalone safe
almost all the time.
Hal sort of alluded to the possibility that it could be seen as a
long-odds investment.  I would be surprised if 10 years from now
we're not using electronic currency in some way, now that we know
a way to do it that won't inevitably get dumbed down when the
trusted third party gets cold feet.
Once it gets bootstrapped, there are so many applications if you
could effortlessly pay a few cents to a website as easily as dropping
coins in a vending machine.
[this next bit turned out to be very controversial.  there is extreme
prejudice against spam solutions, especially proof-of-work.]
It can already be used for pay-to-send e-mail.  The send dialog is
resizeable and you can enter as long of a message as you like.
It's sent directly when it connects.  The recipient doubleclicks
on the transaction to see the full message.  If someone famous is
getting more e-mail than they can read, but would still like to
have a way for fans to contact them, they could set up Bitcoin and
give out the IP address on their website.  "Send X bitcoins to my
priority hotline at this IP and I'll read the message personally."
Subscription sites that need some extra proof-of-work for their
free trial so it doesn't cannibalize subscriptions could charge
bitcoins for the trial.
[again, I don't know why I'm including this, as it's best to stay
away from claims about spam.  people automatically react violently
against any suggestion of a spam solution.]
Then you could earn a nice profit by setting up pay-per-send
e-mail addresses and collecting all the spam money.  You could
sell it back to spammers who don't have big enough botnets to
generate their own, helping bootstrap the currency's value.  As
more people catch on, they'll set up more and more phony addresses
to harvest it.  By the time the book "How I got rich exploiting
spammers and you can too" is coming out, there'll be too many fake
addresses and the spammers will have to give up.
One more factor that would mitigate spam if POW tokens have value:
there would be a profit motive for people to set up massive
quantities of fake e-mail accounts to harvest POW tokens from
spam.  They'd essentially be reverse-spamming the spammers with
automated mailboxes that collect their POW and don't read the
message.  The ratio of fake mailboxes to real people could become
too high for spam to be cost effective.
The process has the potential to establish the POW token's value
in the first place, since spammers that don't have a botnet could
buy tokens from harvesters.  While the buying back would
temporarily let more spam through, it would only hasten the
self-defeating cycle leading to too many harvesters exploiting the
spammers.
Interestingly, one of the e-gold systems already has a form of
spam called "dusting".  Spammers send a tiny amount of gold dust
in order to put a spam message in the transaction's comment field.
If the system let users configure the minimum payment they're
willing to receive, or at least the minimum that can have a
message with it, users could set how much they're willing to get
paid to receive spam.
Ironic if we end up having to choose between economic liberty and
conservation.
Unfortunately, proof of work is the only solution I've found to
make p2p e-cash work without a trusted third party.  Even if I
wasn't using it secondarily as a way to allocate the initial
distribution of currency, PoW is fundamental to coordinating the
network and preventing double-spending.
If it did grow to consume significant energy, I think it would
still be less wasteful than the labour and resource intensive
conventional banking activity it would replace.  The cost would be
an order of magnitude less than the billions in banking fees that
pay for all those brick and mortar buildings, skyscrapers and junk
mail credit card offers.
Indeed, Bitcoin is a distributed secure timestamp server for
transactions.  A few lines of code could create a transaction with
an extra hash in it of anything that needs to be timestamped.
I should add a command to timestamp a file that way.
From a thread on p2presearch which starts with my rant about trust
being the root weakness of all conventional financial systems.
I've developed a new open source P2P e-cash system called Bitcoin.  It's
completely decentralized, with no central server or trusted parties,
because everything is based on crypto proof instead of trust.  Give it a
try, or take a look at the screenshots and design paper:
Download Bitcoin v0.1 at http://www.bitcoin.org
The root problem with conventional currency is all the trust that's
required to make it work.  The central bank must be trusted not to
debase the currency, but the history of fiat currencies is full of
breaches of that trust.  Banks must be trusted to hold our money and
transfer it electronically, but they lend it out in waves of credit
bubbles with barely a fraction in reserve.  We have to trust them with
our privacy, trust them not to let identity thieves drain our accounts.
Their massive overhead costs make micropayments impossible.
A generation ago, multi-user time-sharing computer systems had a similar
problem.  Before strong encryption, users had to rely on password
protection to secure their files, placing trust in the system
administrator to keep their information private.  Privacy could always
be overridden by the admin based on his judgment call weighing the
principle of privacy against other concerns, or at the behest of his
superiors.  Then strong encryption became available to the masses, and
trust was no longer required.  Data could be secured in a way that was
physically impossible for others to access, no matter for what reason,
no matter how good the excuse, no matter what.
It's time we had the same thing for money.  With e-currency based on
cryptographic proof, without the need to trust a third party middleman,
money can be secure and transactions effortless.
One of the fundamental building blocks for such a system is digital
signatures.  A digital coin contains the public key of its owner.  To
transfer it, the owner signs the coin together with the public key of
the next owner.  Anyone can check the signatures to verify the chain of
ownership.  It works well to secure ownership, but leaves one big
problem unsolved: double-spending.  Any owner could try to re-spend an
already spent coin by signing it again to another owner.  The usual
solution is for a trusted company with a central database to check for
double-spending, but that just gets back to the trust model.  In its
central position, the company can override the users, and the fees
needed to support the company make micropayments impractical.
Bitcoin's solution is to use a peer-to-peer network to check for
double-spending.  In a nutshell, the network works like a distributed
timestamp server, stamping the first transaction to spend a coin.  It
takes advantage of the nature of information being easy to spread but
hard to stifle.  For details on how it works, see the design paper at
The result is a distributed system with no single point of failure.
Users hold the crypto keys to their own money and transact directly with
each other, with the help of the P2P network to check for double-spending.
It's similar in that it uses digital signatures for coins, but different
in the approach to privacy and preventing double-spending.  The
recipient of a Bitcoin payment is able to check whether it is the first
spend or not, and second-spends are not accepted.  There isn't an
off-line mode where double-spenders are caught and shamed after the
fact, because that would require participants to have identities.
To protect privacy, key pairs are used only once, with a new one for
every transaction.  The owner of a coin is just whoever has its private key.
Of course, the biggest difference is the lack of a central server.  That
was the Achilles heel of Chaumian systems; when the central company shut
down, so did the currency.
There is a limited supply of money.  Circulation will be 21,000,000
coins.  Transactions only transfer ownership.
Thank you for your questions,
Indeed, it is much like Pekunio in the concept of spraying redundant
copies of every transaction to a number of peers on the network, but the
implementation is not a reputation network like Wizard Rabbit Treasurer.
In fact, Bitcoin does not use reputation at all.  It sees the network
as just a big crowd and doesn't much care who it talks to or who tells
it something, as long as at least one of them relays the information
being broadcast around the network.  It doesn't care because there's no
way to lie to it.  Either you tell it crypto proof of something, or it
ignores you.
As trust systems go, Ripple is unique in spreading trust around rather
than concentrating it.
[I've been asked at least 4 other times "have you heard of Ripple?"]
It's fully operational and the network is growing.  If you try the
software, e-mail me your Bitcoin address and I'll send you a few coins.
We just need to spread the word and keep getting more people interested.
Here's a link to the original introduction of the paper on the
Cryptography mailing list.  (Inflation issues were superseded by changes
I made later to support transaction fees and the limited circulation
plan.  This link is a moving target, this archive page is just a certain
number of days back and the discussion will keep scrolling off to the
next page.)
A little follow up when the software was released.
My description of how Bitcoin solves the Byzantine Generals' problem:
Oh crap, I got your sourceforge usernames mixed up, sorry about that.  I
clicked on the wrong e-mail when I was looking for your username.  You
now have access.
Your FAQ looks good so far!
You can create whatever you want on bitcoin.sourceforge.net.  Something
to get new users up to speed on what Bitcoin is and how to use it and
why, and clean and professional looking would help make it look well
established.  The site at bitcoin.org was designed in a more
professorial style when I was presenting the design paper on the
Cryptography list, but we're moving on from that phase.
You should probably change the part about "distribute them under several
keys".  When the paper says that it means for the software to do it, and
it does.  For privacy reasons, the software already uses a different key
for every transaction, so every piece of money in your wallet is already
on a different key.  The exception is when using a bitcoin address,
everything sent to the same bitcoin address is on the same key, which is
a privacy risk if you're trying to be anonymous.  The EC-DSA key size is
very strong (sized for the future), we don't practically have to worry
about a key getting broken, but if we did there's the advantage that
someone expending the massive computing resources would only break one
single transaction's worth of money, not someone's whole account.  The
details about how to backup your wallet files is in the Q&A dump and
also it's explained in readme.txt and definitely belongs in the FAQ.
Oh I see, you're trying to address byronm's concern on freedomainradio.
I see what you mean about the password feature being useful to address
that argument.  Banks let anyone who has your name and account number
drain your account, and you're not going to get it back from Nigeria.
If someone installs a keylogger on your computer, they could just as
easily get your bank password and transfer money out of your account.
Once we password encrypt the wallet, we'll be able to make a clearer
case that we're much more secure than banks.  We use strong encryption,
while banks still let anyone who has your account info draw money from
your account.
They have Wordpress built in, you might not need to set up any database
stuff manually.  I enabled the Wordpress feature and added you as an
admin, account sirius-m, e-mail sirius-m@users.sourceforge.net.  I'm not
sure how it works out the password for access, maybe it's just based on
being logged in to sourceforge.
They also have support for MediaWiki if you want it.
In case you still need it, here's the accounts and passwords for mysql.
# Access this project's databases over the Internet
We shouldn't try to use security against identity theft as a selling
point, since it leads into these counter arguments.  The current banking
model is already tested and the actual loss percentage is known.  Even
if ours is probably better, it's an unknown, so people can imagine
anything.  The uncertainty about what the average loss percentage will
be is greater than the likely loss percentage itself.
It's already an improvement, and like you say, there must be better
themes to choose from.
It would be good to make the download link go directly to the download area:
https://sourceforge.net/project/showfiles.php?group_id=244765
I haven't found any way to gain admin control over the mediawiki
feature.  It thinks I'm a different S_nakamoto from the one that has
admin access:
I tried deleting and re-enabling the feature, no help.  Oh well.
You're right, that was it.  I went in and granted us access using the
alternate account.
I like your idea of at least moving the FAQ into the wiki.  I've seen
other projects that use the wiki for the FAQ or even the whole site.  If
you can figure out how to make it so regular users can edit things, then
anyone who wants to can help.
The site layout is looking nicer.  More impressive looking.
There are a lot of things you can say on the sourceforge site that I
can't say on my own site.  Even so, I'm uncomfortable with explicitly
saying "consider it an investment".  That's a dangerous thing to say and
you should delete that bullet point.  It's OK if they come to that
conclusion on their own, but we can't pitch it as that.
A few details: the FAQ says "see section 2.3", but the sections aren't
numbered.  Also, could you delete the last sentence on the FAQ "They are
planned to be hidden in v0.1.6, since they're just confusing and
annoying and there's no reason for users to have to see them." -- that's
not really something I meant to say publicly.
The links to sites to help set up 8333 port forwarding is great.
favicon is a nice touch.
Someone came up with the word "cryptocurrency"... maybe it's a word we
should use when describing Bitcoin, do you like it?
Sourceforge is so slow right now I can't even get the login page to
load.  Maybe due to the site reorg they just did.  I'll keep trying and
try to get you that logo stats thing.
Thanks, I've been really busy lately.
I registered username "satoshi".  Since there's no SSL login, I want to
mainly use that account with sub-admin powers and use the admin account
as little as possible.  I created a "Moderators" group to give my
satoshi account as much editing control as possible without the ability
to overthrow everything.
There's something weird with the download bar on the right covering
things up, like on the new account registration it covers up the entry
fields unless you make the browser really wide, and the homepage it
covers up the screenshots.  (with Firefox)
I know this sounds really retarded, but I still haven't been able to get
the sourceforge login page to load, so I haven't been able to read it
either.  https://sourceforge.net/account/login.php
Hal isn't currently actively involved.  He helped me a lot defending the
design on the Cryptography list, and with initial testing when it was
first released.  He carried this torch years ago with his Reusable Proof
Of Work (RPOW).
I'm not going to be much help right now either, pretty busy with work,
and need a break from it after 18 months development.
It would help if there was something for people to use it for.  We need
an application to bootstrap it.  Any ideas?
There are donors I can tap if we come up with something that needs
funding, but they want to be anonymous, which makes it hard to actually
do anything with it.
That's a good point that since you know how many coins exist and how
fast new ones are created, you could set a support price based on the
amount of legacy currency you have and be sure you'll have enough to
meet all demands.  I had imagined an auction, but it would be far
simpler and more confidence inspiring to back it at a specific exchange
rate.
Offering currency to back bitcoins would attract freebie seekers, with
the benefit of attracting a lot of publicity.  At first it would mostly
be seen as a way to get free money for your computer's idle time.  Maybe
pitched like help support the future of e-commerce and get a little
money for your computer's spare cycles.  As people cash in and actually
get paid, word would spread exponentially.
It might help to keep the minimum transaction size above an amount which
a typical user would be able to accumulate with one computer, so that
users have to trade with each other for someone to collect enough to
cash in.  Aggregators would set up shop to buy bitcoins in smaller
increments, which would add confidence in users ability to sell bitcoins
if there are more available buyers than just you.
People would obviously be sceptical at first that the backing will hold
up against an onslaught of people trying to get the free money, but as
the competition raises the proof-of-work difficulty, it should become
clear that bitcoins stay scarce.  People will see that they can't just
get all the bitcoins they want.  It would establish a minimum value
under bitcoins enabling them to be used for other purposes if,
hopefully, other purposes are waiting for something to use.
That would be more powerful if there was also some narrow product market
to use it for.  Some virtual currencies like Tencent's Q coin have made
headway with virtual goods.  It would be sweet if there was some way to
horn in on a market like that as the official virtual currency gets
clamped down on with limitations.  Not saying it can't work without
something, but a ready specific transaction need that it fills would
increase the certainty of success.
Basically like an eBay site with user reviews to try to establish which
sellers can be trusted.  The escrow feature will help but not solve
everything.  It would be far more work to set up such a site than just
to set up a single exchange site of your own, and there won't be enough
users to make it go until later.  I'm thinking it wouldn't make sense to
make an eBay type site until later.
Even if you had automation, you'd probably want to review orders
manually before processing them anyway.  It wouldn't be hard to process
orders by hand, especially at first.  You could always set a minimum
order size to keep orders more infrequent.
That's great, I could probably get a donor to send currency to you which
you convert to euros and pay out through methods that are convenient for
users.  I don't want to do an exchange business myself, but it can be
done independently of me.  Like you say, there is more software
development to be done first, and also I'd like to keep trying for a
while to think of a bootstrap application to use bitcoins for.  I've had
some ideas that could only be done before an exchange exists.
BTW, I tried to buy bitcoin.com before I started but there was no
chance, it's owned by a professional domain speculator.  It's normal for
open source projects to have .org so it's not so bad.
Glad that worked, it's a pain that the dependencies are so big and hard
to build.  Some of them give little attention to the Windows build.
Next time I update to the latest versions, maybe I'll lay everything out
in one directory tree and bundle the whole thing up into a giant archive.
I'm not sure they had wxPack before.  I'm glad they got that so everyone
doesn't have to build wxWidgets themselves.  OpenSSL is the harder one
to build.
I reduced the EXE size by running strip.exe on it to take out the debug
symbols.  That's with mingw.  That's the better compiler, I only used VC
for debugging.
Now that I think about it, you've put your finger on the most important
missing feature right now that would make an order of magnitude
difference in the number of nodes.  Without auto-run, we'll almost never
retain nodes after an initial tryout interest.  Auto-running as a
minimized tray icon by default was the key to success for the early file
sharing networks.  It wouldn't have been appropriate for v0.1.0 when
stability wasn't a given yet, but now it's good and stable.  This is a
must-have feature for the next release so any users that come back to
try the new version we hopefully retain this time.
I think the most user friendly way of doing auto-run is putting an icon
in the Startup folder.  I see OpenOffice.org and a number of other
things on my computer do it that way.  The other way, creating a runas
registry entry, is not easily visible or editable by users, I've never
liked that much.  I guess what we want is an auto-run option that's on
by default, if the option is changed then it creates or deletes the
startup icon.
While it's tempting to do a Linux port, once we do it we have that extra
work with every release from then on.  I'd rather put it off a while
longer.  Auto-run might give us 300% more nodes while Linux might give
us 3% more.  Linux would help server farms, but actually we'd like to
favour individual users.  Someone reported that it works fine in WinE.
That's great, that's a good step forward.
Yes, I worked out the sourceforge login problem, it was some tricky
thing on the login page that exposed a quirky bug in a browser add-in.
Thanks for that.  I'm still merging in some changes I had that need to
go in before any next release.  Some things based on questions and
feedback I've received that'll reduce confusion.  I'll probably enable
multi-proc generating support, and hopefully make it safe to just backup
wallet.dat to backup your money.  It's good to be coding again!
I'm going to hide the transaction fee setting, which is completely not
needed and only serves to confuse people.  It was only there for testing
and demonstration of a technical detail that can only be needed in the
far away future, if ever, but was necessary to implement at the
beginning to make it possible later.
What was the problem with the shortcut in the startup folder?  If you
could send me the code, I'd like to take another look and see if I can
see what the problem was.  The first strcat in the registry code should
be strcpy, otherwise it would fail intermittently.  If the same code was
in the shortcut one, maybe that was the problem.
It's encouraging to see more people taking an interest such as that
NewLibertyStandard site.  I like his approach to estimating the value
based on electricity.  It's educational to see what explanations people
adopt.  They may help discover a simplified way of understanding it that
makes it more accessible to the masses.  Many complex concepts in the
world have a simplistic explanation that satisfies 80% of people, and a
complete explanation that satisfies the other 20% who see the flaws in
the simplistic explanation.
I got it, I see you checked in the startup folder code before changing
it to registry.  I don't see any visible problems in the code.  I guess
it depends what exactly the problem was with it not always working by
default.  Was there a Vista/UAC security problem?
It's possible Bitcoin ran and bailed out because something was wrong.
debug.log should tell something if that was the case.  What OS are you
using?  I wonder if we need Admin privilege and don't realize it.  Stuff
that requires Admin can't start on startup on Vista.
Program shortcuts have multiple tabs of settings with lots of little
details.  I'll try the startup folder code and see if I can reproduce
the problem.  Every other systray icon on my computer is in the startup
folder, and it makes it easy for users to manage all their autoruns in
one place.  The things in the registry key tend to be devious hidden
bloatware.
I implemented the code to flush wallet.dat whenever it's closed so we'll
be able to tell users they only need to backup wallet.dat.  You can
restore just wallet.dat and it'll re-download the rest.  I'll have to do
another stress test before release.
Yeah, I put back your startup folder shortcut code and it started fine
for me too on XP and Vista.  For good measure, I changed it to make the
shortcut settings look identical to one I manually created.  I set the
working directory to where the EXE is since that's where debug.log is
created, otherwise windows puts it in some weird directory.  I didn't
change the setup script yet.
I checked everything in to SVN (thanks for setting that up)
- multi-proc generate
- flush wallet.dat after every change so the DB doesn't leave that stuff
in the transaction logs
- view menu checkbox to hide all generated coins so you can see just
your payment transactions
- disabled transaction fee option
- made the minimize to tray options similar to Firefox's MinimizeToTray
- bunch of other misc changes since the 0.1.5 release
I made it not show non-accepted generated coins.  It won't show
generated coins until they have at least one confirmation (one block
linked after it), so usually they'll just never be seen.  Occasionally a
generated coin that was displayed might disappear because it became not
accepted later.  I don't think anyone would notice the occasional
non-accepteds if we didn't point them out in the UI.  People have told
me they find it annoying to have to look at them, as they're permanently
displayed in the transaction record.
I still have more testing to do.  I guess we gotta test Windows 7 now.
I haven't had any reports of crashes in v0.1.5.  It's been rock solid
for me on Windows.  I think it must be Wine related.  If you get another
crash in Wine and it prints anything on the terminal, e-mail me and I
may be able to figure out what happened, maybe something I can work
around.  Martti and I have been working on a new version to release soon
and it would be nice to get any Wine fixes in there.
Those don't look like anything to worry about.  Probably functions
unimplemented by Wine that are harmlessly stubbed out.
You can delete debug.log occasionally if you don't want to take the disk
space.  It's just status messages that help with debugging.
bitcoin.sourceforge.net looks fine now.  Maybe sourceforge was doing
some maintenance.
Doesn't work right now.
Sourceforge is just so darn slow.  I don't know what else to do though.
It's such a standard, more often than not any given project has a
projectname.sourceforge.net site.  When I see whatever.sourceforge.net
in a google search, I assume that's the official site.
Is there a way to make Bitweaver allow users to edit (and maybe delete)
their own messages in the forum?
Getting antsy to port to Linux?  It's not a decision to be taken lightly
because once it's done, it doubles my testing and building workload.
Although I am worried about Liberty's Wine crashes.
I've tried to be as portable as possible and use standard C stuff
instead of Windows calls.  The threading is _beginthread which is part
of the standard C library.  wxWidgets has wxCriticalSection stuff we can
use.  The sockets code is send/recv stuff which I think is the same as
unix because Microsoft ported sockets from BSD.  We need direct control
over sockets, it wouldn't be a good idea to get behind an abstraction
layer.  wxWidgets is a good place to look for cross-platform support
functions.  I want to avoid #ifdefing up the code if we can.  Anything
that's used more than once probably becomes a function in util.cpp that
has the #ifdef in it.
BTW, I have a lot of uncommitted changes right now because it includes
some crucial protocol transitions that can't be unleashed on the network
until I've tested the heck out of it.  It shouldn't be too much longer.
Can you make the setup uninstall the Startup folder icon?  I figure it
should install and uninstall an icon in a regular program group, and
just uninstall the Startup folder one.  I guess it doesn't matter that
much whether it installs and uninstalls the Startup folder icon or just
uninstalls it.
I'll convert the CriticalSection code to wxCriticalSection and upload it
to SVN (it's a little tricky).  I don't know what to do for
TryEnterCriticalSection though.  I think I'm almost ready to check
everything in.
You're probably right, it's about time to do a linux build.  I've been
working on getting my linux machine set up and building the dependencies.
The easy solution I took was to look at the wxWidgets source code and
see how they did it.  They just mapped it to wxMutex on non-MSW, which
does have TryEnter, so that mapped in perfectly.
I checked in all my backlog of changes to SVN, including the overhaul of
CCriticalSection in util.h and OpenSSL's mutex callback in util.cpp to
do everything with wxWidgets when not on Windows.
If we get it working on Linux, I'll run my test suite against it here
off-network first, then we can give an unreleased build to
LibertyStandard to test for a while before going public.
I fixed some non-portable stuff I came across:
If there's any other unportable stuff you know of I should fix, let me know.
I think I'll move debug.log and db.log into the same directory as the
data files (%appdata%\Bitcoin), rather than whatever the current
directory happens to be.
heapchk() is just a MSVCRT debugging thing that's not being used.  It
can be a no-op on Linux.  OpenSSL automatically uses /dev/urandom to
seed on Linux, so RandAddSeedPerfmon can also be a no-op.
Don't let it connect to the network before we've tested it thoroughly
off-net.  If you have two computers, unplug the internet and use
"bitcoin -connect=<iplinux.  -connect will allow you to connect to non-routable addresses
like 192.168.x.x.  We don't want to reflect badly on the reliability of
the network if it throws off some malformed crud we hadn't thought to
check for yet, or discovers something else anti-social to do on the network.
I have time that I can do some testing when you've got something
buildable to test.  I can include it in the stress test I'm currently
running on the changes so far.
Great, I've been looking forward to working on the Linux build.
If you connect to Freenode's hidden service, then they tell you they've
also banned TOR from that due to abuse and it kicks you off.  There's a
several step procedure you can do to run a password utility on unix and
e-mail request an account that you could login with, but that's getting
pretty complicated.  I wonder if we could get away with applying for one
account and then everyone use the same account?  I suppose the IRC
server probably limits accounts to one login, or some admin might not
like to see a dozen logins on the same account.
Besides the IRC part, how did your test of proxy go?  Since you've been
connected before, your addr.dat contains known node addresses, but
without IRC to know which ones are online, it takes a long time to find
them.  There are normally 1 to 3 other nodes besides you that can accept
incoming connections, and existing nodes that already know you would
eventually connect to you.  How many connections did you get, and how
long did it take?  I guess to know whether it successfully connected
outbound through TOR you'd need to search debug.log for "connected".
To originally connect with TOR without connecting normally once to get
seeded, you'd have to know the address of an existing node that can
accept incoming connections and seed it like this:
bitcoin -proxy=127.0.0.1:9050 -addnode=<ip of a node
If some nodes that accept incoming connects were willing to have their
IP coded into the program, it could seed automatically.  Or some IP seed
addresses posted on a Wiki page with the instructions.
Another option is to search the world again for an IRC server that
doesn't ban TOR nodes.  Or if we could get someone to set one up.  IRC
servers ban TOR because they have actual text chat on them... if there
was one with just bots and junk then it wouldn't care.  Probably should
post a question on the forum or the mailing list and see if anyone knows
one.
Another problem is that TOR users can't accept incoming connections, and
we have so few that can.  If everyone goes to TOR, there won't be any
nodes to connect to.
We have a shortage of nodes that can accept incoming connections.  It
generally ranges from 2 to 4 lately.  We need to emphasize the
importance to people of setting up port forwarding on their router.
Every P2P file sharing program has instructions how to do it.  We should
have a paragraph on the bitcoin.sourceforge.net homepage urging people
to set up port forwarding to accept incoming connections, and a link to
a site that describes how to do it for each router.
It was almost there.  I fixed a few things and got it to finish
compiling but I don't know the system libraries to link to so there's
undefined references galore.
I changed the makefile to look for things under /usr/local and in their
default "make install" locations.  I wrote what I did and switches I
used in build-unix.txt.  I'm currently using wxWidgets 2.8.9 for now
because it's the same version as on Windows and I don't want to wonder
if there's version change issues at the same time as platform change.
2.8.10 or 2.9.0 are probably fine though.  I went with the
single-library compile of wxWidgets since we're linking to almost every
library anyway.
I added xpm files, which is what they use everywhere else but Windows
instead of RC files.  They're clever C files that define graphics in
static arrays.  The bitcoin icon has 5 different versions but I couldn't
figure out how that works in xpm so I only put the biggest one.  Maybe
on GTK it scales it for you.  I don't know if these are right or what,
but they compile.
Just letting you know I'm still working on the Linux build so we don't
duplicate work.  I got it linked and ran it and working through runtime
issues like getting it switched to load bitmaps from xpm instead of
resources.
There are debian packages available for some of the dependencies instead
of having to compile them ourselves:
I need to see if Berkeley DB or Boost have packages.
We'll shared-link OpenSSL, I'm pretty sure it's always preinstalled on
Linux.  GTK has to be shared linked.  I'm not completely sure if it's
preinstalled by default.
I merged the linux changes into the main trunk on SVN.  It compiles and
runs now.  I think all the problems are in the UI.  The menus quickly
quit working and it doesn't repaint when it's supposed to unless I
resize it, and the UI is getting some segfaults.  Shouldn't be too hard
to debug with gdb.  I haven't tested if it plays nice with other nodes
yet so keep it off-net.
build-unix.txt and makefile.unix added
debug.log moved to the data directory "%appdata%/bitcoin/debug.log"
7 inbound and 2 outbound sounds about as expected.
My last SVN commit included an overhaul of the code that selects the
order of addresses to connect to, trying them in the order of most
recently seen online, so it should get connected in a more reasonable
amount of time if IRC is unavailable.  IRC is really only needed to seed
the first connection, but we've been using it as a crutch to get
connected faster.
That would be great.  It's only TOR users that need it, so in the
instructions saying "bitcoin -proxy=127.0.0.1:9050 -addnode=<someipsomeip could be an actual static IP, with the wiki free-for-all
add-your-ip list nearby or a link to it.  There should be a link to that optional step, add your IP to this list now that you can accept incoming
if you're static.
Do you think anonymous people are looking to be completely stealth, as
in never connect once without TOR so nobody knows they use bitcoin, or
just want to switch to TOR before doing any transactions?  It's just if
you want to be completely stealth that you'd have to go through the
-proxy -addnode manual seeding.  It would be very easy to fumble that
up; if you run bitcoin normally to begin with it immediately
automatically starts connecting.
Now that the forum on bitcoin.sourceforge.net is catching on, we really
should look for somewhere that freehosts full blown forum software.  The
bitweaver forum feature is just too lightweight.  I assume the "Forum"
tab on the homepage can link out to wherever the forum is hosted.
I've seen projects that have major following just from forum talk and
pie-in-the-sky planning without even having any code yet.  Having a lot
of forum talk gives a project more presence on the net, more search
hits, makes it look big, draws new users in, helps solve support
questions, hashes out what features are most of wanted.
It would be a big plus if it could support SSL, at least for the login
page if not sitewide.  Multiple people on the forum have expressed
interest in TOR/I2P, and those users need SSL because a lot of TOR exit
nodes are probably password scrapers run by identity thieves.  A lot of
the core interest in Bitcoin is going to be from the privacy crowd.
Any ideas where we can get a free forum?  Maybe we should look at where
some other projects have their forums hosted for ideas where to look.
It works reliably on Linux now, except if it uses wxMessageBox() outside
the GUI thread, it'll crash because non-GUI threads can't open a window
on Linux.  I haven't got to fixing that yet.  I've been running my
stress test on it and it's functioning normally.
Most of wxWidgets is not thread-safe to use in threads other than the UI
thread, but as a rule of thumb on Windows anything not UI related is OK.
It turns out its more thread-unsafe on GTK.  I replaced a bunch of
stuff at once so I don't know if it was just one thing (probably
Repaint), but I have to assume even any wx function that uses wxString
is not safe to use outside the UI thread.  So dang, there goes all the
nice wxWidgets portability support functions.  I left a few simple
things like wxThread::GetCPUCount() that I checked the source and it's
all numerical, and wxMutex has to be safe or it'd be useless.
There's an issue that if you exit and run it again right away, it can't
bind port 8333.  The port frees up after about a minute.  Unless I'm
missing something, I am closing the socket before exit, so I don't know
what else I can do.  Maybe this is just something about Linux that it
takes a minute to free up a port you had bound.  Possibly a security
feature so some trojan doesn't kill the web server and quickly jump into
its place and pick up all the client retries.
Still gotta figure out how to do the xpm version of the icon correctly.
I wonder if the database dat files are interchangeable with Windows.
bitcoin-linux-0.1.6-test1.tar.bz2 attached
The Linux build is ready for testing on the network.  It seems solid.  I
sent the executable as an attachment in the previous e-mail, but if the
mail server didn't let it through (it's 12MB), you can download it here:
In the debug.log, it requests the block list, receives the block list,
then begins uploading the list of blocks requested.  It doesn't receive
the blocks, but it didn't run long enough for me to be sure it would
have had time yet.  Everything else looks normal.
How long did you run it?  It could take a few minutes to start
downloading the blocks.  Especially if you're on a cable modem, the
uplink can be much lower bandwidth so it would take some time to upload
the block request list.
If you run it again and it still doesn't download blocks, keep it
running for several hours at least and then send me the debug.log.  That
should give it time for my node to connect to you and I could see what
it says on my side and correlate it with your debug.log.
You're right about the minimize on close option, there's no reason that
can't be separate.  Martti originally had it separate and I made it a
sub-option, my bad.  I'll change it back.
I'm not really a fan of that type of forum layout.  The thread list only
fits about 4 threads on a page, posts are treated like news articles or
blog posts with reply comments at the bottom.  It's more of a social
networking site, not really conducive to technical discussion.
I'm thinking phpBB or IPB or similar.  One line of text per thread,
small fonts, efficient use of vertical space.  Most people are already
familiar with the interface.
About how long did it take to start?  It could be the node that you
happened to request from is slow.  The slow start is consistent with the
slow download speed.
I'd like to look at your current debug.log file and try to understand
what's going.  It might just be a really slow connection on the other
side, or maybe something's wrong and failed and retried.  Taking too
long could confuse other users.
Martti, how long did it take to start downloading blocks when you ran
it, and how fast did it download?
It already uses SO_REUSEADDR so it can bind to the port if it's in
TIME_WAIT state after being closed.  The only time it should fail to
bind is when the program really is already running.  It's important that
two copies of Bitcoin not run on the same machine at once because they
would be modifying the database at the same time.  There is never any
need to run two on one machine as coin generation will now use multiple
processors automatically.
I'm not sure what those lib errors are, I'll do some searching.
Thanks for that, I see what happened.  Because the first one was slow,
it ended up requesting the blocks from everybody else, which only bogged
everything down.  I can fix this, I just need to think a while about the
right way.
There's no risk in shutting down while there are unconfirmed.  When you
make a transaction or new block, it immediately broadcasts it to the
network.  After that, the increasing #/confirmed number is just
monitoring the outcome.  There's nothing your node does during that time
to promote the acceptance.
Now that I think about it, when you close Bitcoin, it closes the main
window immediately but in the background continues running to finish an
orderly flush and shutdown of the database.  Before I implemented that,
it was annoying having a dead hung unresponsive window hanging around.
Until it finishes the orderly shutdown in the background, the port would
be locked, and this is an important protection to make sure another copy
can't touch the database until it's done.  I haven't seen the shutdown
take more than a few seconds.
In Wine, there's no way for the Windows version to do SO_REUSEADDR, so
that would add 60 seconds (on my system) of TIME_WAIT after the port is
closed.
If you need to transfer between two copies, you could send it to the
other's bitcoin address.  The receiving copy doesn't have to be online
at the time.
The command line to use a different data directory is
For example, on Linux, the default directory is (don't use ~)
You shouldn't normally have any need to use this switch.  It still won't
let you run two instances at once.
You really don't want to keep running in Wine, you're getting database
errors (db.log).  You probably developed these rituals of transferring
to a fresh install to cope with database corruption.  If there is a way
to lose unconfirmed blocks, it would have to be the database errors.
Any problems you find in the Linux build can be fixed.  The Wine
incompatibility deep inside Berkeley DB is unfixable.
I think GCC 4.3.3 on the Linux build optimized the SHA-256 code better
than the old GCC 3.4.5 on Windows.  When I was looking for the best
SHA-256 code, there was a lot of hand tuned highly optimized SHA1 code
available, but not so much for SHA-256 yet.  I should see if I can
upgrade MinGW to 4.3.x to get them on a level playing field.
You got a lot done with the Linux build, autostart, minimize to tray,
setup and everything, it's really appreciated.  Good luck on your C++
project.
I see what happened.  All your sockets went dead somehow.  You had no
communication with the network, but because you had 8 zombie
connections, it thought it was still online and kept generating blocks.
You can tell this is happening when your blocks are numbered
sequentially, without other people's blocks interspersed, like:
It's implausible that you would be the only one to find blocks for 6
blocks in a row like that.
When you exited and restarted, it connected and downloaded 45 blocks
that the network found in your absence.  Since your blocks were not
broadcast to the network immediately, the network went on without them.
It sounds like you had exactly the same problem on Wine.  There's
clearly something about socket handling on Linux that's effecting it
either way.
I'll start researching this.  Ultimately if I can't find the root of the
problem, I'll have to make some kind of mechanism to watch for an
absence of messages and disconnect.  The only workaround for you right
now would be to exit and restart more often.
All but one of your node connections went dead at the same time, one
shortly after.  IRC was still working, so it wasn't that you were
offline from the internet.
I wonder if the status of blocks should say "#/unconfirmed" all the way
up to maturity (119/unconfirmed then 120 blocks) instead.  The meaning
of the number isn't as strong for blocks as for transactions.
I think it would be an improvement not to count one's own blocks as
confirmations.  A drawback would be that the status numbers shown by
different nodes would not match.  The status number would no longer be
coordinated with the maturity countdown on blocks either.  A lighter
option would be a special case only if all confirmations are your own.
I fixed a few places I found where it was possible for a socket to get
an error and not get disconnected.  If your connections go dead again,
it should disconnect and reconnect them.  I also implemented an
inactivity timeout as a fallback.
This also includes a partial fix for the slow initial block download.
You should run with the "-debug" switch to get some additional debug.log
information I added that'll help if there are more problems.
Right now (04:50 GMT) my node is connecting to yours and getting zombie
connections each time.  The socket isn't returning an error, just zombie
without notice.  If you're running the linux build right now, it would
be interesting to see what the log says on your side.
test3:
I've added specific code to detect zombie sockets.  It'll detect if the
socket hasn't sent or received any data within 60 seconds of connecting,
and detect if data is queued to send and hasn't sent for 3 minutes.
I think I may have weakened the reconnect speed in test2.  In test3 I'm
making it more determined to reconnect quickly.
I added checking to track whether other nodes received your generated
blocks.  If none did, it'll warn you in the description:
"Generated - Warning: This block was not received by any other nodes and
will probably not be accepted!"
The status can go to "#/offline?" for blocks or transactions you create
if they don't get out to any other nodes.
With all this, it should be impossible not to notice as soon as it
screws up.  It should hopefully disconnect all the zombie sockets.
After that, whether it's able to make some good connections, or sockets
is completely hosed and it stays at 0 connections, I don't know.
If this doesn't work, I guess I'll look at the sourcecode of some other
P2P apps like BitTorrent and see how they deal with this stuff.  Maybe
there's some magic flag or procedure to bash the sockets system back to
life.
I added MSG_DONTWAIT to the send and recv calls in case they forgot the
socket is non-blocking.  If that doesn't work, there's now the catch-all
solution: another thread monitors the send/recv thread and terminates
and restarts it if it stops.  It prints "*** Restarting
ThreadSocketHandler ***" in debug.log, and an error message displays on
the status bar for a while.
Before terminating, it tries closing the socket that's hung.  If that
works, it doesn't have to resort to terminating.
I ran a test where it terminated the thread about 1000 times without
trouble, so it should be safe.  The terminate on linux is
pthread_cancel, which throws it into C++'s exception handler.
The thread calls we were using didn't have terminate, so I created our
own wrappers in util.h to use CreateThread on windows and pthread_create
on linux, instead of:
_beginthread is windows only and lacks terminate
boost::thread is really attractive, but lacks terminate
wxThread requires you to create a class for every function you might
call (yuck)
I created a forum on Zetaboards, InvisionFree's new site that they're
migrating to.
I made an admin account you can use to upgrade your own account to admin:
BTW, the admin pages have a huge blank space at the top, you have to
scroll down.
It doesn't support SSL, but none of them do.  I replaced the ugly
default orange and blue theme with the Frostee theme, which was the only
decent looking theme I could find after extensive searching.  Searching
for themes is futile, there are thousands of rubbish themes.  It turns
out the solution is to look at button sets instead
(http://resources.zetaboards.com/forum/1000328/)
I only created two subforums to begin with.  I'll create new ones as the
need arises.  I like to start with a flat namespace until there's enough
items to justify subsections.  Technical Support makes sense as a
separate section to get that stuff out of the main spotlight so our
dirty laundry isn't in everyone's face, and to make people feel more
free to report bugs there.  Mostly only devs and people checking on a
bug need read the Technical Support section.
linux-0.1.6-test5 solved Liberty's zombie socket problem.  The
MSG_DONTWAIT fixed the root cause, it's not having to terminate and
restart the thread.  The sockets are marked non-blocking already, so I
don't understand why.  Maybe it forgot.  I suppose if a socket fails and
the OS closes it then there's nothing left to remember it was
non-blocking, but then accessing a closed handle should return
immediately with an error.  There's no MSG_DONTWAIT on Windows, marking
the socket as nonblocking is the only way, so if anyone runs the Windows
version in Wine it will have to rely on terminating the thread.
The only problem now is the DB exceptions he's getting.
I had expected those to be a Wine problem, but he's getting them on
Linux just the same.  He tried moving the datadir to a different drive,
no help.  I've never gotten them.  I'm running a stress test that
continuously generates a lot of activity and DB access and never got it.
He has Ubuntu 64-bit and I have 32-bit, so I'm assuming that's the
difference.  Is your Linux machine 64-bit or 32-bit?  Have you ever had
a DB exception? (see db.log also)  Now that the zombie problem is fixed
in test5, could you start running it on your Linux machine?  We could
use a 3rd vote to get a better idea of what we're dealing with here.
The DB exception is uncaught, so it'll stop the program if you get it.
BTW, zetaboards insists on displaying "Member #", so you better sign up
soon and grab a good account number.
I'd better install 64-bit then.  I imagine it's something about the
32-bit version of Berkeley DB on 64-bit Linux.
BTW, in things like the feature list credits, do you want me to refer to
you as sirius-m or Martti Malmi?  I think most projects go by real names
for consistency.
At first glance, bitcoinshop.com looks better.  bitcoinexchange.com
might be better than bitcoinx.com.
Be careful where you search domain names, many will front-run you.  Even
network solutions, although they've said they won't if you use their
whois page not the homepage.  The only safe place is
http://www.internic.com/whois.html
I have an idea for a workaround, but it depends on what files the errors
are on.  If you've accumulated several errors in db.log, could you send
it to me? (even if it's rather simple and boring)  Is the file listed
always blkindex.dat, or does it include addr.dat or wallet.dat too?
What do you see as the benefits of switching the wiki?
Some I can think of:
SSL
get away from sourceforge's unreliable hosting
everything not logged by sourceforge
The forum feature is about as weak as bitweaver.  We need a full blown
forum software for that.
My priority right now is to get a forum going, either phpBB or similar.
What do you think of the zetaboards option?  Should we go ahead with that?
That's a good idea to go in a more web-publishing CMS type direction
like Drupal.  That's a better fit and can produce a better looking
website than a wiki.  I think I was wrong about wiki.  Only a few
specific people will do any website design work and those people can go
ahead and have a separate login.  In that case, login integration with
the forum doesn't matter much.  For security, I'd almost rather have a
different login than be constantly checking the forum with the same
login that could pwn the website.
Drupal's forum is less bad than the wikis, but still a long way from
something I would want to use.
zetaboards pros and cons:
pros:
- we don't have to worry about bandwidth
- they handle the backend management and security patches
con:
- lack of SSL
- lack of privacy, everything is logged
- lack of control over the php code for customization
- no CAPTCHA, and if they add one later it might be unacceptable flash
- ads (could pay to get rid of them later if we care enough)
- there's always the risk they abruptly cancel the site for some petty
reason
test 7:
Backup your data directory before running this, just in case.
Workaround for the Db::open/Db::close "Bad file descriptor" exception.
Might also make the initial block download faster.  The workaround is to
open the database handles and keep them open for the duration of the
program, which is actually the more common thing to do anyway.  If we're
not closing and opening all the time, the error shouldn't get a chance
to happen.
The one exception is wallet.dat, which I still close after writing is
finished so I can flush the transaction logs into the dat file, making
the dat file standalone.  That way if someone does a backup while
Bitcoin is running, they'll get a wallet.dat that is valid by itself
without the database transaction logs.
This is a restructuring of the database handling, so we might find some
new deadlocks.  Usually if it deadlocks, either the UI will stop
repainting, or it'll stop using CPU even though it still says Generating.
Another issue I thought of with zetaboards: most free forum sites won't
let you export the user account database if you want to move.  I don't
know why I don't see any other software projects using a free forum, but
I have to assume there might be a reason we would discover later.
If you can install phpBB3 on your VPS, that's probably the better option.
From what I've seen on other forums, if the cost of bandwidth becomes
an issue, a small Google Adwords (text links) at the top generates more
than the cost of bandwidth even for very low value traffic like gaming.
This would be much higher value traffic well targeted for high paying
gold merchant keywords and VPN hosts.  It could eventually be a valuable
revenue stream you wouldn't want to give away to some free site.
I want to pre-announce some of the features in version 0.2 on the forum
and try to get some anticipation going.  Even if hardly anyone else is
posting, I have seen project forums where most of the posts are the
author announcing what's going on with the latest changes.  Users can
see progress going on, see that it's improving and supported and not
abandonware.  It's a little like a blog in that case, but easier for
users to use it as a searchable FAQ and better organized.  Whenever I
google search software questions, most of the hits are forum posts.
Finally an easy one.  I see a way that could happen on a long operation
such as the initial download.  The TryLock bug is unrelated to the db
stuff.  Fix will be in test8.
I've been able to reproduce the db::open/close exception 3 times now on
32-bit linux by hitting it with a continuous flood of non-stop requests.
It looks like even periodically closing the wallet.dat database to
flush it gets the db::close exceptions.  I'm disabling the wallet flush
feature on Linux.  On Linux we'll never close a database handle until
we're ready to exit.  So far with this disabled, no exceptions.
I'm also implementing the orderly initial block download.  Instead of
naively requesting all the blocks at once, it'll request batches of 500
at a time.  This way, it'll receive the blocks before the retry timeout,
so it shouldn't go requesting it from other nodes unless it actually
doesn't receive them or it's too slow.  The change is in the requestee's
side, so this functionality won't be visible until your initial block
download is coming from a node that has the new version.
I'm going to test this some more before sending test8.
Thanks.  The db::open/close errors confirm the pattern.
More interesting is the zombie sockets activity towards the end, and the
socket thread monitor tripped but didn't get it going again.  Was the
machine disconnected from the net?  MSG_DONTWAIT in test5 solved the
zombie problem for Liberty.  What test version were you running?  (I
should print the test version in the log)
That's great, this is going to fun!  I'll research what people say about
the two.
I've been configuring the SMF forum.  They're saying SMF is better
written than phpBB and more reliable, so if I can get SMF to look right,
that's the preferable choice.
Most forums run vBulletin (big-boards.com lists 1376 vBulletin, 275
Invision, 245 phpBB and 41 SMF), so if you don't look like vBulletin or
Invision, it looks like you compromised because you couldn't afford
vBulletin.  SMF's UI started out further away from the standard look,
but I've been able to use CSS to make it look more like the others.
I've done as much as I can with CSS, the rest requires editing PHP files
and uploading images.  The forum doesn't have a built in file
upload/edit admin feature, it's added separately as the SMF File Manager
mod.  I uploaded the mod but some files need to be chmod 777 so it can
install.  If you go to Admin-Apply Mod, it offers to do it automatically if you enter an ftp login.
Someone says you might also have to
The error in the error log is:
failed to open stream: Permission denied
(I'm sure that's just the first file)
Is it OK to go live with this SMF installation when I'm finished
configuring it?  I should be able to point forum.bitcoin.org to it.
Liberty reports that linux-test8 has been running smoothly.  My tests
have been running fine as well.  The Linux version looks fully
stabilized to me.
Good news: he says he made his first sale of bitcoins.  Someone bought
out all he had.  I had been wondering whether it would be buyers or sellers.
DNS entry.
I'm thinking of merging the bitcoin.org information with your site
content so I can switch the whole bitcoin.org domain over.  We need to
replace the current bitcoin.org site with a user-oriented site before
the release.
If the website and forum switch at the same time, then forum.bitcoin.org
isn't necessary unless we want it that way for looks.
Have you decided on the CMS to use?  I should research Drupal and other
CMSes and see what's the most popular.
The linux version, setup exe, tor option and better website/forum will
all increase the percentage of visitors who can use it, and the
autostart and minimize to tray will increase how many keep running it.
All those factors multiply together.
It's good to start low and only have the price go up.
I really like that he explains the concept that the cost of electricity
is a minimum floor under the price.  At a minimum you either have to pay
the cost in electricity or pay someone the cost of production to make
them for you.
Thanks, that worked, I got File Manager installed with SSH.  I also
uploaded a few themes into Drupal.  I haven't thoroughly gone through
all the available themes yet.
Looked around at CMSes, Drupal and Joomla are popular.  Consensus is
Joomla has a better selection of themes and is easier to learn, though
Drupal may be more intuitive for programmers and customization.  Joomla
better for CMS, Drupal better for blogs.  Drupal's URLs are search
engine friendly, Joomla not.
Both have SMF bridge modules available.  For future reference, Drupal's
is named "SMFforum Integration".
I'll go ahead with setting up Drupal then.
I don't think we should make the site https by default.  It's still very
unusual for the public part of sites to be https, probably because it
introduces potential technical complications, delays and greater server
load.  As a user I'm a little annoyed when it takes time to verify the
identity of some no-name site I casually came across.  For me it seems
like https sites fail to load a lot more often.
The important thing is to have SSL available for those who need it.
Those who need SSL I think know to try inserting an "s" after http and
see if it works.  SMF has code that changes all the links to https if
the URL handed in is https.
We could add a note on the registration page that if you want SSL, you
can change http to https at any time and approve the self-signed
certificate, or a link that does it, and the TOR page can mention it too.
We can look into getting a certificate later when things have settled
down.  With Class 1, no changes are allowed for a year, which is a risk
if we find issues with the current host and have to change IP.
We need to do a continuity transition with bitcoin.org so the search
engines don't think this is a new site and reset the site start date and
PR data.  Google allows a certain number of properties like IP address
or content of the site to change without deleting your site history.  To
play it safe, when the IP address changes, the content better stay the
same and vice versa.  Even though not much rank has accumulated yet, the
original start date becomes extremely important if the site gets popular
later.
Steps:
1) copy the current bitcoin.org index.html to the new server exactly as-is.
2) switch the bitcoin.org DNS entry.
3) keep working on the drupal site behind the scenes.
4) after google has had time to update its records, we can switch over
to the drupal site.
The timing works out well because we can switch to the new forum now and
release the drupal site later when we're ready.
I'll see if I can figure out how to temporarily move drupal aside to
drupal.php or /drupal/ or something where we can still easily get in and
work on it.
Drupal's .htaccess file which uses mod_rewrite to allow clean URLs
without the ? parameter is not working because its changes are rejected
because Apache is not configured with "AllowOverride All".  This is
needed to make Drupal coexist with the other site the way we want.
I need access to change these files to fix it:
Here's the planned fix.  If you do it yourself, please still give me
access to httpd.conf in case I need to change it again later.
This probably requires Apache to be restarted after.
(apache2ctl graceful)
The bitcoin.org DNS change went through about 12 hours ago.  I'll wait
another 12 hours and then change the Forum tab on
bitcoin.sourceforge.net to go to http://www.bitcoin.org/smf/
For future reference, the changes in SMF to update the base url were:
server settings-   themes and layout-   there's a path in smileys and message icons
The Bitweaver menu editor is broken, I can't change the Forum link.  The
"create and edit menu items" page comes up blank for me:
http://bitcoin.sourceforge.net/nexus/menu_items.php?menu_id=2
You try it, I'm stumped.
The Forum link should be changed to:
Thanks, I haven't settled on a theme yet.  My first experiment was to
try something besides yet another blue site.  Another line of thought is
that it should be like a bank website, stately, professional and
official looking to support confidence in financial matters.
The logo's a little too Disco/web-1990's.  I still like your bitweaver
one better, I recreated it with text as a placeholder for now.  When the
theme is more settled, I'll think about a matching logo.
Good idea about the Sourceforge tag, we can use all the graphics we can get.
I have more to do before we go live, and we need to give the search
engines more time.
What Windows version/browser doesn't font anti-aliasing work on?  IE 6
on XP anti-aliases, and versions below that have less than 1% market share.
There's a transaction fee of 0.01 per KB after the first 1KB for
oversized transactions.  The first 1KB is free, small transactions are
typically 250 bytes.  Doubleclick on the transaction.  Think of it like
postage by weight.
The solution is an extra dialog when sending, something like "This is an
oversized transaction and requires a transaction fee of 0.20bc.  Is this
OK?"  (is that text good enough or any improvements?)  I have the code
already, I'll put it in.
Then we wouldn't have to explain the 10,000.20bc transaction, but may
still have to explain who the transaction fee goes to.
That's strange, I've seen Firefox 3.5 on XP anti-alias large fonts.
Well anyway, your way is safer.
I changed it back to text for now though so I can keep tweaking the
colours.  Drupal puts the <spanthat's fine for testing.
I added some instruction text on the homepage below the screenshots.
True.  I suppose the dialog could make it worse by giving people a
chance to experiment with breaking it up.
I'm making some changes.  The largest free transaction will be 60KB, or
about 27,000bc if made of 50bc inputs.  I hope that's high enough that
the transaction fee should rarely ever come up.  v0.2 nodes will take
free transactions until the block size is over 200K, with priority given
to smaller transactions.
It's best if you don't talk about this transaction fee stuff in public.
It's there for flood control.  We don't want to give anyone any ideas.
You found an infrequent bug in CreateTransaction.  It wrote the
transaction for 10000.20 with a fee of 0.22.  If you look at the
transaction on the sender's side, it'll be a debit 10000.42 with
transaction fee 0.22.  The bug was that it had to make a rare third pass
on calculating the fee, and incorrectly added the first pass' fee to the
amount being sent.  Will fix.
I added the sourceforge tracker to bitcoin.sourceforge.net.  The
complete selection of links is below if you want a different one.
I had it on bitcoin.org for a minute, but took it off.  It breaks the
lock in SSL mode with a mixed content warning, "partially encrypted" and
"contains unauthenticated content".  Anyway, do we really want
sourceforge tracking everyone?  It's more privacy friendly without it.
I went ahead and put the new Drupal site online.  Enough time has passed
for a safe transition, and the site looks good.  There's more work I
should do on the theme, but it's good enough so far.  This is a huge
improvement over the old bitcoin.org page.
I wasn't satisfied with my custom2 theme.  It felt crowded, the
header/logo seemed wrong and the heavy left margin stationery style is
outdated.
custom3 online now is a more standard layout similar to a lot of
commercial software homepages.  Maybe it's just me, but I really like
the random blue squares.
Most of the fixes are on the sender's side, so if you were downloading the network upgrades to 0.2.
How long did the initial download take?
Here's the planned release announcement text.  Probably releasing shortly.
- Multi-processor support for coin generation
- Proxy support for use with TOR
- Fixed some slowdowns in the initial block download
- Various refinements to keep the network running smoothly
We also have a new forum at http://www.bitcoin.org/smf/ if you have any
questions.
Thanks to <PRESIDIO_ANONYMIZED_PERSON> (sirius-m) for his coding work and for hosting
the new site and forum, and thanks to New Liberty Standard for testing
the Linux version.
- Multi-processor support for coin generation
- Proxy support for use with TOR
- Fixed some slowdowns in the initial block download
We also have a new forum at http://www.bitcoin.org/smf/
Many thanks to Martti (sirius-m) for all his development work, and to
New Liberty Standard for his help with testing the Linux version.
Thanks for creating the maintenance account, it would have been
impossible to do all that without it.  I'm really always going to need
it.  OK, I changed the password to a 20 character random password.
That's a good domain.  People rarely type domain names anymore, they use
autocomplete or click links on search engines.
I need to make a way for you to programmatically get new generated
bitcoin addresses.  Either that or you could have them send to your IP
address, but then you have to rely on them to put the order number in
the comment.
When generating the new address, there can be an option to add an entry
to the address book associated with the address, so the received
transaction will be labelled.  I kinda hid the labels after early users
found them confusing, but it would be very helpful for this application.
You have to widen up the comment column to see them.
Are you going to manually review and enter orders, at least to begin
with?  I sure would.
I'm thinking I should move the UI in the direction of having the user
ask for their bitcoin address when they want one.  "give me a bitcoin to
receive a payment with".  I suppose next to the send button, there would
by a receive button, you press it and it says "here's a new address to
use, here's the button to copy it to the clipboard, do you want to label
it?" and maybe some explanation about why you shouldn't reuse addresses.
Or maybe just a "New Address" button next to the address box that you
should hit each time to change it.
I had been wondering why everyone keeps harping on no-UI, when already
you can run it with only a small icon on the tray, which is common for
server services on Windows.  So I guess this is why.  I had chalked it
up to unix snobbery if they couldn't abide a tiny little icon on a
desktop they never see.
Not opening any windows is easy, but it may fail because the gtk
libraries aren't there.  wxWidgets has __WXBASE__ for "Only wxBase, no
GUI features".  You could try building for that instead of __WXGTK__ and
see what happens.  It would be preferable if there's any way to do it as
a command line switch on the same executable, rather than yet another
build variation to release.
How much memory do you have to work with?  Bitcoin necessarily takes a
fair bit of memory; about 75MB on Windows.  Is that a problem?
Command line control is one of the next things on the list.  I want to
design the API carefully.
Receiving payments is the part that has a lot of design choices to be
made.  The caller needs to identify the transactions of interest, that's
where the one-bitcoin-address-per-transaction model helps.  Searching
the comments text for an order number is another possibility.  There's
polled, asking what has been received to the given bitcoin address, and
event driven.  I guess in event driven, bitcoin would be told to run a
command line when a certain amount is received to a certain bitcoin address.
You're right, I was looking at a test run with 250,000 blocks... duh.
A normal one shows 17MB memory usage and 10MB VM size.
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-just want to save the money, then just bitcoin-
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.
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)
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:
its a security question
Is it possible to open a socket that can only be accessed locally?
I must have accidentally typed j instead of z.  It's bz2 format.  Rename
to .tar.bz2 or just do tar -jxvf
What was the reason for this change?
wxFormBuilder turns the (c) symbol into UTF-8 automatically.  On
wxWidgets-2.8.9 ansi, it shows as a copyright symbol with an extra trash
character, which this hack fixes up for the non-unicode (ansi) case.
Good, then no need to consider d-bus.  Is there something like IPC
sockets on Windows?  I guess we could look how wx does it, or maybe the
XML-RPC library will already know what to do.  Windows has named pipes,
maybe that's the best analogue.
I don't think I want to invent my own RPC protocol, I want to use an
existing standard.  PHP, Java, Python or anything will be able to talk
to the server directly the same way the command line commands do.
I'm going to start reading on XML-RPC.  It's coming up in searches as
the most widely used protocol and widely supported.  PHP includes it in
its standard libraries.
I noticed this in the docs for wxSocketServer::Accept(bool wait = true):
"If wait is true and there are no pending connections to be accepted, it
will wait for the next incoming connection to arrive.  **Warning: This
will block the GUI."
wxWidgets is pathologically single-threaded.  Not only single-threaded,
but must-be-the-GUI-thread-ed.  Even for something as non-UI as
wxStandardPaths I got nailed.  All this is fine for UI code, since this
is the same constraint placed by Windows anyway, but for UI-less server
daemon code, wx calls are uncertain.
Status of my research currently:
For PHP, Python, etc to access the server, we need to use regular
sockets.  I think we can make it local-only by binding to localhost
only, so it can only be accessed through the loopback.  They say it's
also watertight to simply check the IP of connections received and
disconnect anything not 127.0.0.1.  May as well do both.
XML-RPC is a bit fat.  There are 4 libraries for C++ but they're all big
and hard to build, dependencies, license issues.  Some posters complain
all the C++ and PHP XML-RPC libraries are buggy.
JSON-RPC is a simpler more elegant standard.  It's simple enough I could
use a generic JSON parser.
PHP, Python and Java all have good implementations of JSON-RPC.
I'm currently leaning towards JSON-RPC.
Maybe the current difficulty of buying LR is already the limit of how
easy it can get in that direction.
Every conventional payment method has refutability as their way to cope
with their lack of passwords and crypto.  The system is wide open to
copying plaintext credit card numbers and account numbers, and they deal
with it by reversing the transaction after the fact.  The system works
for physical goods that have to be delivered somewhere, and services
which can't be resold.  It's a problem when it interfaces with precious
metals and currency conversion.
The first step of being easy in one direction, bitcoin-of established value, goes a long way.  Even those who don't use the
conversion still benefit from knowing that they could.  Trading bitcoin
becomes an easier way to trade the ability to claim LR, similar to how
paper money was once the right to claim gold.  Nobody has to ever
actually claim the LR to get the benefit of having the option that they
could if they wanted to.
A lot of times you just need a minuscule amount of online currency.  The
hassle of buying the other online currencies is too much for buying a
small amount.  The ease of getting a small amount of bitcoin may help
bootstrap an ecosystem of sellers of micropayment sized online goods
selling to that market.  If the sellers can get LR for bitcoins, they're
happy, and that may be subsidized at first by investors who want to buy
bc in large lots.
The main thing holding online currencies back is the lack of an easy way
to get a small amount of currency.  Bitcoin opens that up.  It'll be the
only online currency that's both easy to cash out and easy to get a
small amount.  It'll just be the usual harder difficulty to buy a large
amount.
Right, I'll change it to this so it doesn't get broken again:
The JSON-RPC implementation is going well.  I'm using boost::asio for
sockets.  JSON-RPC can be plain socket or HTTP, but it seems most other
implementations are HTTP, so I made my own simple HTTP headers.  For
JSON parsing I'm using JSON Spirit, which makes full use of STL and has
been really nice to use.  It's header-only so it's no added build work,
and small enough to just add it to our source tree.  MIT license.  This
should all be working in a few more days.
The forum sure is taking off.  I didn't expect to have so much activity
so fast.
Does Drupal have any special multi-language support, or do you just
create copies of pages by hand?
BlueSky offered to do translation on the forum.  If you create a
www.bitcoin.org/zh/ copy of the site and give him an account with just
the ability to create new pages and edit text, he'll probably translate
the site into Chinese for you and maybe maintain it.
I didn't make any changes to Drupal code.  The only thing other than
installing themes was the .htaccess file (which really is needed, it
didn't work in the global config file).
It was only SMF where I made some PHP changes.
You might find it preferable not to translate it into your own language.
Often the standard answer about legalities is that it's only intended
for people in other countries.  Translating it into your home language
weakens that argument.
I uploaded my JSON-RPC and command line implementation to SVN.  I'm
waiting to post on the forum when I've had more time to think about the
commands.  At least some method names are going to change.
To enable the RPC server, add the switch -server.  It's not on by default.
Client commands are without any switches, as such:
Applications would normally use JSON-RPC directly, not command line.
I haven't tested my JSON-RPC server with anything else yet.  If you do,
please tell me how it goes.  You're using Python, right?
Getting the Linux version to run without the GTK installed will be a
separate task.
I will probably relent and do that.  I can move init and shutdown into
init.cpp or start.cpp or something, link only wxbase and not link ui.o
and uibase.o.
wxWidgets is mostly Windows people, they wouldn't know much about GTK.
Don't you have an Ubuntu laptop you can test and compile on so you don't
have to toy with the vps?
Hurray, I got it on the first go.
Could you send me the Python code you used?  So if I do some testing
later I don't have to figure it out myself.
I see it calls gtk-init-check in wxApp::Initialize.
I can subclass Initialize, call the original one while suppressing the
error message and ignore the return value.  It seems to be working.
Any suggestions what to name the command line switches and how to
describe them?  Is there any traditional standard?  I'm currently using:
-daemon (or -d)   (Enables RPC and runs in the background)
-server           (Enables RPC)
This is working.  A few more things and I'll upload it.
We'll need to tell people to install the GTK libraries.  Do you remember
the apt-get command to install GTK, and can you install it without
having a GUI installed?
Good, that gives them a little sense of ownership and responsibility.
I hope we get at least one .mo file for the software translation in time
to put into the 0.3 release.
I put it at bitcoin.org/download/linux64-0.2.7.1.tar.gz.  You can delete
it when you've got it.
I thought about what might cause the problem you're having and made a
change that this build includes.  This might have been unsafe code,
although it would probably always get lucky.
If you still suspect this code, for testing you could change it to:
const char* wxGetTranslation(const char* pszEnglish)
Could you send me the debug.log?
Does it still do it if you didn't do getinfo?
You could comment out the CreateThreads listed below, then re-enable
them one at a time until it does it again.  Then we would know which
thread the problem is in.
That narrows it down a lot.  It didn't print any IRC activity in
debug.log, so I guess it couldn't have gotten past the RecvUntil.
Eyeballing it I don't see anything obvious.  I guess it would have to be
either in ConnectSocket or RecvUntil.
Try it with the attached irc.cpp and net.cpp and send me the debug.log.
Or you could run it in gdb and step through ThreadIRCSeed
or u to step over and up out of routines.
It's in RecvUntil, but I still can't see anything wrong with it.  The
only thing I can think of is if the socket is receiving a spew of
characters.
Try this irc.cpp.  debug.log may grow rapidly so be ready to kill it.
It's in util.c ParseString.  I'm guessing the problem is incompatibility
between the type "unsigned int" and the type of str.npos, which is
size_type.
Try changing the two "unsigned int"s to "size_type".
Actually, please try this instead, this is more correct:
Comparing unsigned int -1 (0xffffffff) with long unsigned int -1
(0xffffffffffffffff) results in the unsigned int being promoted to
64-bit, which is 0x00000000ffffffff != 0xffffffffffffffff.
There's a blog writer who wants to write a story about Bitcoin, but I
don't have time right now to answer his questions.  Would you be
interested in answering his questions if I refer him to you?  We might
get a good link out of it.
The blog is
I've also been busy with other things for the last month and a half.  I
just now downloaded my e-mail since the beginning of April.  I mostly
have things sorted and should be back to Bitcoin shortly.  Glad that
you've been handling things in my absence.  Congrats on your first
transaction!
As I recall, the code was nearly ready for a 0.3 release.  I think all
it needed was a little testing time and to install the new icon xpm.
The JSON API functions are complete.  I wanted to take another fresh
look at them in case I think of any better function names before
committing.  I ought to write some sample code showing the proper way to
use them, particularly with polling for received transactions.  When I
left off, I was thinking about bolting a payment mechanism onto a free
upload server software as an example.  It would make sense to actually
build one practical application with the API before releasing it.  You
don't realise the problems with an API until you actually try to use it.
If bandwidth is a problem, delete my link in the "0.3 almost ready"
thread.  I just don't want to upload it to sourceforge for a quickie
share for a day or two, possibly taking it down immediately if there's a
bug.  Sourceforge has a policy of not allowing removal of files once
they're added, and it's a pain to upload to.  I'll delete the file once
the release is ready.
BTW, it's looking like I may be able to get us some money soon to cover
web host costs, back your exchange service, etc, in the form of cash in
the mail.  Can you receive it and act as the project's treasurer?
I got a donation offer for $2000 USD.  I need to get your postal mailing
address to have him send to.  And yes, he wants to remain anonymous, so
please keep the envelope's origin private.
I think we should de-emphasize the anonymous angle.  With the popularity
of bitcoin addresses instead of sending by IP, we can't give the
impression it's automatically anonymous.  It's possible to be
pseudonymous, but you have to be careful.  If someone digs through the
transaction history and starts exposing information people thought was
anonymous, the backlash will be much worse if we haven't prepared
expectations by warning in advance that you have to take precautions if
you really want to make that work.  Like Tor says, "Tor does not
magically encrypt all of your Internet activities.  Understand what Tor
does and does not do for you."
Also, anonymous sounds a bit shady.  I think the people who want
anonymous will still figure it out without us trumpeting it.
I made some changes to the bitcoin.org homepage.  It's not really
crucial to update the translations.  I tend to keep editing and
correcting for some time afterwards, so if they want to update, they
should wait.
I removed the word "anonymous", and the sentence about "anonymity
means", although you worded it so carefully "...CAN be kept hidden..."
it was a shame to remove it.
Instead, I added Tor instructions at the bottom, with instructions for
how to stay anonymous (pseudonymous) directly after the Tor
instructions: "If you want to remain anonymous (pseudonymous, really),
be careful not to reveal any information linking your bitcoin addresses
to your identity, and use a new bitcoin address for each payment you
receive."
It helps that it can now seed automatically through Tor.
Even though it doesn't say anonymous until the bottom, I think anonymous
seekers would already suspect it based on all the other attributes like
no central authority to take your ID info and the way bitcoin addresses
look.
I uploaded 0.3.0 beta to sourceforge and updated the links on
bitcoin.org.  I still need to post the announcement message on the forum
and mailing list.  Here's what I've prepared:
Announcing version 0.3 of Bitcoin, the P2P cryptocurrency!  Bitcoin is a
digital currency using cryptography and a distributed network to replace
the need for a trusted central server.  Escape the arbitrary inflation
risk of centrally managed currencies!  Bitcoin's total circulation is
limited to 21 million coins.  The coins are gradually being released to
the networks nodes based on the CPU power they contribute.  You can get
a share of them just by installing the software and contributing your
idle CPU time.
Actually, "tabs for sent and received transactions" sounds really
immature if it doesn't have that already.  "Transaction filter tabs"
sounds better.
I'm still editing it a little more and then I'll e-mail it to
bitcoin-list and send it to the cryptography list.
"Get it at http://www.bitcoin.org or read the forum to find out more."
Announcing version 0.3 of Bitcoin, the P2P cryptocurrency!  Bitcoin is a
digital currency using cryptography and a distributed network to replace
the need for a trusted central server.  Escape the arbitrary inflation
risk of centrally managed currencies!  Bitcoin's total circulation is
limited to 21 million coins.  The coins are gradually released to the
network's nodes based on the CPU power they contribute, so you can get a
share of them by contributing your idle CPU time.
Probably not an issue anymore, but might be a good idea to delete or update
that wiki page.
Is it possible for the translators (at least the more trusted ones) to
have user accounts on drupal so they can update their translated text
directly?  The user accounts on drupal appear to be pretty weak.  I
created a satoshi account and it can't even edit the side bar stuff,
just the main text of pages.  I don't think user accounts can access any
of the admin stuff.  Do you think it's safe, or do you feel insecure
about doing that?  If you're worried, maybe there's a way to lock just
the english version of the homepage.
It would be nice if when I need to make changes to the homepage, I could
enlist someone like Xunie to do the rote work of reflecting it to all
the translations instead of having to do all that work myself.  (many
light changes don't require understanding the language to fix the
translated pages)
It’s recommended that you stop Bitcoin before backing it up to make sure
the backup will be correct."
You did some research when choosing hosting, this was a well chosen one,
right?  It seems like it would be a tremendous hassle to change, and
we've had good luck with this one.  Cheaper will usually have some
offsetting drawback in quality.
I wonder if that extra memory is just disk cache or something.
I take it you haven't received anything from that donor yet?  He seemed
pretty certain he was going to send it, maybe more.  (if you get
anything, we need to keep private for him the fact that we got a donation)
Please promise me you won't make a switch now.  The last thing we need
is switchover hassle on top of the slashdot flood of work we've got now.
I'm losing my mind there are so many things that need to be done.
Also, it would suck to be on a smaller, less reliable host just to save
a measly $20.
I will try to think of a polite way to ask the donor if he sent it, but
right now there are other higher priority things that are going to bump
even that for a few days.
Would a donation of bitcoins help in the short term?
That's great!  I'll let him know it was received and thank him.
It might be a long time before we get another donation like that, we
should save a lot of it.
Spend what you need on hosting.  Email me a simple accounting when you
take out money for expenses, like:
$100-200 is chump change if they're a serious company, it would only
make us sound small.
What they need most is confidence they can convert it to fiat currency.
That VOIP company essentially said so in a recent post.  The best
thing we can do is make sure there's cash available to cash out and
support and steady the conversion rate.
The money is leveraged better that way too.  Theoretically, imagine 10
businesses have their eye on a $100 bill being offered for bitcoins, but
don't actually cash out because they know it's there if they need it.
That one $100 bill allowed 10 different people to act like their 5000
bitcoins were equivalent to $100.
I think we should allocate $1000 at this point to your exchange.
Interesting, so how is the balance between purchases of coins and cash
going?
Btw, are you able to use my builds of bitcoind on your host, or do you
have to build it yourself?
They probably couldn't have gotten that large of a trade on
bitcoinmarket.com.
Wish I could figure out how to fix that.  What version of GLIBCXX does
your system have?
Make sure you upgrade to Bitcoin 0.3.3 as soon as possible.
I think our problem may be that we have forum notifications on, like
e-mail you when you receive a PM, but we don't have e-mail verification
of new accounts.  Can someone put someone else's e-mail address without
verifying it, then have stuff sent there?  We need to stop that right
away before it gets used for something bad.  Either disallow all
notification, or make sure e-mail addresses are verified.
I'm more inclined to disallow notifications or anything where the forum
sends you e-mail.  I kinda like not requiring e-mail verification.  But
if that's the only way to make sure we don't send e-mails to un-verified
addresses, then we could do that.
If we request to get off of PBL, we'd better make sure we've got the
problem secured first.
I changed Registration-Activation".  I assume that means it e-mail verifies.
"Member Activation
When this option is enabled any members registering to the forum will
have a activation link emailed to them which they must click before they
can become full members"
I think that's the only way to make sure the forum can't be used to send
to other people's e-mail addresses and potentially use it to spam.
Please upgrade to 0.3.6 ASAP to get an important bugfix.
Oh great, now we're screwed.
We probably got spam blocked because we were allowing registrations
without e-mail verification.  But now that we've enabled it, our
verification e-mails are blocked.
There could still be some existing user accounts created before the
registration requirement being used by spammers.
We're kind of in a jam here.  Can you make sure there's nothing else you
can think of that might be acting as an open e-mail gateway or way for
spammers to use our system for putting out spam?  Check the e-mail logs
and see if there's been a lot of traffic and what it's from.  If you can
figure out what the problem was and shut it down, then after you're sure
it's fixed, request PBL to take us off the block list.
If there's a way to prohibit the forum from sending e-mail
notifications, maybe we should do that.
For "normal members" I disabled "Request notification on replies" and
"Request notification on new topics".
I'm pretty sure there's a notification option for when you receive PMs,
but I don't see a way to disable it.  If we have to, I guess we could
edit the php code.
Here's the info about PBL again.
I think our problem may be that we have forum notifications on, like
e-mail you when you receive a PM, but we don't have e-mail verification
of new accounts.  Can someone put someone else's e-mail address without
verifying it, then have stuff sent there?  We need to stop that right
away before it gets used for something bad.  Either disallow all
notification, or make sure e-mail addresses are verified.
I'm more inclined to disallow notifications or anything where the forum
sends you e-mail.  I kinda like not requiring e-mail verification.  But
if that's the only way to make sure we don't send e-mails to un-verified
addresses, then we could do that.
If we request to get off of PBL, we'd better make sure we've got the
problem secured first.
I changed Registration-Activation".  I assume that means it e-mail verifies.
"Member Activation
When this option is enabled any members registering to the forum will
have a activation link emailed to them which they must click before they
can become full members"
I think that's the only way to make sure the forum can't be used to send
to other people's e-mail addresses and potentially use it to spam.
Are PM notifications still disabled?  (All we really need is disable the
forum's access to the mail server)
Right, forgot about that.
Hopefully theymos was right that the PBL is the source of the problem.
This is single-player computer game based on Windows Minesweeper version.
Would you be so kind to add us to the http://www.bitcoin.org/trade page?
Thank you.
I noticed my custom captcha stuff is gone.  I guess it got lost in an
upgrade?  What are we doing for captcha now?  If we only have default
captcha, we'd be getting flooded with spam accounts.  Do I need to
re-integrate the custom captcha stuff or do we have another solution now?
I reuploaded the changes.  For future reference, the files in Sources
with customisations are:
Let me know whenever you do an upgrade so I can make sure all my changes
survived.
Hopefully the 1.1.x line is mature and updates are infrequent.  We
shouldn't upgrade to 2.0.  I made a ton of customisations that wouldn't
be compatible, and I kind of prefer the look of 1.1 over 2.0 anyway.
The captcha url has mycode=4 added to it, and the register page has
extra hidden mycode=2 through 5 images so any automated thing wouldn't
know which one to pick.  Everything that uses captcha has to have that
mycode=4 thing added.  Something in sending personal messages also uses
captcha.
Bitcoin.org has been down for several hours.
Do you know what caused that outage?  Did it need to be rebooted, or was
it a DoS or something?  The IP was pingable during the outage.
Did you get back to davidonpda about his doing a mirror backup?  I think
that's a really good idea.  Do you do any backups, or the VPS do any for
you automatically?
It should be Gavin.  I trust him, he's responsible, professional, and
technically much more linux capable than me.
(I don't know Xunie, but he hasn't posted for months and he was a goofball)
Thanks, did you finish moving bitcoinexchange to another server?
Mind if I add you to the Project Developers list on the Contact page?
You wrote some code before so you should be there.  It would have to be
your real name for consistency.  If you want to have an e-mail address
listed, I'll make an image out of it so it doesn't attract spam.
Version 0.3.18 is now available.
Changes:
- Fixed a wallet.dat compatibility problem if you downgraded from 0.3.17
and then upgraded again
- IsStandard() check to only include known transaction types in blocks
- Jgarzik's optimisation to speed up the initial block download a little
The main addition in this release is the Accounts-based JSON-RPC
commands that Gavin's been working on (more details at
BTW, password hashes = passwords.  It's easy to break the hash of short
passwords people use on forums.
6 chars = 3 difficulty
7 chars = 410 difficulty
8 chars = 25418 difficulty
+1
Even with encryption, a trusted storage place is better.
You're the best person to do it.
EFF is really important.  We want to have a good relationship with them.
We're the type of project they like; they've helped the TOR project
and done a lot to protect P2P file sharing.
The paper was published in 2008.
Someone needs to correct Wikipedia; it incorrectly says the paper was
published in 2009.  The paper was released earlier than the software.
Martti should give you the Drupal admin password.