The most complete public archive of Satoshi Nakamoto's known writings: 960 items spanning 2008–2011, including the Bitcoin whitepaper (October 2008), private email correspondence with Wei Dai, Hal Finney, Adam Back, Martti Malmi (Sirius), Mike Hearn, Gavin Andresen, Laszlo Hanyecz, Dustin Trammell, and Jon Matonis; posts to the Cryptography and Bitcoin mailing lists; the P2P Foundation announcement; and 538 BitcoinTalk forum posts. All items are presented chronologically, cross-referenced, and fully searchable.
Compilation notice — date unknown — source: (this compilation)
Credits, Sources, and Compilation Notice
This document is a non-commercial historical
compilation of publicly-available material relating to Satoshi
Nakamoto and the early development of Bitcoin. Every item in this
archive comes from a published source — the original authors and
curators are credited below.
Source archives
Nakamoto
Institute — whitepaper Markdown transcription, the seven
SVG figures, and the aggregated mailing-list data (Cryptography list,
bitcoin-list, P2P Research list, P2P Foundation posts). Licensed
under GNU AGPL-3.0.
lugaxker/nakamoto-archive
— BitcoinTalk forum posts, private Wei Dai and Hal Finney
correspondence, the Adam Back COPA exhibit PDF, and the Gavin Andresen
alert-key email.
Dustin D. Trammell (“Druid”) — mbox archive of 22
Satoshi correspondence emails, originally hosted at
dustintrammell.com/s/Satoshi_Nakamoto.zip and retrieved
here via the Internet Archive Wayback Machine.
bitcoin.org — the
original Bitcoin whitepaper PDF. MIT License.
UK COPA v. Wright court records — Adam Back exhibit
emails (public record once filed in court).
Original authors of the
correspondence
Satoshi Nakamoto (author of the whitepaper and most forum posts), Wei
Dai, Hal Finney, Adam Back, Martti Malmi (Sirius), Mike Hearn, Dustin D.
Trammell, Gavin Andresen, Jon Matonis, Laszlo Hanyecz, James A. Donald,
Ray Dillinger, Hashcash list participants, BitcoinTalk forum members,
and the many other early Bitcoin community members whose words appear in
these threads.
Compilation notice and
takedown
This is a research/educational aggregation. Material from the sources
above is reproduced here for historical preservation and study. Where
authors have self-published their correspondence (Malmi, Hearn,
Trammell, Andresen), that publication act is treated as the relevant
license to reproduce.
If you are an author or rights-holder of any material reproduced here
and would like content removed, please contact lebitwamdec@yandex.com and the material will
be removed promptly.
License of this compilation
This compiled archive (HTML, PDF, the build script
build_satoshi.py, and the sources/ directory)
is licensed under the GNU Affero General
Public License v3.0.
The AGPL applies to the compilation and the build code, not
to the underlying historical material (which retains the licenses of its
original authors). The upstream Nakamoto Institute source
content (whitepaper Markdown transcription, SVG figures, mailing-list
data) was already AGPL-3.0; this site adopts the same license to remain
compatible with it.
The complete source code (build script, input archives, intermediate
Markdown, and the rendered outputs) is available alongside this page —
every file referenced from this archive is reachable from the base URL.
You may copy, modify, and redistribute this work under the terms of the
AGPL-3.0.
PII redactions
A leaked HTTP basic-auth credential and a small number of phone
numbers, names, and email-address domains belonging to private
individuals (people who exchanged one or two messages with Satoshi and
are not themselves public figures) have been replaced with
[REDACTED-…] markers. The original sources linked above
retain the unredacted versions.
Note on the 2014 P2P
Foundation post
The post titled “I am not Dorian Nakamoto.” dated March 7, 2014 in
the P2P Foundation section is flagged as disputed: it
was made from Satoshi’s P2P Foundation account nearly three years after
the last verified Satoshi communication (the April 23, 2011 email to
Mike Hearn), from a long-dormant account that many researchers believe
to have been compromised. Authorship by the real Satoshi Nakamoto is not
verified and is widely doubted.
Citation of your Hashcash paper
Adam Back correspondence (Satoshi Nakamoto) — August 20, 2008 — source: adam-back-emails.txt#email-4
I'm getting ready to release a paper that references your Hashcash paper and I wanted to make sure I
have the citation right. Here's what I have:
[5] A. Back, "Hashcash - a denial of service counter-measure,"
http://www.hashcash.org/papers/hashcash.pdf, 2002.
I think you would find it interesting, since it finds a new use for hash-based proof-of-work as a way to
make e-cash work. You can download a pre-release draft at http://www.upload.ae/file/6157/ecash-
pdf.html Feel free to forward it to anyone else you think would be interested. I'm also nearly finished
with a C++ implementation to release as open source.
Title: Electronic Cash Without a Trusted Third PartyAbstract: A purely peer-to-peer version of electronic
cash would allow online payments to be sent directly from one party to another without the burdens of
going through a financial institution. Digital signatures offer part of the solution, but the main benefits are
lost if a trusted party is still required to prevent double-spending. We propose a solution to the double-
spending problem using a peer-to-peer network. The network timestamps transactions by hashing them
into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without
redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events
witnessed, but proof that it came from the largest pool of CPU power. As long as honest nodes control
the most CPU power on the network, they can generate the longest chain and outpace any attackers.
The network itself requires minimal structure. Messages are broadcasted on a best effort basis, and
nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what
happened while they were gone.
satoshi@anonymousspeech.com
Re: Citation of your Hashcash paper
Adam Back correspondence (Adam Back) — August 21, 2008 — source: adam-back-emails.txt#email-5
From: Adam Back Sent: Thur
8/21/2008 1:55:59 PM (UTC+01:00) To: satoshi@anonymousspeech.comSubject:
Re: Citation of your Hashcash paper
Yes citation looks fine, I'll take a look at your paper. You maybe
aware of the "B-money" proposal, I guess google can find it for you,
by Wei Dai which sounds to be somewhat related to your paper. (The
b-money idea is just described concisely on his web page, he didnt
write up a paper).
Adam
On Wed, Aug 20, 2008 at 6:30 PM, satoshi@anonymousspeech.com
<satoshi@anonymousspeech.com> wrote:
> I'm getting ready to release a paper that references your Hashcash paper and I wanted to make sure I
have the citation right. Here's what I have:
>
> [5] A. Back, "Hashcash - a denial of service counter-measure,"
http://www.hashcash.org/papers/hashcash.pdf, 2002.
>
> I think you would find it interesting, since it finds a new use for hash-based proof-of-work as a way to
make e-cash work. You can download a pre-release draft at http://www.upload.ae/file/6157/ecash-
pdf.html Feel free to forward it to anyone else you think would be interested. I'm also nearly finished
with a C++ implementation to release as open source.
>
> Title: Electronic Cash Without a Trusted Third Party
>
> Abstract: A purely peer-to-peer version of electronic cash would allow online payments to be sent
directly from one party to another without the burdens of going through a financial institution. Digital
signatures offer part of the solution, but the main benefits are lost if a trusted party is still required to
prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer
network. The network timestamps transactions by hashing them into an ongoing chain of hash-based
proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest
chain not only serves as proof of the sequence of events witnessed, but proof that it came from the
largest pool of CPU power. As long as honest nodes control the most CPU power on the network, they
can generate the longest chain and outpace any attackers. The network itself requires minimal structure.
Messages are broadcasted on a best effort basis, and nodes can leave and rejoin the network at will,
accepting the longest proof-of-work chain as proof of what happened while they were gone.
>
> satoshi@anonymousspeech.com
>
>
>
RE: Citation of your Hashcash paper
Adam Back correspondence (Satoshi Nakamoto) — August 21, 2008 — source: adam-back-emails.txt#email-2
Thanks, I wasn't aware of the b-money page, but my ideas start from exactly that point. I'll e-mail him to
confirm the year of publication so I can credit him.
The main thing my system adds is to also use proof-of-work to support a distributed timestamp server.
While users are generating proof-of-work to make new coins for themselves, the same proof-of-work is
also supporting the network timestamping. This is instead of Usenet.
Satoshi
>Yes citation looks fine, I'll take a look at your paper. You maybe
>aware of the "B-money" proposal, I guess google can find it for you,
>by Wei Dai which sounds to be somewhat related to your paper. (The
>b-money idea is just described concisely on his web page, he didnt
>write up a paper).
>
>Adam
>>On Wed, Aug 20, 2008 at 6:30 PM, satoshi@anonymousspeech.com
><satoshi@anonymousspeech.com> wrote:
>> I'm getting ready to release a paper that references your Hashcash paper and I wanted to make sure I
have the citation right. Here's what I have:
>>
>> [5] A. Back, "Hashcash - a denial of service counter-measure,"
http://www.hashcash.org/papers/hashcash.pdf, 2002.
>>
>> I think you would find it interesting, since it finds a new use for hash-based proof-of-work as a way to
make e-cash work. You can download a pre-release draft at http://www.upload.ae/file/6157/ecash-
pdf.html Feel free to forward it to anyone else you think would be interested. I'm also nearly finished
with a C++ implementation to release as open source.
>>
>> Title: Electronic Cash Without a Trusted Third Party
>>
>> Abstract: A purely peer-to-peer version of electronic cash would allow online payments to be sent
directly from one party to another without the burdens of going through a financial institution. Digital
signatures offer part of the solution, but the main benefits are lost if a trusted party is still required to
prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer
network. The network timestamps transactions by hashing them into an ongoing chain of hash-based
proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest
chain not only serves as proof of the sequence of events witnessed, but proof that it came from the
largest pool of CPU power. As long as honest nodes control the most CPU power on the network, they
can generate the longest chain and outpace any attackers. The network itself requires minimal structure.
Messages are broadcasted on a best effort basis, and nodes can leave and rejoin the network at will,
accepting the longest proof-of-work chain as proof of what happened while they were gone.
>>
>> satoshi@anonymousspeech.com
>>
>>
>>
>
Re: Citation of your Hashcash paper
Adam Back correspondence (Adam Back) — August 21, 2008 — source: adam-back-emails.txt#email-3
From: Adam Back Sent: Thur
8/21/2008 7:17:17 PM (UTC+01:00) To: satoshi@anonymousspeech.comSubject:
Re: Citation of your Hashcash paper
Sorry still not read your paper yet, but another related paper is by
Rivest et al called micromint, which uses k-way collisions to create
an over-time computational advantage for the bank in creating coins.
What you said about one group of players having an advantage (by
compute cycles) reminded me of micromint. In micromint the bank gets
an increasing advantage over time as there is some cumulative build up
of advantage in terms of the partial results accumulated helping
create further the partial-collisions more cheaply.
Adam
On Thu, Aug 21, 2008 at 6:59 PM, satoshi@anonymousspeech.com
<satoshi@anonymousspeech.com> wrote:
> Thanks, I wasn't aware of the b-money page, but my ideas start from exactly that point. I'll e-mail him to
confirm the year of publication so I can credit him.
>
> The main thing my system adds is to also use proof-of-work to support a distributed timestamp server.
While users are generating proof-of-work to make new coins for themselves, the same proof-of-work is
also supporting the network timestamping. This is instead of Usenet.
>
> Satoshi
>
>>Yes citation looks fine, I'll take a look at your paper. You maybe
>>aware of the "B-money" proposal, I guess google can find it for you,
>>by Wei Dai which sounds to be somewhat related to your paper. (The
>>b-money idea is just described concisely on his web page, he didnt
>>write up a paper).
>>
>>Adam
>>
>>On Wed, Aug 20, 2008 at 6:30 PM, satoshi@anonymousspeech.com
>><satoshi@anonymousspeech.com> wrote:
>>> I'm getting ready to release a paper that references your Hashcash paper and I wanted to make sure
I have the citation right. Here's what I have:
>>>
>>> [5] A. Back, "Hashcash - a denial of service counter-measure,"
http://www.hashcash.org/papers/hashcash.pdf, 2002.
>>>
>>> I think you would find it interesting, since it finds a new use for hash-based proof-of-work as a way to
make e-cash work. You can download a pre-release draft at http://www.upload.ae/file/6157/ecash-
pdf.html Feel free to forward it to anyone else you think would be interested. I'm also nearly finished
with a C++ implementation to release as open source.
>>>
>>> Title: Electronic Cash Without a Trusted Third Party
>>>
>>> Abstract: A purely peer-to-peer version of electronic cash would allow online payments to be sent
directly from one party to another without the burdens of going through a financial institution. Digital
signatures offer part of the solution, but the main benefits are lost if a trusted party is still required to
prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer
network. The network timestamps transactions by hashing them into an ongoing chain of hash-based
proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest
chain not only serves as proof of the sequence of events witnessed, but proof that it came from the
largest pool of CPU power. As long as honest nodes control the most CPU power on the network, they
can generate the longest chain and outpace any attackers. The network itself requires minimal structure.
Messages are broadcasted on a best effort basis, and nodes can leave and rejoin the network at will,
accepting the longest proof-of-work chain as proof of what happened while they were gone.
>>>
>>> satoshi@anonymousspeech.com
>>>
>>>
>>>
>>
>
>
Citation of your b-money page
Wei Dai correspondence — August 22, 2008 — source: 1.md
I was very interested to read your b-money page. I’m getting ready to
release a paper that expands on your ideas into a complete working
system. Adam Back (hashcash.org) noticed the similarities and pointed me
to your site.
I need to find out the year of publication of your b-money page for
the citation in my paper. It’ll look like:
Title: Electronic Cash Without a Trusted Third Party
Abstract: A purely peer-to-peer version of electronic cash would
allow online payments to be sent directly from one party to another
without the burdens of going through a financial institution. Digital
signatures offer part of the solution, but the main benefits are lost if
a trusted party is still required to prevent double-spending. We propose
a solution to the double-spending problem using a peer-to-peer network.
The network timestamps transactions by hashing them into an ongoing
chain of hash-based proof-of-work, forming a record that cannot be
changed without redoing the proof-of-work. The longest chain not only
serves as proof of the sequence of events witnessed, but proof that it
came from the largest pool of CPU power. As long as honest nodes control
the most CPU power on the network, they can generate the longest chain
and outpace any attackers. The network itself requires minimal
structure. Messages are broadcasted on a best effort basis, and nodes
can leave and rejoin the network at will, accepting the longest
proof-of-work chain as proof of what happened while they were gone.
I've been working on a new electronic cash system that's fully
peer-to-peer, with no trusted third party.
The paper is available at:
http://www.bitcoin.org/bitcoin.pdf
The main properties:
Double-spending is prevented with a peer-to-peer network.
No mint or other trusted parties.
Participants can be anonymous.
New coins are made from Hashcash style proof-of-work.
The proof-of-work for new coin generation also powers the
network to prevent double-spending.
Bitcoin: A Peer-to-Peer Electronic Cash System
Abstract. A purely peer-to-peer version of electronic cash would
allow online payments to be sent directly from one party to another
without the burdens of going through a financial institution.
Digital signatures provide part of the solution, but the main
benefits are lost if a trusted party is still required to prevent
double-spending. We propose a solution to the double-spending
problem using a peer-to-peer network. The network timestamps
transactions by hashing them into an ongoing chain of hash-based
proof-of-work, forming a record that cannot be changed without
redoing the proof-of-work. The longest chain not only serves as
proof of the sequence of events witnessed, but proof that it came
from the largest pool of CPU power. As long as honest nodes control
the most CPU power on the network, they can generate the longest
chain and outpace any attackers. The network itself requires
minimal structure. Messages are broadcasted on a best effort basis,
and nodes can leave and rejoin the network at will, accepting the
longest proof-of-work chain as proof of what happened while they
were gone.
Full paper at:
http://www.bitcoin.org/bitcoin.pdf
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (James A. Donald) — November 02, 2008 — source: sni-emails.json#email-2
Satoshi Nakamoto wrote:
> I've been working on a new electronic cash system that's fully
> peer-to-peer, with no trusted third party.
>
> The paper is available at:
> http://www.bitcoin.org/bitcoin.pdf
We very, very much need such a system, but the way I understand your
proposal, it does not seem to scale to the required size.
For transferable proof of work tokens to have value, they must have
monetary value. To have monetary value, they must be transferred within
a very large network - for example a file trading network akin to
bittorrent.
To detect and reject a double spending event in a timely manner, one
must have most past transactions of the coins in the transaction, which,
naively implemented, requires each peer to have most past
transactions, or most past transactions that occurred recently. If
hundreds of millions of people are doing transactions, that is a lot of
bandwidth - each must know all, or a substantial part thereof.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 03, 2008 — source: sni-emails.json#email-3
>Satoshi Nakamoto wrote:
>> I've been working on a new electronic cash system that's fully
>> peer-to-peer, with no trusted third party.
>>
>> The paper is available at:
>> http://www.bitcoin.org/bitcoin.pdf
>
>We very, very much need such a system, but the way I understand your
>proposal, it does not seem to scale to the required size.
>
>For transferable proof of work tokens to have value, they must have
>monetary value. To have monetary value, they must be transferred within
>a very large network - for example a file trading network akin to
>bittorrent.
>
>To detect and reject a double spending event in a timely manner, one
>must have most past transactions of the coins in the transaction, which,
> naively implemented, requires each peer to have most past
>transactions, or most past transactions that occurred recently. If
>hundreds of millions of people are doing transactions, that is a lot of
>bandwidth - each must know all, or a substantial part thereof.
>
Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node.
The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices.
If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (John Levine) — November 03, 2008 — source: sni-emails.json#email-4
> As long as honest nodes control the most CPU power on the network,
> they can generate the longest chain and outpace any attackers.
But they don't. Bad guys routinely control zombie farms of 100,000
machines or more. People I know who run a blacklist of spam sending
zombies tell me they often see a million new zombies a day.
This is the same reason that hashcash can't work on today's Internet
-- the good guys have vastly less computational firepower than the bad
guys.
I also have my doubts about other issues, but this one is the killer.
R's,
John
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 03, 2008 — source: sni-emails.json#email-5
>> As long as honest nodes control the most CPU power on the network,
>> they can generate the longest chain and outpace any attackers.
>
>But they don't. Bad guys routinely control zombie farms of 100,000
>machines or more. People I know who run a blacklist of spam sending
>zombies tell me they often see a million new zombies a day.
>
>This is the same reason that hashcash can't work on today's Internet
>-- the good guys have vastly less computational firepower than the bad
>guys.
Thanks for bringing up that point.
I didn't really make that statement as strong as I could have. The requirement is that the good guys collectively have more CPU power than any single attacker.
There would be many smaller zombie farms that are not big enough to overpower the network, and they could still make money by generating bitcoins. The smaller farms are then the "honest nodes". (I need a better term than "honest") The more smaller farms resort to generating bitcoins, the higher the bar gets to overpower the network, making larger farms also too small to overpower it so that they may as well generate bitcoins too. According to the "long tail" theory, the small, medium and merely large farms put together should add up to a lot more than the biggest zombie farm.
Even if a bad guy does overpower the network, it's not like he's instantly rich. All he can accomplish is to take back money he himself spent, like bouncing a check. To exploit it, he would have to buy something from a merchant, wait till it ships, then overpower the network and try to take his money back. I don't think he could make as much money trying to pull a carding scheme like that as he could by generating bitcoins. With a zombie farm that big, he could generate more bitcoins than everyone else combined.
The Bitcoin network might actually reduce spam by diverting zombie farms to generating bitcoins instead.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (James A. Donald) — November 03, 2008 — source: sni-emails.json#email-6
James A. Donald:
> > To detect and reject a double spending event in a
> > timely manner, one must have most past transactions
> > of the coins in the transaction, which, naively
> > implemented, requires each peer to have most past
> > transactions, or most past transactions that
> > occurred recently. If hundreds of millions of people
> > are doing transactions, that is a lot of bandwidth -
> > each must know all, or a substantial part thereof.
Satoshi Nakamoto wrote:
> Long before the network gets anywhere near as large as
> that, it would be Safe for users to use Simplified
> Payment Verification (section 8) to check for double
> spending, which only requires having the chain of
> block headers,
If I understand Simplified Payment Verification
correctly:
New coin issuers need to store all coins and all recent
coin transfers.
There are many new coin issuers, as many as want to be
issuers, but far more coin users.
Ordinary entities merely transfer coins. To see if a
coin transfer is OK, they report it to one or more new
coin issuers and see if the new coin issuer accepts it.
New coin issuers check transfers of old coins so that
their new coins have valid form, and they report the
outcome of this check so that people will report their
transfers to the new coin issuer.
If someone double spends a coin, and one expenditure is
reported to one new coin issuer, and the other
simultaneously reported to another new coin issuer, then
both issuers to swifly agree on a unique sequence order
of payments. This, however, is a non trivial problem of
a massively distributed massive database, a notoriously
tricky problem, for which there are at present no peer
to peer solutions. Obiously it is a solvable problem,
people solve it all the time, but not an easy problem.
People fail to solve it rather more frequently.
But let us suppose that the coin issue network is
dominated by a small number of issuers as seems likely.
If a small number of entities are issuing new coins,
this is more resistant to state attack that with a
single issuer, but the government regularly attacks
financial networks, with the financial collapse ensuing
from the most recent attack still under way as I write
this.
Government sponsored enterprises enter the business, in
due course bad behavior is made mandatory, and the evil
financial network is bigger than the honest financial
network, with the result that even though everyone knows
what is happening, people continue to use the paper
issued by the evil financial network, because of network
effects - the big, main issuers, are the issuers you use
if you want to do business.
Then knowledgeable people complain that the evil
financial network is heading for disaster, that the
government sponsored enterprises are about to cause a
"collapse of the total financial system", as Wallison
and Alan Greenspan complained in 2005, the government
debates shrinking the evil government sponsored
enterprises, as with "S. 190 [109th]: Federal Housing
Enterprise Regulatory Reform Act of 2005" but they find
easy money too seductive, and S. 190 goes down in flames
before a horde of political activists chanting that easy
money is sound, and opposing it is racist, nazi,
ignorant, and generally hateful, the recent S. 190
debate on limiting portfolios (bond issue supporting dud
mortgages) by government sponsored enterprises being a
perfect reprise of the debates on limiting the issue of
new assignats in the 1790s.
The big and easy government attacks on money target a
single central money issuer, as with the first of the
modern political attacks, the French Assignat of 1792,
but in the late nineteenth century political attacks on
financial networks began, as for example the Federal
reserve act of 1913, the goal always being to wind up
the network into a single too big to fail entity, and
they have been getting progressively bigger, more
serious, and more disastrous, as with the most recent
one. Each attack is hugely successful, and after the
cataclysm that the attack causes the attackers are
hailed as saviors of the poor, the oppressed, and the
nation generally, and the blame for the the bad
consequences is dumped elsewhere, usually on Jews,
greedy bankers, speculators, etc, because such attacks
are difficult for ordinary people understand. I have
trouble understanding your proposal - ordinary users
will be easily bamboozled by a government sponsored
security update. Further, when the crisis hits, to
disagree with the line, to doubt that the regulators are
right, and the problem is the evil speculators, becomes
political suicide, as it did in America in 2007,
sometimes physical suicide, as in Weimar Germany.
Still, it is better, and more resistant to attack by
government sponsored enterprises, than anything I have
seen so far.
> Visa processed 37 billion transactions in FY2008, or
> an average of 100 million transactions per day. That
> many transactions would take 100GB of bandwidth, or
> the size of 12 DVD or 2 HD quality movies, or about
> $18 worth of bandwidth at current prices.
> If the network were to get that big, it would take
> several years, and by then, sending 2 HD movies over
> the Internet would probably not seem like a big deal.
If there were a hundred or a thousand money issuers by
the time the government attacks, the kind of government
attacks on financial networks that we have recently seen
might well be more difficult.
But I think we need to concern ourselves with minimizing
the data and bandwidth required by money issuers - for
small coins, the protocol seems wasteful. It would be
nice to have the full protocol for big coins, and some
shortcut for small coins wherein people trust account
based money for small amounts till they get wrapped up
into big coins.
The smaller the data storage and bandwidth required for
money issuers, the more resistant the system is the kind
of government attacks on financial networks that we have
recently seen.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Ray Dillinger) — November 06, 2008 — source: sni-emails.json#email-7
On Tue, 2008-11-04 at 06:20 +1000, James A. Donald wrote:
> If I understand Simplified Payment Verification
> correctly:
>
> New coin issuers need to store all coins and all recent
> coin transfers.
>
> There are many new coin issuers, as many as want to be
> issuers, but far more coin users.
>
> Ordinary entities merely transfer coins. To see if a
> coin transfer is OK, they report it to one or more new
> coin issuers and see if the new coin issuer accepts it.
> New coin issuers check transfers of old coins so that
> their new coins have valid form, and they report the
> outcome of this check so that people will report their
> transfers to the new coin issuer.
I think the real issue with this system is the market
for bitcoins.
Computing proofs-of-work have no intrinsic value. We
can have a limited supply curve (although the "currency"
is inflationary at about 35% as that's how much faster
computers get annually) but there is no demand curve
that intersects it at a positive price point.
I know the same (lack of intrinsic value) can be said of
fiat currencies, but an artificial demand for fiat
currencies is created by (among other things) taxation
and legal-tender laws. Also, even a fiat currency can
be an inflation hedge against another fiat currency's
higher rate of inflation. But in the case of bitcoins
the inflation rate of 35% is almost guaranteed by the
technology, there are no supporting mechanisms for
taxation, and no legal-tender laws. People will not
hold assets in this highly-inflationary currency if
they can help it.
Bear
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 06, 2008 — source: sni-emails.json#email-8
>[Lengthy exposition of vulnerability of a systm to use-of-force
>monopolies ellided.]
>
>You will not find a solution to political problems in cryptography.
Yes, but we can win a major battle in the arms race and gain a new territory of freedom for several years.
Governments are good at cutting off the heads of a centrally controlled networks like Napster, but pure P2P networks like Gnutella and Tor seem to be holding their own.
Satoshi
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Hal Finney) — November 07, 2008 — source: sni-emails.json#email-9
Bitcoin seems to be a very promising idea. I like the idea of basing
security on the assumption that the CPU power of honest participants
outweighs that of the attacker. It is a very modern notion that exploits
the power of the long tail. When Wikipedia started I never thought it
would work, but it has proven to be a great success for some of the
same reasons.
I also do think that there is potential value in a form of unforgeable
token whose production rate is predictable and can't be influenced
by corrupt parties. This would be more analogous to gold than to fiat
currencies. Nick Szabo wrote many years ago about what he called "bit
gold"[1] and this could be an implementation of that concept. There have
also been proposals for building light-weight anonymous payment schemes on
top of heavy-weight non-anonymous systems, so Bitcoin could be leveraged
to allow for anonymity even beyond the mechanisms discussed in the paper.
Unfortunately I am having trouble fully understanding the system. The
paper describes key concepts and some data structures, but does not
clearly specify the various rules and verifications that the participants
in the system would have to follow.
In particular I don't understand exactly what verifications P2P nodes
perform when they receive new blocks from other nodes, and how they
handle transactions that have been broadcast to them. For example, it
is mentioned that if a broadcast transaction does not reach all nodes,
it is OK, as it will get into the block chain before long. How does this
happen - what if the node that creates the "next" block (the first node
to find the hashcash collision) did not hear about the transaction,
and then a few more blocks get added also by nodes that did not hear
about that transaction? Do all the nodes that did hear it keep that
transaction around, hoping to incorporate it into a block once they get
lucky enough to be the one which finds the next collision?
Or for example, what if a node is keeping two or more chains around as
it waits to see which grows fastest, and a block comes in for chain A
which would include a double-spend of a coin that is in chain B? Is that
checked for or not? (This might happen if someone double-spent and two
different sets of nodes heard about the two different transactions with
the same coin.)
This kind of data management, and the rules for handling all the packets
that are flowing around is largely missing from the paper.
I also don't understand exactly how double-spending, or cancelling
transactions, is accomplished by a superior attacker who is able to muster
more computing power than all the honest participants. I see that he can
create new blocks and add them to create the longest chain, but how can
he erase or add old transactions in the chain? As the attacker sends out
his new blocks, aren't there consistency checks which honest nodes can
perform, to make sure that nothing got erased? More explanation of this
attack would be helpful, in order to judge the gains to an attacker from
this, versus simply using his computing power to mint new coins honestly.
As far as the spending transactions, what checks does the recipient of a
coin have to perform? Does she need to go back through the coin's entire
history of transfers, and make sure that every transaction on the list is
indeed linked into the "timestamp" block chain? Or can she just do the
latest one? Do the timestamp nodes check transactions, making sure that
the previous transaction on a coin is in the chain, thereby enforcing
the rule that all transactions in the chain represent valid coins?
Sorry about all the questions, but as I said this does seem to be a
very promising and original idea, and I am looking forward to seeing
how the concept is further developed. It would be helpful to see a more
process oriented description of the idea, with concrete details of the
data structures for the various objects (coins, blocks, transactions),
the data which is included in messages, and algorithmic descriptions
of the procedures for handling the various events which would occur in
this system. You mentioned that you are working on an implementation,
but I think a more formal, text description of the system would be a
helpful next step.
Hal Finney
[1] http://unenumerated.blogspot.com/2005/12/bit-gold.html
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 08, 2008 — source: sni-emails.json#email-10
Ray Dillinger:
> the "currency" is inflationary at about 35%
> as that's how much faster computers get annually
> ... the inflation rate of 35% is almost guaranteed
> by the technology
Increasing hardware speed is handled: "To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases."
As computers get faster and the total computing power applied to creating bitcoins increases, the difficulty increases proportionally to keep the total new production constant. Thus, it is known in advance how many new bitcoins will be created every year in the future.
The fact that new coins are produced means the money supply increases by a planned amount, but this does not necessarily result in inflation. If the supply of money increases at the same rate that the number of people using it increases, prices remain stable. If it does not increase as fast as demand, there will be deflation and early holders of money will see its value increase.
Coins have to get initially distributed somehow, and a constant rate seems like the best formula.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 09, 2008 — source: sni-emails.json#email-11
Hal Finney wrote:
> it is mentioned that if a broadcast transaction does not reach all nodes,
> it is OK, as it will get into the block chain before long. How does this
> happen - what if the node that creates the "next" block (the first node
> to find the hashcash collision) did not hear about the transaction,
> and then a few more blocks get added also by nodes that did not hear
> about that transaction? Do all the nodes that did hear it keep that
> transaction around, hoping to incorporate it into a block once they get
> lucky enough to be the one which finds the next collision?
Right, nodes keep transactions in their working set until they get into a block. If a transaction reaches 90% of nodes, then each time a new block is found, it has a 90% chance of being in it.
> Or for example, what if a node is keeping two or more chains around as
> it waits to see which grows fastest, and a block comes in for chain A
> which would include a double-spend of a coin that is in chain B? Is that
> checked for or not? (This might happen if someone double-spent and two
> different sets of nodes heard about the two different transactions with
> the same coin.)
That does not need to be checked for. The transaction in whichever branch ends up getting ahead becomes the valid one, the other is invalid. If someone tries to double spend like that, one and only one spend will always become valid, the others invalid.
Receivers of transactions will normally need to hold transactions for perhaps an hour or more to allow time for this kind of possibility to be resolved. They can still re-spend the coins immediately, but they should wait before taking an action such as shipping goods.
> I also don't understand exactly how double-spending, or cancelling
> transactions, is accomplished by a superior attacker who is able to muster
> more computing power than all the honest participants. I see that he can
> create new blocks and add them to create the longest chain, but how can
> he erase or add old transactions in the chain? As the attacker sends out
> his new blocks, aren't there consistency checks which honest nodes can
> perform, to make sure that nothing got erased? More explanation of this
> attack would be helpful, in order to judge the gains to an attacker from
> this, versus simply using his computing power to mint new coins honestly.
The attacker isn't adding blocks to the end. He has to go back and redo the block his transaction is in and all the blocks after it, as well as any new blocks the network keeps adding to the end while he's doing that. He's rewriting history. Once his branch is longer, it becomes the new valid one.
This touches on a key point. Even though everyone present may see the shenanigans going on, there's no way to take advantage of that fact.
It is strictly necessary that the longest chain is always considered the valid one. Nodes that were present may remember that one branch was there first and got replaced by another, but there would be no way for them to convince those who were not present of this. We can't have subfactions of nodes that cling to one branch that they think was first, others that saw another branch first, and others that joined later and never saw what happened. The CPU power proof-of-work vote must have the final say. The only way for everyone to stay on the same page is to believe that the longest chain is always the valid one, no matter what.
> As far as the spending transactions, what checks does the recipient of a
> coin have to perform? Does she need to go back through the coin's entire
> history of transfers, and make sure that every transaction on the list is
> indeed linked into the "timestamp" block chain? Or can she just do the
> latest one?
The recipient just needs to verify it back to a depth that is sufficiently far back in the block chain, which will often only require a depth of 2 transactions. All transactions before that can be discarded.
> Do the timestamp nodes check transactions, making sure that
> the previous transaction on a coin is in the chain, thereby enforcing
> the rule that all transactions in the chain represent valid coins?
Right, exactly. When a node receives a block, it checks the signatures of every transaction in it against previous transactions in blocks. Blocks can only contain transactions that depend on valid transactions in previous blocks or the same block. Transaction C could depend on transaction B in the same block and B depends on transaction A in an earlier block.
> Sorry about all the questions, but as I said this does seem to be a
> very promising and original idea, and I am looking forward to seeing
> how the concept is further developed. It would be helpful to see a more
> process oriented description of the idea, with concrete details of the
> data structures for the various objects (coins, blocks, transactions),
> the data which is included in messages, and algorithmic descriptions
> of the procedures for handling the various events which would occur in
> this system. You mentioned that you are working on an implementation,
> but I think a more formal, text description of the system would be a
> helpful next step.
I appreciate your questions. I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec. You're already right about most of your assumptions where you filled in the blanks.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 09, 2008 — source: sni-emails.json#email-12
James A. Donald wrote:
> The core concept is that lots of entities keep complete and consistent
> information as to who owns which bitcoins.
>
> But maintaining consistency is tricky. It is not clear to me what
> happens when someone reports one transaction to one maintainer, and
> someone else transports another transaction to another maintainer. The
> transaction cannot be known to be valid until it has been incorporated
> into a globally shared view of all past transactions, and no one can
> know that a globally shared view of all past transactions is globally
> shared until after some time has passed, and after many new
> transactions have arrived.
>
> Did you explain how to do this, and it just passed over my head, or
> were you confident it could be done, and a bit vague as to the details?
The proof-of-work chain is the solution to the synchronisation problem, and to knowing what the globally shared view is without having to trust anyone.
A transaction will quickly propagate throughout the network, so if two versions of the same transaction were reported at close to the same time, the one with the head start would have a big advantage in reaching many more nodes first. Nodes will only accept the first one they see, refusing the second one to arrive, so the earlier transaction would have many more nodes working on incorporating it into the next proof-of-work. In effect, each node votes for its viewpoint of which transaction it saw first by including it in its proof-of-work effort.
If the transactions did come at exactly the same time and there was an even split, it's a toss up based on which gets into a proof-of-work first, and that decides which is valid.
When a node finds a proof-of-work, the new block is propagated throughout the network and everyone adds it to the chain and starts working on the next block after it. Any nodes that had the other transaction will stop trying to include it in a block, since it's now invalid according to the accepted chain.
The proof-of-work chain is itself self-evident proof that it came from the globally shared view. Only the majority of the network together has enough CPU power to generate such a difficult chain of proof-of-work. Any user, upon receiving the proof-of-work chain, can see what the majority of the network has approved. Once a transaction is hashed into a link that's a few links back in the chain, it is firmly etched into the global history.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (James A. Donald) — November 09, 2008 — source: sni-emails.json#email-13
Satoshi Nakamoto wrote:
> The bandwidth might not be as prohibitive as you
> think. A typical transaction would be about 400 bytes
> (ECC is nicely compact). Each transaction has to be
> broadcast twice, so lets say 1KB per transaction.
> Visa processed 37 billion transactions in FY2008, or
> an average of 100 million transactions per day. That
> many transactions would take 100GB of bandwidth, or
> the size of 12 DVD or 2 HD quality movies, or about
> $18 worth of bandwidth at current prices.
The trouble is, you are comparing with the Bankcard
network.
But a new currency cannot compete directly with an old,
because network effects favor the old.
You have to go where Bankcard does not go.
At present, file sharing works by barter for bits. This,
however requires the double coincidence of wants. People
only upload files they are downloading, and once the
download is complete, stop seeding. So only active
files, files that quite a lot of people want at the same
time, are available.
File sharing requires extremely cheap transactions,
several transactions per second per client, day in and
day out, with monthly transaction costs being very small
per client, so to support file sharing on bitcoins, we
will need a layer of account money on top of the
bitcoins, supporting transactions of a hundred
thousandth the size of the smallest coin, and to support
anonymity, chaumian money on top of the account money.
Let us call a bitcoin bank a bink. The bitcoins stand
in the same relation to account money as gold stood in
the days of the gold standard. The binks, not trusting
each other to be liquid when liquidity is most needed,
settle out any net discrepancies with each other by
moving bit coins around once every hundred thousand
seconds or so, so bitcoins do not change owners that
often, Most transactions cancel out at the account
level. The binks demand bitcoins of each other only
because they don't want to hold account money for too
long. So a relatively small amount of bitcoins
infrequently transacted can support a somewhat larger
amount of account money frequently transacted.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (James A. Donald) — November 09, 2008 — source: sni-emails.json#email-14
--
Satoshi Nakamoto wrote:
> The proof-of-work chain is the solution to the
> synchronisation problem, and to knowing what the
> globally shared view is without having to trust
> anyone.
>
> A transaction will quickly propagate throughout the
> network, so if two versions of the same transaction
> were reported at close to the same time, the one with
> the head start would have a big advantage in reaching
> many more nodes first. Nodes will only accept the
> first one they see, refusing the second one to arrive,
> so the earlier transaction would have many more nodes
> working on incorporating it into the next
> proof-of-work. In effect, each node votes for its
> viewpoint of which transaction it saw first by
> including it in its proof-of-work effort.
OK, suppose one node incorporates a bunch of
transactions in its proof of work, all of them honest
legitimate single spends and another node incorporates a
slightly different bunch of transactions in its proof of
work, all of them equally honest legitimate single
spends, and both proofs are generated at about the same
time.
What happens then?
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (James A. Donald) — November 09, 2008 — source: sni-emails.json#email-15
Satoshi Nakamoto wrote:
> Increasing hardware speed is handled: "To compensate
> for increasing hardware speed and varying interest in
> running nodes over time, the proof-of-work difficulty
> is determined by a moving average targeting an average
> number of blocks per hour. If they're generated too
> fast, the difficulty increases."
This does not work - your proposal involves
complications I do not think you have thought through.
Furthermore, it cannot be made to work, as in the
proposed system the work of tracking who owns what coins
is paid for by seigniorage, which requires inflation.
This is not an intolerable flaw - predictable inflation
is less objectionable than inflation that gets jiggered
around from time to time to transfer wealth from one
voting block to another.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 09, 2008 — source: sni-emails.json#email-16
James A. Donald wrote:
>OK, suppose one node incorporates a bunch of
>transactions in its proof of work, all of them honest
>legitimate single spends and another node incorporates a
>different bunch of transactions in its proof of
>work, all of them equally honest legitimate single
>spends, and both proofs are generated at about the same
>time.
>
>What happens then?
They both broadcast their blocks. All nodes receive them and keep both, but only work on the one they received first. We'll suppose exactly half received one first, half the other.
In a short time, all the transactions will finish propagating so that everyone has the full set. The nodes working on each side will be trying to add the transactions that are missing from their side. When the next proof-of-work is found, whichever previous block that node was working on, that branch becomes longer and the tie is broken. Whichever side it is, the new block will contain the other half of the transactions, so in either case, the branch will contain all transactions. Even in the unlikely event that a split happened twice in a row, both sides of the second split would contain the full set of transactions anyway.
It's not a problem if transactions have to wait one or a few extra cycles to get into a block.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (James A. Donald) — November 09, 2008 — source: sni-emails.json#email-17
--
> James A. Donald wrote:
>> OK, suppose one node incorporates a bunch of
>> transactions in its proof of work, all of them honest
>> legitimate single spends and another node
>> incorporates a different bunch of transactions in its
>> proof of work, all of them equally honest legitimate
>> single spends, and both proofs are generated at about
>> the same time.
>>
>> What happens then?
Satoshi Nakamoto wrote:
> They both broadcast their blocks. All nodes receive
> them and keep both, but only work on the one they
> received first. We'll suppose exactly half received
> one first, half the other.
>
> In a short time, all the transactions will finish
> propagating so that everyone has the full set. The
> nodes working on each side will be trying to add the
> transactions that are missing from their side. When
> the next proof-of-work is found, whichever previous
> block that node was working on, that branch becomes
> longer and the tie is broken. Whichever side it is,
> the new block will contain the other half of the
> transactions, so in either case, the branch will
> contain all transactions. Even in the unlikely event
> that a split happened twice in a row, both sides of
> the second split would contain the full set of
> transactions anyway.
>
> It's not a problem if transactions have to wait one or
> a few extra cycles to get into a block.
So what happened to the coin that lost the race?
On the one hand, we want people who make coins to be
motivated to keep and record all transactions, and
obtain an up to date record of all transactions in a
timely manner. On the other hand, it is a bit harsh if
the guy who came second is likely to lose his coin.
Further, your description of events implies restrictions
on timing and coin generation - that the entire network
generates coins slowly compared to the time required for
news of a new coin to flood the network, otherwise the
chains diverge more and more, and no one ever knows
which chain is the winner.
You need to make these restrictions explicit, for
network flood time may well be quite slow.
Which implies that the new coin rate is slower.
We want spenders to have certainty that their
transaction is valid at the time it takes a spend to
flood the network, not at the time it takes for branch
races to be resolved.
At any given time, for example at 1 040 689 138 seconds
we can look back at the past and say:
At 1 040 688 737 seconds, node 5 was *it*, and
he incorporated all the coins he had discovered
into the chain, and all the new transactions he
knew about on top of the previous link
At 1 040 688 792 seconds, node 2 was *it*, and
he incorporated all the coins he had discovered
into the chain, and all the new transactions he
knew about into the chain on top of node 5's
link.
At 1 040 688 745 seconds, node 7 was *it*, and
he incorporated all the coins he had discovered
into the chain, and all the new transactions he
knew about into the chain on top of node 2's
link.
But no one can know who is *it* right now
So how does one know when to reveal one's coins? One
solution is that one does not. One incorporates a hash
of the coin secret whenever one thinks one might be
*it*, and after that hash is securely in the chain,
after one knows that one was *it* at the time, one can
then safely spend the coin that one has found, revealing
the secret.
This solution takes care of the coin revelation problem,
but does not solve the spend recording problem. If one
node is ignoring all spends that it does not care about,
it suffers no adverse consequences. We need a protocol
in which your prospects of becoming *it* also depend on
being seen by other nodes as having a reasonably up to
date and complete list of spends - which this protocol
is not, and your protocol is not either.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 10, 2008 — source: sni-emails.json#email-18
James A. Donald wrote:
> Furthermore, it cannot be made to work, as in the
> proposed system the work of tracking who owns what coins
> is paid for by seigniorage, which requires inflation.
If you're having trouble with the inflation issue, it's easy to tweak it for transaction fees instead. It's as simple as this: let the output value from any transaction be 1 cent less than the input value. Either the client software automatically writes transactions for 1 cent more than the intended payment value, or it could come out of the payee's side. The incentive value when a node finds a proof-of-work for a block could be the total of the fees in the block.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 10, 2008 — source: sni-emails.json#email-19
James A. Donald wrote:
> So what happened to the coin that lost the race?
>
> ... it is a bit harsh if the guy who came second
> is likely to lose his coin.
When there are multiple double-spent versions of the same transaction, one and only one will become valid.
The receiver of a payment must wait an hour or so before believing that it's valid. The network will resolve any possible double-spend races by then.
The guy who received the double-spend that became invalid never thought he had it in the first place. His software would have shown the transaction go from "unconfirmed" to "invalid". If necessary, the UI can be made to hide transactions until they're sufficiently deep in the block chain.
> Further, your description of events implies restrictions
> on timing and coin generation - that the entire network
> generates coins slowly compared to the time required for
> news of a new coin to flood the network
Sorry if I didn't make that clear. The target time between blocks will probably be 10 minutes.
Every block includes its creation time. If the time is off by more than 36 hours, other nodes won't work on it. If the timespan over the last 6*24*30 blocks is less than 15 days, blocks are being generated too fast and the proof-of-work difficulty doubles. Everyone does the same calculation with the same chain data, so they all get the same result at the same link in the chain.
> We want spenders to have certainty that their
> transaction is valid at the time it takes a spend to
> flood the network, not at the time it takes for branch
> races to be resolved.
Instantant non-repudiability is not a feature, but it's still much faster than existing systems. Paper cheques can bounce up to a week or two later. Credit card transactions can be contested up to 60 to 180 days later. Bitcoin transactions can be sufficiently irreversible in an hour or two.
> If one node is ignoring all spends that it does not
> care about, it suffers no adverse consequences.
With the transaction fee based incentive system I recently posted, nodes would have an incentive to include all the paying transactions they receive.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (James A. Donald) — November 13, 2008 — source: sni-emails.json#email-20
Satoshi Nakamoto wrote:
> When there are multiple double-spent versions of the
> same transaction, one and only one will become valid.
That is not the question I am asking.
It is not trust that worries me, it is how it is
possible to have a a globally shared view even if
everyone is well behaved.
The process for arriving at a globally shared view of
who owns what bitgold coins is insufficiently specified.
Once specified, then we can start considering whether
everyone has incentives to behave correctly.
It is not sufficient that everyone knows X. We also
need everyone to know that everyone knows X, and that
everyone knows that everyone knows that everyone knows X
- which, as in the Byzantine Generals problem, is the
classic hard problem of distributed data processing.
This problem becomes harder when X is quite possibly a
very large amount of data - agreement on who was the
owner of every bitgold coin at such and such a time.
And then on top of that we need everyone to have a
motive to behave in such a fashion that agreement
arises. I cannot see that they have motive when I do
not know the behavior to be motivated.
You keep repeating your analysis of the system under
attack. We cannot say how the system will behave under
attack until we know how the system is supposed to
behave when not under attack.
If there are a lot of transactions, it is hard to
efficiently discover the discrepancies between one
node's view and another node's view, and because new
transactions are always arriving, no two nodes will ever
have the same view, even if all nodes are honest, and
all reported transactions are correct and true single
spends.
We should be able to accomplish a system where two nodes
are likely to come to agreement as to who owned what
bitgold coins at some very recent past time, but it is
not simple to do so.
If one node constructs a hash that represents its
knowledge of who owned what bitgold coins at a
particular time, and another node wants to check that
hash, it is not simple to do it in such a way that
agreement is likely, and disagreement between honest
well behaved nodes is efficiently detected and
efficiently resolved.
And if we had a specification of how agreement is
generated, it is not obvious why the second node has
incentive to check that hash.
The system has to work in such a way that nodes can
easily and cheaply change their opinion about recent
transactions, so as to reach consensus, but in order to
provide finality and irreversibility, once consensus has
been reached, and then new stuff has be piled on top of
old consensus, in particular new bitgold has been piled
on top of old consensus, it then becomes extremely
difficult to go back and change what was decided.
Saying that is how it works, does not give us a method
to make it work that way.
> The receiver of a payment must wait an hour or so
> before believing that it's valid. The network will
> resolve any possible double-spend races by then.
You keep discussing attacks. I find it hard to think
about response to attack when it is not clear to me what
normal behavior is in the case of good conduct by each
and every party.
Distributed databases are *hard* even when all the
databases perfectly follow the will of a single owner.
Messages get lost, links drop, syncrhonization delays
become abnormal, and entire machines go up in flames,
and the network as a whole has to take all this in its
stride.
Figuring out how to do this is hard, even in the
complete absence of attacks. Then when we have figured
out how to handle all this, then come attacks.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Hal Finney) — November 13, 2008 — source: sni-emails.json#email-21
James A. Donald writes:
> Satoshi Nakamoto wrote:
> > When there are multiple double-spent versions of the
> > same transaction, one and only one will become valid.
>
> That is not the question I am asking.
>
> It is not trust that worries me, it is how it is
> possible to have a a globally shared view even if
> everyone is well behaved.
>
> The process for arriving at a globally shared view of
> who owns what bitgold coins is insufficiently specified.
I agree that the description is not completely clear on how these matters
are handled. Satoshi has suggested that releasing source code may be the
best way to clarify the design. As I have tried to work through details on
my own, it does appear that the rules become rather complicated and indeed
one needs at least a pseudo-code algorithm to specify the behavior. So
perhaps writing real code is not a bad way to go. I found that there is
a sourceforge project set up for bitgold, although it does not have any
code yet.
In answer to James' specific question, about what happens when different
nodes see different sets of transactions, due to imperfect broadcast, here
is how I understand it. Each node must be prepared to maintain potentially
several "candidate" block chains, each of which may eventually turn out
to become the longest one, the one which wins. Once a given block chain
becomes sufficiently longer than a competitor, the shorter one can be
deleted. This length differential is a parameter which depends on the
node's threat model for how much compute power an attacker can marshall,
in terms of the fraction of the "honst" P2P network's work capacity,
and is estimated in the paper. The idea is that once a chain gets far
enough behind the longest one, there is essentially no chance that it
can ever catch up.
In order to resolve the issue James raised, I think it is necessary
that nodes keep a separate pending-transaction list associated with
each candidate chain. This list would include all transactions the node
has received (via broadcast by the transactees) but which have not yet
been incorporated into that block chain. At any given time, the node is
working to extend the longest block chain, and the block it is working
to find a hash collision for will include all of the pending transactions
associated with that chain.
I think that this way, when a candidate chain is deleted because it
got too much shorter than the longest one, transactions in it are
not lost, but have continued to be present in the pending-transaction
list associated with the longest chain, in those nodes which heard the
original transaction broadcast. (I have also considered whether nodes
should add transactions to their pending-transaction list that they
learn about through blocks from other nodes, even if those blocks do
not end up making their way into the longest block chain; but I'm not
sure if that is necessary or helpful.)
Once these rules are clarified, more formal modeling will be helpful in
understanding the behavior of the network given imperfect reliability. For
example, if on average a fraction f of P2P nodes receive a given
transaction broadcast, then I think one would expect 1/f block-creation
times to elapse before the transaction appears in what is destined to
become the longest chain. One might also ask, given that the P2P network
broadcast is itself imperfectly reliable, how many candidate chains
must a given node keep track of at one time, on average? Or as James
raised earlier, if the network broadcast is reliable but depends on a
potentially slow flooding algorithm, how does that impact performance?
> And then on top of that we need everyone to have a
> motive to behave in such a fashion that agreement
> arises. I cannot see that they have motive when I do
> not know the behavior to be motivated.
I am somewhat less worried about motivation. I'd be satisfied if the
system can meet the following criteria:
1. No single node operator, or small collection of node operators
which controls only a small fraction of overall network resources,
can effectively cheat, if other players are honest.
2. The long tail of node operators is sufficiently large that no small
collection of nodes can control more than a small fraction of overall
resources. (Here, the "tail" refers to a ranking based on amount of
resources controlled by each operator.)
3. The bitcoin system turns out to be socially useful and valuable, so
that node operators feel that they are making a beneficial contribution
to the world by their efforts (similar to the various "@Home" compute
projects where people volunteer their compute resources for good causes).
In this case it seems to me that simple altruism can suffice to keep the
network running properly.
> Distributed databases are *hard* even when all the
> databases perfectly follow the will of a single owner.
> Messages get lost, links drop, syncrhonization delays
> become abnormal, and entire machines go up in flames,
> and the network as a whole has to take all this in its
> stride.
A very good point, and a more complete specification is necessary in order
to understand how the network will respond to imperfections like this. I
am looking forward to seeing more detail emerge.
One thing I might mention is that in many ways bitcoin is two independent
ideas: a way of solving the kinds of problems James lists here, of
creating a globally consistent but decentralized database; and then using
it for a system similar to Wei Dai's b-money (which is referenced in the
paper) but transaction/coin based rather than account based. Solving the
global, massively decentralized database problem is arguably the harder
part, as James emphasizes. The use of proof-of-work as a tool for this
purpose is a novel idea well worth further review IMO.
Hal Finney
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 13, 2008 — source: sni-emails.json#email-22
James A. Donald wrote:
> It is not sufficient that everyone knows X. We also
> need everyone to know that everyone knows X, and that
> everyone knows that everyone knows that everyone knows X
> - which, as in the Byzantine Generals problem, is the
> classic hard problem of distributed data processing.
The proof-of-work chain is a solution to the Byzantine Generals' Problem. I'll try to rephrase it in that context.
A number of Byzantine Generals each have a computer and want to attack the King's wi-fi by brute forcing the password, which they've learned is a certain number of characters in length. Once they stimulate the network to generate a packet, they must crack the password within a limited time to break in and erase the logs, otherwise they will be discovered and get in trouble. They only have enough CPU power to crack it fast enough if a majority of them attack at the same time.
They don't particularly care when the attack will be, just that they all agree. It has been decided that anyone who feels like it will announce a time, and whatever time is heard first will be the official attack time. The problem is that the network is not instantaneous, and if two generals announce different attack times at close to the same time, some may hear one first and others hear the other first.
They use a proof-of-work chain to solve the problem. Once each general receives whatever attack time he hears first, he sets his computer to solve an extremely difficult proof-of-work problem that includes the attack time in its hash. The proof-of-work is so difficult, it's expected to take 10 minutes of them all working at once before one of them finds a solution. Once one of the generals finds a proof-of-work, he broadcasts it to the network, and everyone changes their current proof-of-work computation to include that proof-of-work in the hash they're working on. If anyone was working on a different attack time, they switch to this one, because its proof-of-work chain is now longer.
After two hours, one attack time should be hashed by a chain of 12 proofs-of-work. Every general, just by verifying the difficulty of the proof-of-work chain, can estimate how much parallel CPU power per hour was expended on it and see that it must have required the majority of the computers to produce that much proof-of-work in the allotted time. They had to all have seen it because the proof-of-work is proof that they worked on it. If the CPU power exhibited by the proof-of-work chain is sufficient to crack the password, they can safely attack at the agreed time.
The proof-of-work chain is how all the synchronisation, distributed database and global view problems you've asked about are solved.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 14, 2008 — source: sni-emails.json#email-23
Hal Finney wrote:
> I think it is necessary that nodes keep a separate
> pending-transaction list associated with each candidate chain.
> ... One might also ask ... how many candidate chains must
> a given node keep track of at one time, on average?
Fortunately, it's only necessary to keep a pending-transaction pool for the current best branch. When a new block arrives for the best branch, ConnectBlock removes the block's transactions from the pending-tx pool. If a different branch becomes longer, it calls DisconnectBlock on the main branch down to the fork, returning the block transactions to the pending-tx pool, and calls ConnectBlock on the new branch, sopping back up any transactions that were in both branches. It's expected that reorgs like this would be rare and shallow.
With this optimisation, candidate branches are not really any burden. They just sit on the disk and don't require attention unless they ever become the main chain.
> Or as James raised earlier, if the network broadcast
> is reliable but depends on a potentially slow flooding
> algorithm, how does that impact performance?
Broadcasts will probably be almost completely reliable. TCP transmissions are rarely ever dropped these days, and the broadcast protocol has a retry mechanism to get the data from other nodes after a while. If broadcasts turn out to be slower in practice than expected, the target time between blocks may have to be increased to avoid wasting resources. We want blocks to usually propagate in much less time than it takes to generate them, otherwise nodes would spend too much time working on obsolete blocks.
I'm planning to run an automated test with computers randomly sending payments to each other and randomly dropping packets.
> 3. The bitcoin system turns out to be socially useful and valuable, so
> that node operators feel that they are making a beneficial contribution
> to the world by their efforts (similar to the various "@Home" compute
> projects where people volunteer their compute resources for good causes).
>
> In this case it seems to me that simple altruism can suffice to keep the
> network running properly.
It's very attractive to the libertarian viewpoint if we can explain it properly. I'm better with code than with words though.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Ray Dillinger) — November 15, 2008 — source: sni-emails.json#email-24
Okay.... I'm going to summarize this protocol as I understand it.
I'm filling in some operational details that aren't in the paper
by supplementing what you wrote with what my own "design sense"
tells me are critical missing bits or "obvious" methodologies for
use.
First, people spend computer power creating a pool of coins to use
as money. Each coin is a proof-of-work meeting whatever criteria
were in effect for money at the time it was created. The time of
creation (and therefore the criteria) is checkable later because
people can see the emergence of this particular coin in the
transaction chain and track it through all its "consensus view"
spends. (more later on coin creation tied to adding a link).
When a coin is spent, the buyer and seller digitally sign a (blinded)
transaction record, and broadcast it to a bunch of nodes whose purpose
is keeping track of consensus regarding coin ownership. If someone
double spends, then the transaction record can be unblinded revealing
the identity of the cheater. This is done via a fairly standard cut-
and-choose algorithm where the buyer responds to several challenges
with secret shares, and the seller then asks him to "unblind" and
checks all but one, verifying that they do contain secret shares any
two of which are sufficient to identify the buyer. In this case the
seller accepts the unblinded spend record as "probably" containing
a valid secret share.
The nodes keeping track of consensus regarding coin ownership are in
a loop where they are all trying to "add a link" to the longest chain
they've so far recieved. They have a pool of reported transactions
which they've not yet seen in a "consensus" signed chain. I'm going
to call this pool "A". They attempt to add a link to the chain by
moving everything from pool A into a pool "L" and using a CPU-
intensive digital signature algorithm to sign the chain including
the new block L. This results in a chain extended by a block
containing all the transaction records they had in pool L, plus
the node's digital signature. While they do this, new
transaction records continue to arrive and go into pool A again
for the next cycle of work.
They may also recieve chains as long as the one they're trying to
extend while they work, in which the last few "links" are links
that are *not* in common with the chain on which they're working.
These they ignore. (? Do they ignore them? Under what
circumstances would these become necessary to ever look at again,
bearing in mind that any longer chain based on them will include
them?)
But if they recieve a _longer_ chain while working, they
immediately check all the transactions in the new links to make
sure it contains no double spends and that the "work factors" of
all new links are appropriate. If it contains a double spend,
then they create a "transaction" which is a proof of double
spending, add it to their pool A, broadcast it, and continue work.
If one of the "new" links has an inappropriate work factor (ie,
someone didn't put enough CPU into it for it to be "licit"
according to the rules) a new "transaction" which is a proof
of the protocol violation by the link-creating node is created,
broadcast, and added to pool A, and the chain is rejected. In
the case of no double spends and appropriate work factors for
all links not yet seen, they accept the new chain as consensus.
If the new chain is accepted, then they give up on adding their
current link, dump all the transactions from pool L back into pool
A (along with transactions they've recieved or created since
starting work), eliminate from pool A those transaction records
which are already part of a link in the new chain, and start work
again trying to extend the new chain.
If they complete work on a chain extended with their new link, they
broadcast it and immediately start work on another new link with
all the transactions that have accumulated in pool A since they
began work.
Do I understand it correctly?
Biggest Technical Problem:
Is there a mechanism to make sure that the "chain" does not consist
solely of links added by just the 3 or 4 fastest nodes? 'Cause a
broadcast transaction record could easily miss those 3 or 4 nodes
and if it does, and those nodes continue to dominate the chain, the
transaction might never get added.
To remedy this, you need to either ensure provable propagation of
transactions, or vary the work factor for a node depending on how
many links have been added since that node's most recent link.
Unfortunately, both measures can be defeated by sock puppets.
This is probably the worst problem with your protocol as it
stands right now; you need some central point to control the
identities (keys) of the nodes and prevent people from making
new sock puppets.
Provable propagation would mean that When Bob accepts a new chain
from Alice, he needs to make sure that Alice has (or gets) all
transactions in his "A" and "L" pools. He sends them, and
Alice sends back a signed hash to prove she got them. Once
Alice has recieved this block of transactions, if any subsequent
chains including a link added by Alice do not include those
transactions at or before that link, then Bob should be able to
publish the block he sent Alice, along with her signature, in a
transaction as proof that Alice violated protocol. Sock puppets
defeat this because Alice just signs subsequent chains using a
new key, pretending to be a different node.
If we go with varying the work factor depending on how many new
links there are, then we're right back to domination by the 3
or 4 fastest nodes, except now they're joined by 600 or so
sock puppets which they use to avoid the work factor penalty.
If we solve the sock-puppet issue, or accept that there's a central
point controlling the generation of new keys, then generation of
coins should be tied to the act of successfully adding a block to
the "consensus" chain. This is simple to do; creation of a coin
is a transaction, it gets added along with all the other transactions
in the block. But you can only create one coin per link, and of
course if your version of the chain isn't the one that gets accepted,
then in the "accepted" view you don't have the coin and can't spend
it. This gives the people maintaining the consensus database a
reason to spend CPU cycles, especially since the variance in work
factor by number of links added since their own last link (outlined
above) guarantees that everyone, not just the 3 or 4 fastest nodes,
occasionally gets the opportunity to create a coin.
Also, the work requirement for adding a link to the chain should
vary (again exponentially) with the number of links added to that
chain in the previous week, causing the rate of coin generation
(and therefore inflation) to be strictly controlled.
You need coin aggregation for this to scale. There needs to be
a "provable" transaction where someone retires ten single coins
and creates a new coin with denomination ten, etc. This is not
too hard, using the same infrastructure you've already got; it
simply becomes part of the chain, and when the chain is accepted
consensus, then everybody can see that it happened.
Bear
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 15, 2008 — source: sni-emails.json#email-25
I'll try and hurry up and release the sourcecode as soon as possible to serve as a reference to help clear up all these implementation questions.
Ray Dillinger (Bear) wrote:
> When a coin is spent, the buyer and seller digitally sign a (blinded)
> transaction record.
Only the buyer signs, and there's no blinding.
> If someone double spends, then the transaction record
> can be unblinded revealing the identity of the cheater.
Identities are not used, and there's no reliance on recourse. It's all prevention.
> This is done via a fairly standard cut-and-choose
> algorithm where the buyer responds to several challenges
> with secret shares
No challenges or secret shares. A basic transaction is just what you see in the figure in section 2. A signature (of the buyer) satisfying the public key of the previous transaction, and a new public key (of the seller) that must be satisfied to spend it the next time.
> They may also receive chains as long as the one they're trying to
> extend while they work, in which the last few "links" are links
> that are *not* in common with the chain on which they're working.
> These they ignore.
Right, if it's equal in length, ties are broken by keeping the earliest one received.
> If it contains a double spend, then they create a "transaction"
> which is a proof of double spending, add it to their pool A,
> broadcast it, and continue work.
There's no need for reporting of "proof of double spending" like that. If the same chain contains both spends, then the block is invalid and rejected.
Same if a block didn't have enough proof-of-work. That block is invalid and rejected. There's no need to circulate a report about it. Every node could see that and reject it before relaying it.
If there are two competing chains, each containing a different version of the same transaction, with one trying to give money to one person and the other trying to give the same money to someone else, resolving which of the spends is valid is what the whole proof-of-work chain is about.
We're not "on the lookout" for double spends to sound the alarm and catch the cheater. We merely adjudicate which one of the spends is valid. Receivers of transactions must wait a few blocks to make sure that resolution has had time to complete. Would be cheaters can try and simultaneously double-spend all they want, and all they accomplish is that within a few blocks, one of the spends becomes valid and the others become invalid. Any later double-spends are immediately rejected once there's already a spend in the main chain.
Even if an earlier spend wasn't in the chain yet, if it was already in all the nodes' pools, then the second spend would be turned away by all those nodes that already have the first spend.
> If the new chain is accepted, then they give up on adding their
> current link, dump all the transactions from pool L back into pool
> A (along with transactions they've received or created since
> starting work), eliminate from pool A those transaction records
> which are already part of a link in the new chain, and start work
> again trying to extend the new chain.
Right. They also refresh whenever a new transaction comes in, so L pretty much contains everything in A all the time.
> CPU-intensive digital signature algorithm to
> sign the chain including the new block L.
It's a Hashcash style SHA-256 proof-of-work (partial pre-image of zero), not a signature.
> Is there a mechanism to make sure that the "chain" does not consist
> solely of links added by just the 3 or 4 fastest nodes? 'Cause a
> broadcast transaction record could easily miss those 3 or 4 nodes
> and if it does, and those nodes continue to dominate the chain, the
> transaction might never get added.
If you're thinking of it as a CPU-intensive digital signing, then you may be thinking of a race to finish a long operation first and the fastest always winning.
The proof-of-work is a Hashcash style SHA-256 collision finding. It's a memoryless process where you do millions of hashes a second, with a small chance of finding one each time. The 3 or 4 fastest nodes' dominance would only be proportional to their share of the total CPU power. Anyone's chance of finding a solution at any time is proportional to their CPU power.
There will be transaction fees, so nodes will have an incentive to receive and include all the transactions they can. Nodes will eventually be compensated by transaction fees alone when the total coins created hits the pre-determined ceiling.
> Also, the work requirement for adding a link to the chain should
> vary (again exponentially) with the number of links added to that
> chain in the previous week, causing the rate of coin generation
> (and therefore inflation) to be strictly controlled.
Right.
> You need coin aggregation for this to scale. There needs to be
> a "provable" transaction where someone retires ten single coins
> and creates a new coin with denomination ten, etc.
Every transaction is one of these. Section 9, Combining and Splitting Value.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Ray Dillinger) — November 15, 2008 — source: sni-emails.json#email-26
On Sat, 2008-11-15 at 12:43 +0800, Satoshi Nakamoto wrote:
> I'll try and hurry up and release the sourcecode as soon as possible
> to serve as a reference to help clear up all these implementation
> questions.
> Ray Dillinger (Bear) wrote:
> > When a coin is spent, the buyer and seller digitally sign a (blinded)
> > transaction record.
>
> Only the buyer signs, and there's no blinding.
>
>
> > If someone double spends, then the transaction record
> > can be unblinded revealing the identity of the cheater.
>
> Identities are not used, and there's no reliance on recourse. It's all prevention.
Okay, that's surprising. If you're not using buyer/seller
identities, then you are not checking that a spend is being made
by someone who actually is the owner of (on record as having
recieved) the coin being spent.
There are three categories of identity that are useful to
think about. Category one: public. Real-world identities
are a matter of record and attached to every transaction.
Category two: Pseudonymous. There are persistent "identities"
within the system and people can see if something was done by
the same nym that did something else, but there's not necessarily
any way of linking the nyms with real-world identities. Category
three: unlinkably anonymous. There is no concept of identity,
persistent or otherwise. No one can say or prove whether the
agents involved in any transaction are the same agents as involved
in any other transaction.
Are you claiming category 3 as you seem to be, or category 2?
Lots of people don't distinguish between anonymous and
pseudonymous protocols, so it's worth asking exactly what
you mean here.
Anyway: I'll proceed on the assumption that you meant very
nearly (as nearly as I can imagine, anyway) what you said,
unlinkably anonymous. That means that instead of an "identity",
a spender has to demonstrate knowledge of a secret known only
to the real owner of the coin. One way to do this would be
to have the person recieving the coin generate an asymmetric
key pair, and then have half of it published with the
transaction. In order to spend the coin later, s/he must
demonstrate posession of the other half of the asymmetric
key pair, probably by using it to sign the key provided by
the new seller. So we cannot prove anything about "identity",
but we can prove that the spender of the coin is someone who
knows a secret that the person who recieved the coin knows.
And what you say next seems to confirm this:
> No challenges or secret shares. A basic transaction is just
> what you see in the figure in section 2. A signature (of the
> buyer) satisfying the public key of the previous transaction,
> and a new public key (of the seller) that must be satisfied to
> spend it the next time.
Note, even though this doesn't involve identity per se, it still
makes the agent doing the spend linkable to the agent who
earlier recieved the coin, so these transactions are linkable.
In order to counteract this, the owner of the coin needs to
make a transaction, indistinguishable to others from any
normal transaction, in which he creates a new key pair and
transfers the coin to its posessor (ie, has one sock puppet
"spend" it to another). No change in real-world identity of
the owner, but the transaction "linkable" to the agent who spent
the coin is unlinked. For category-three unlinkability, this
has to be done a random number of times - maybe one to six
times?
BTW, could you please learn to use carriage returns?? Your
lines are scrolling stupidly off to the right and I have to
scroll to see what the heck you're saying, then edit to add
carriage returns before I respond.
> > If it contains a double spend, then they create a "transaction"
> > which is a proof of double spending, add it to their pool A,
> > broadcast it, and continue work.
> There's no need for reporting of "proof of double spending" like
> that. If the same chain contains both spends, then the block is
> invalid and rejected.
> Same if a block didn't have enough proof-of-work. That block is
> invalid and rejected. There's no need to circulate a report
> about it. Every node could see that and reject it before relaying it.
Mmmm. I don't know if I'm comfortable with that. You're saying
there's no effort to identify and exclude nodes that don't
cooperate? I suspect this will lead to trouble and possible DOS
attacks.
> If there are two competing chains, each containing a different
> version of the same transaction, with one trying to give money
> to one person and the other trying to give the same money to
> someone else, resolving which of the spends is valid is what
> the whole proof-of-work chain is about.
Okay, when you say "same" transaction, and you're talking about
transactions that are obviously different, you mean a double
spend, right? Two transactions signed with the same key?
> We're not "on the lookout" for double spends to sound the alarm
> and catch the cheater. We merely adjudicate which one of the
> spends is valid. Receivers of transactions must wait a few
> blocks to make sure that resolution has had time to complete.
Until.... until what? How does anybody know when a transaction
has become irrevocable? Is "a few" blocks three? Thirty? A
hundred? Does it depend on the number of nodes? Is it logarithmic
or linear in number of nodes?
> Would be cheaters can try and simultaneously double-spend all
> they want, and all they accomplish is that within a few blocks,
> one of the spends becomes valid and the others become invalid.
But in the absence of identity, there's no downside to them
if spends become invalid, if they've already recieved the
goods they double-spent for (access to website, download,
whatever). The merchants are left holding the bag with
"invalid" coins, unless they wait that magical "few blocks"
(and how can they know how many?) before treating the spender
as having paid.
The consumers won't do this if they spend their coin and it takes
an hour to clear before they can do what they spent their coin on.
The merchants won't do it if there's no way to charge back a
customer when they find the that their coin is invalid because
the customer has doublespent.
> Even if an earlier spend wasn't in the chain yet, if it was
> already in all the nodes' pools, then the second spend would
> be turned away by all those nodes that already have the first
> spend.
So there's a possibility of an early catch when the broadcasts of
the initial simultaneous spends interfere with each other. I assume
here that the broadcasts are done by the sellers, since the buyer
has a possible disincentive to broadly disseminate spends.
> > If the new chain is accepted, then they give up on adding their
> > current link ... and start work again trying to extend the new
> > chain.
>
> Right. They also refresh whenever a new transaction comes in,
> so L pretty much contains everything in A all the time.
Okay, that's a big difference between a proof of work that takes
a huge set number of CPU cycles and a proof of work that takes a
tiny number of CPU cycles but has a tiny chance of success. You
can change the data set while working, and it doesn't mean you
need to start over. This is good in this case, as it means nobody
has to hold recently recieved transactions out of the link they're
working on.
> > Is there a mechanism to make sure that the "chain" does not consist
> > solely of links added by just the 3 or 4 fastest nodes?
> If you're thinking of it as a CPU-intensive digital signing, then
> you may be thinking of a race to finish a long operation first and
> the fastest always winning.
Right. That was the misconception I was working with. Again, the
difference between a proof taking a huge set number of CPU cycles
and a proof that takes a tiny number of CPU cycles but has a tiny
chance of success.
> Anyone's chance of finding a solution at any
> time is proportional to their CPU power.
It's like a random variation in the work factor; in this way it works
in your favor.
> There will be transaction fees, so nodes will have an incentive
> to receive and include all the transactions they can. Nodes
> will eventually be compensated by transaction fees alone when
> the total coins created hits the pre-determined ceiling.
I don't understand how "transaction fees" would work, and how the money
would find its way from the agents doing transactions to those running
the network. But the economic effect is the same (albeit somewhat
randomized) if adding a link to the chain allows the node to create
a coin, so I would stick with that.
Also, be aware that the compute power of different nodes can be
expected to vary by two orders of magnitude at any given moment in
history.
Bear
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 15, 2008 — source: sni-emails.json#email-27
Ray Dillinger wrote:
> One way to do this would be
> to have the person recieving the coin generate an asymmetric
> key pair, and then have half of it published with the
> transaction. In order to spend the coin later, s/he must
> demonstrate posession of the other half of the asymmetric
> key pair, probably by using it to sign the key provided by
> the new seller.
Right, it's ECC digital signatures. A new key pair is used for every
transaction.
It's not pseudonymous in the sense of nyms identifying people, but it
is at least a little pseudonymous in that the next action on a coin
can be identified as being from the owner of that coin.
> Mmmm. I don't know if I'm comfortable with that. You're saying
> there's no effort to identify and exclude nodes that don't
> cooperate? I suspect this will lead to trouble and possible DOS
> attacks.
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.
> Until.... until what? How does anybody know when a transaction
> has become irrevocable? Is "a few" blocks three? Thirty? A
> hundred? Does it depend on the number of nodes? Is it logarithmic
> or linear in number of nodes?
Section 11 calculates the worst case under attack. Typically, 5 or
10 blocks is enough for that. If you're selling something that
doesn't merit a network-scale attack to steal it, in practice you
could cut it closer.
> But in the absence of identity, there's no downside to them
> if spends become invalid, if they've already received the
> goods they double-spent for (access to website, download,
> whatever). The merchants are left holding the bag with
> "invalid" coins, unless they wait that magical "few blocks"
> (and how can they know how many?) before treating the spender
> as having paid.
>
> The consumers won't do this if they spend their coin and it takes
> an hour to clear before they can do what they spent their coin on.
> The merchants won't do it if there's no way to charge back a
> customer when they find the that their coin is invalid because
> the customer has doublespent.
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.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (James A. Donald) — November 16, 2008 — source: sni-emails.json#email-28
Satoshi Nakamoto wrote:
> Fortunately, it's only necessary to keep a
> pending-transaction pool for the current best branch.
This requires that we know, that is to say an honest
well behaved peer whose communications and data storage
is working well knows, what the current best branch is -
but of course, the problem is that we are trying to
discover, trying to converge upon, a best branch, which
is not easy at the best of times, and becomes harder
when another peer is lying about its connectivity and
capabilities, and yet another peer has just had a major
disk drive failure obfuscated by a software crash, and
the international fibers connecting yet a third peer
have been attacked by terrorists.
> When a new block arrives for the best branch,
> ConnectBlock removes the block's transactions from
> the pending-tx pool. If a different branch becomes
> longer
Which presupposes the branches exist, that they are
fully specified and complete. If they exist as complete
works, rather than works in progress, then the problem
is already solved, for the problem is making progress.
> Broadcasts will probably be almost completely
> reliable.
There is a trade off between timeliness and reliability.
One can make a broadcast arbitrarily reliable if time is
of no consequence. However, when one is talking of
distributed data, time is always of consequence, because
it is all about synchronization (that peers need to have
corresponding views at corresponding times) so when one
does distributed data processing, broadcasts are always
highly unreliable Attempts to ensure that each
message arrives at least once result in increased timing
variation. Thus one has to make a protocol that is
either UDP or somewhat UDP like, in that messages are
small, failure of messages to arrive is common, messages
can arrive in different order to the order in which they
were sent, and the same message may arrive multiple
times. Either we have UDP, or we need to accommodate
the same problems as UDP has on top of TCP connections.
Rather than assuming that each message arrives at least
once, we have to make a mechanism such that the
information arrives even though conveyed by messages
that frequently fail to arrive.
> TCP transmissions are rarely ever dropped these days
People always load connections near maximum. When a
connection is near maximum, TCP connections suffer
frequent unreasonably long delays, and connections
simply fail a lot - your favorite web cartoon somehow
shows it is loading forever, and you try again, or it
comes up with a little x in place of a picture, and you
try again
Further very long connections - for example ftp
downloads of huge files, seldom complete. If you try to
ftp a movie, you are unlikely to get anywhere unless
both client and server have a resume mechanism so that
they can talk about partially downloaded files.
UDP connections, for example Skype video calls, also
suffer frequent picture freezes, loss of quality, and so
forth, and have to have mechanisms to keep going
regardless.
> It's very attractive to the libertarian viewpoint if
> we can explain it properly. I'm better with code than
> with words though.
No, it is very attractive to the libertarian if we can
design a mechanism that will scale to the point of
providing the benefits of rapidly irreversible payment,
immune to political interference, over the internet,
to very large numbers of people. You have an outline
and proposal for such a design, which is a big step
forward, but the devil is in the little details.
I really should provide a fleshed out version of your
proposal, rather than nagging you to fill out the blind
spots.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Satoshi Nakamoto) — November 17, 2008 — source: sni-emails.json#email-29
James A. Donald wrote:
> > Fortunately, it's only necessary to keep a
> > pending-transaction pool for the current best branch.
>
> This requires that we know, that is to say an honest
> well behaved peer whose communications and data storage
> is working well knows, what the current best branch is -
I mean a node only needs the pending-tx pool for the best branch it
has. The branch that it currently thinks is the best branch.
That's the branch it'll be trying to make a block out of, which is
all it needs the pool for.
> > Broadcasts will probably be almost completely
> > reliable.
>
> Rather than assuming that each message arrives at least
> once, we have to make a mechanism such that the
> information arrives even though conveyed by messages
> that frequently fail to arrive.
I think I've got the peer networking broadcast mechanism covered.
Each node sends its neighbours an inventory list of hashes of the
new blocks and transactions it has. The neighbours request the
items they don't have yet. If the item never comes through after a
timeout, they request it from another neighbour that had it. Since
all or most of the neighbours should eventually have each item,
even if the coms get fumbled up with one, they can get it from any
of the others, trying one at a time.
The inventory-request-data scheme introduces a little latency, but
it ultimately helps speed more by keeping extra data blocks off the
transmit queues and conserving bandwidth.
> You have an outline
> and proposal for such a design, which is a big step
> forward, but the devil is in the little details.
I believe I've worked through all those little details over the
last year and a half while coding it, and there were a lot of them.
The functional details are not covered in the paper, but the
sourcecode is coming soon. I sent you the main files.
(available by request at the moment, full release soon)
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (Nicolas Williams) — November 17, 2008 — source: sni-emails.json#email-30
On Fri, Nov 14, 2008 at 11:04:21PM -0800, Ray Dillinger wrote:
> On Sat, 2008-11-15 at 12:43 +0800, Satoshi Nakamoto wrote:
> > > If someone double spends, then the transaction record
> > > can be unblinded revealing the identity of the cheater.
> >
> > Identities are not used, and there's no reliance on recourse. It's all prevention.
>
> Okay, that's surprising. If you're not using buyer/seller
> identities, then you are not checking that a spend is being made
> by someone who actually is the owner of (on record as having
> recieved) the coin being spent.
How do identities help? It's supposed to be anonymous cash, right? And
say you identify a double spender after the fact, then what? Perhaps
you're looking at a disposable ID. Or perhaps you can't chase them
down.
Double spend detection needs to be real-time or near real-time.
Nico
--
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (James A. Donald) — November 17, 2008 — source: sni-emails.json#email-31
Ray Dillinger wrote:
> Okay.... I'm going to summarize this protocol as I
> understand it.
>
> I'm filling in some operational details that aren't in
> the paper by supplementing what you wrote with what my
> own "design sense" tells me are critical missing bits
> or "obvious" methodologies for use.
There are a number of significantly different ways this
could be implemented. I have been working on my own
version based on Patricia hash trees, (not yet ready to
post, will post in a week or so) with the consensus
generation being a generalization of file sharing using
Merkle hash trees. Patricia hash trees where the high
order part of the Patricia key represents the high order
part of the time can be used to share data that evolves
in time. The algorithm, if implemented by honest
correctly functioning peers, regularly generates
consensus hashes of the recent past - thereby addressing
the problem I have been complaining about - that we have
a mechanism to protect against consensus distortion by
dishonest or malfunctioning peers, which is useless
absent a definition of consensus generation by honest
and correctly functioning peers.
> First, people spend computer power creating a pool of
> coins to use as money. Each coin is a proof-of-work
> meeting whatever criteria were in effect for money at
> the time it was created. The time of creation (and
> therefore the criteria) is checkable later because
> people can see the emergence of this particular coin
> in the transaction chain and track it through all its
> "consensus view" spends. (more later on coin creation
> tied to adding a link).
>
> When a coin is spent, the buyer and seller digitally
> sign a (blinded) transaction record, and broadcast it
> to a bunch of nodes whose purpose is keeping track of
> consensus regarding coin ownership.
I don't think your blinding works.
If there is a public record of who owns what coin, we
have to generate a public diff on changes in that
record, so the record will show that a coin belonged to
X, and soon thereafter belonged to Y. I don't think
blinding can be made to work. We can blind the
transaction details easily enough, by only making hashes
of the details public, (X paid Y for
49vR7xmwYcKXt9zwPJ943h9bHKC2pG68m) but that X paid Y is
going to be fairly obvious.
If when Joe spends a coin to me, then I have to have the
ability to ask "Does Joe rightfully own this coin", then
it is difficult to see how this can be implemented in a
distributed protocol without giving people the ability
to trawl through data detecting that Joe paid me.
To maintain a consensus on who owns what coins, who owns
what coins has to be public.
We can build a privacy layer on top of this - account
money and chaumian money based on bitgold coins, much as
the pre 1915 US banking system layered account money and
bank notes on top of gold coins, and indeed we have to
build a layer on top to bring the transaction cost down
to the level that supports agents performing micro
transactions, as needed for bandwidth control, file
sharing, and charging non white listed people to send us
communications.
So the entities on the public record are entities
functioning like pre 1915 banks - let us call them
binks, for post 1934 banks no longer function like that.
> But if they recieve a _longer_ chain while working,
> they immediately check all the transactions in the new
> links to make sure it contains no double spends and
> that the "work factors" of all new links are
> appropriate.
I am troubled that this involves frequent
retransmissions of data that is already mostly known.
Consensus and widely distributed beliefs about bitgold
ownership already involves significant cost. Further,
each transmission of data is subject to data loss, which
can result in thrashing, with the risk that the
generation of consensus may slow below the rate of new
transactions. We already have problems getting the cost
down to levels that support micro transactions by
software agents, which is the big unserved market -
bandwidth control, file sharing, and charging non white
listed people to send us communications.
To work as useful project, has to be as efficient as it
can be - hence my plan to use a Patricia hash tree
because it identifies and locate small discrepancies
between peers that are mostly in agreement already,
without them needing to transmit their complete data.
We also want to avoid very long hash chains that have to
be frequently checked in order to validate things. Any
time a hash chain can potentially become enormously long
over time, we need to ensure that no one ever has to
rewalk the full length. Chains that need to be
re-walked can only be permitted to grow as the log of
the total number of transactions - if they grow as the
log of the transactions in any one time period plus the
total number of time periods, we have a problem.
> Biggest Technical Problem:
>
> Is there a mechanism to make sure that the "chain"
> does not consist solely of links added by just the 3
> or 4 fastest nodes? 'Cause a broadcast transaction
> record could easily miss those 3 or 4 nodes and if it
> does, and those nodes continue to dominate the chain,
> the transaction might never get added.
>
> To remedy this, you need to either ensure provable
> propagation of transactions, or vary the work factor
> for a node depending on how many links have been added
> since that node's most recent link.
>
> Unfortunately, both measures can be defeated by sock
> puppets. This is probably the worst problem with your
> protocol as it stands right now; you need some central
> point to control the identities (keys) of the nodes
> and prevent people from making new sock puppets.
We need a protocol wherein to be a money tracking peer
(an entity that validates spends) you have to be
accepted by at least two existing peers who agree to
synchronize data with you - presumably through human
intervention by the owners of existing peers, and these
two human approved synchronization paths indirectly
connect you to the other peers in the network through
at least one graph cycle.
If peer X is only connected to the rest of the network
by one existing peer, peer Y, perhaps because X's
directly connecting peer has dropped out, then X is
demoted to a client, not a peer - any transactions X
submits are relabeled by Y as submitted to Y, not X, and
the time of submission (which forms part of the Patricia
key) is the time X submitted them to Y, not the time
they were submitted to X.
The algorithm must be able swiftly detect malfunctioning
peers, and automatically exclude them from the consensus
temporarily - which means that transactions submitted
through malfunctioning peers do not get included in the
consensus, therefore have to be resubmitted, and peers
may find themselves temporarily demoted to clients,
because one of the peers through which they were
formerly connected to the network has been dropped by
the consensus.
If a peer gets a lot of automatic temporary exclusions,
there may be human intervention by the owners of those
peers to which it exchanges data directly to permanently
drop them.
Since peers get accepted by human invite, they have
reputation to lose, therefore we can make the null
hypothesis (the primary Bayesian prior) honest intent,
valid data, but unreliable data transmission - trust
with infrequent random verification. Designing the
system on this basis considerably reduces processing
costs.
Recall that SET died on its ass in large part because
every transaction involved innumerable public key
operations. Similarly, we have huge security flaws in
https because it has so many redundant public key
operations that web site designers try to minimize the
use of https to cover only those areas that truly need
it - and they always get the decision as to what truly
needs it subtly wrong.
Efficiency is critical, particularly as the part of the
market not yet served is the market for very low cost
transactions.
> If we solve the sock-puppet issue, or accept that
> there's a central point controlling the generation of
> new keys,
A central point will invite attack, will be attacked.
The problem with computer networked money is that the
past can so easily be revised, so nodes come under
pressure to adjust the past - "I did not pay that"
swiftly becomes "I should not have paid that", which
requires arbitration, which is costly, and introduces
uncertainty, which is costly, and invites government
regulation, which is apt to be utterly ruinous and
wholly devastating.
For many purposes, reversal and arbitration is highly
desirable, but there is no way anyone can compete with
the arbitration provided by Visa and Mastercard, for
they have network effects on their side, and they do a
really good job of arbitration, at which they have vast
experience, accumulated skills, wisdom, and good repute.
So any new networked transaction system has to target
the demand for final and irreversible transactions.
The idea of a distributed network consensus is that one
has a lot of peers in a lot of jurisdictions, and once a
transaction has entered into the consensus, undoing it
is damn near impossible - one would have to pressure
most of the peers in most of the jurisdictions to agree,
and many of them don't even talk your language, and
those that do, will probably pretend that they do not.
So people will not even try.
To avoid pressure, the network has to avoid any central
point at which pressure can be applied. Recall Nero's
wish that Rome had a single throat that he could cut. If
we provide them with such a throat, it will be cut.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin P2P e-cash paper
Cryptography Mailing List (James A. Donald) — November 18, 2008 — source: sni-emails.json#email-32
Nicolas Williams wrote:
> How do identities help? It's supposed to be anonymous
> cash, right?
Actually no. It is however supposed to be pseudonymous,
so dinging someone's reputation still does not help
much.
> And say you identify a double spender after the fact,
> then what? Perhaps you're looking at a disposable ID.
> Or perhaps you can't chase them down.
>
> Double spend detection needs to be real-time or near
> real-time.
Near real time means we have to use UDP or equivalent,
rather than TCP or equivalent, and we have to establish
an approximate consensus, not necessarily the final
consensus, not necessarily exact agreement, but close to
it, in a reasonably small number of round trips.
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Re: Bitcoin source files attached
Hal Finney correspondence — November 19, 2008 — source: 1.md
X-Bogosity: Ham, tests-bogofilter, spamicity=0.000000,
version=1.0.3
Status: RO
Ah, I see, thanks for the corrections.
Some of the discussion and concern over performance may relate to the
eventual size of the P2P node network. How large do you envision it
becoming? Tens of nodes? Thousands? Millions?
And for clients, do you think this could scale to be usable for close
to 100% of world financial transactions? Or would you see it as mostly
being used for some “core” subset of transactions that have special
requirements, with other transactions using a different payment system
that perhaps is based on Bitcoin?
Hal
Source file: QEI3NJOWY5FXJOOR7CEMNT7O3U.avif
[bitcoin-list] Welcome
bitcoin-list Mailing List (Satoshi Nakamoto) — December 10, 2008 — source: sni-emails.json#email-41
Announcing the first release of Bitcoin, a new electronic cash
system that uses a peer-to-peer network to prevent double-spending.
It's completely decentralized with no server or central authority.
See bitcoin.org for screenshots.
Download link:
http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar
Windows only for now. Open source C++ code is included.
- Unpack the files into a directory
- Run BITCOIN.EXE
- It automatically connects to other nodes
If you can keep a node running that accepts incoming connections,
you'll really be helping the network a lot. Port 8333 on your
firewall needs to be open to receive incoming connections.
The software is still alpha and experimental. There's no guarantee
the system's state won't have to be restarted at some point if it
becomes necessary, although I've done everything I can to build in
extensibility and versioning.
You can get coins by getting someone to send you some, or turn on
Options->Generate Coins to run a node and generate blocks. I made
the proof-of-work difficulty ridiculously easy to start with, so
for a little while in the beginning a typical PC will be able to
generate coins in just a few hours. It'll get a lot harder when
competition makes the automatic adjustment drive up the difficulty.
Generated coins must wait 120 blocks to mature before they can be
spent.
There are two ways to send money. If the recipient is online, you
can enter their IP address and it will connect, get a new public
key and send the transaction with comments. If the recipient is
not online, it is possible to send to their Bitcoin address, which
is a hash of their public key that they give you. They'll receive
the transaction the next time they connect and get the block it's
in. This method has the disadvantage that no comment information
is sent, and a bit of privacy may be lost if the address is used
multiple times, but it is a useful alternative if both users can't
be online at the same time or the recipient can't receive incoming
connections.
Total circulation will be 21,000,000 coins. It'll be distributed
to network nodes when they make blocks, with the amount cut in half
every 4 years.
first 4 years: 10,500,000 coins
next 4 years: 5,250,000 coins
next 4 years: 2,625,000 coins
next 4 years: 1,312,500 coins
etc...
When that runs out, the system can support transaction fees if
needed. It's based on open market competition, and there will
probably always be nodes willing to process transactions for free.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Re: Bitcoin v0.1
Hal Finney correspondence — January 09, 2009 — source: 4.md
Hi, Satoshi, thanks very much for that information! I should have a
chance to look at that this weekend. I am looking forward to learning
more about the code -
Hal
Source file: 66FEUFUEIVC3LOIOA6ESVKGGKM.avif
Bitcoin v0.1
Hal Finney correspondence — January 09, 2009 — source: 3.md
Yes, actually the version with MSVC symbols would be better, that is
the one I am using.
I found that if I launched this one from a cygwin shell, it does not
crash. But if I launch it from Windows, double-clicking on the file, it
does crash similarly to the previous version. However, I am pretty sure
that the previous version did crash even when I launched it from
cygwin.
I have to go out but I’ll leave this version running for a while.
Hal
Source file: finneynakamotoemails.pdf
Re: Crash in bitcoin 0.1.0
Hal Finney correspondence — January 10, 2009 — source: 11.md
Hi Satoshi - The version with the .pdb file did not run for me, I got
an error about MSVCP60D.DLL not being found. I imagine this is due to
the version incompatibility you were worried about.
The next version, that deleted the questionable line of code and
turned off optimization, seems to run fine for me. So the problem may be
related to that bit.
Hal
Source file: finneynakamotoemails.pdf
Re: Bitcoin v0.1
Hal Finney correspondence — January 10, 2009 — source: 5.md
X-Bogosity: Ham, tests-bogofilter, spamicity-0.000000, version
1.0.3
Status: O
Sure thing. If you have any questions, feel free.
Hi, Satoshi, thanks very much for that information! I should have a
chance to look at that this weekend. I am looking forward to learning
more about the code -
Hal
Source file: 66FEUFUEIVC3LOIOA6ESVKGGKM.avif
Re: Citation of your b-money page
Wei Dai correspondence — January 10, 2009 — source: 3.md
I wanted to let you know, I just released the full implementation of
the paper I sent you a few months ago, Bitcoin v0.1. Details, download
and screenshots are at www.bitcoin.org
I think it achieves nearly all the goals you set out to solve in your
b-money paper.
The system is entirely decentralized, without any server or trusted
parties. The network infrastructure can support a full range of escrow
transactions and contracts, but for now the focus is on the basics of
money and transactions.
There was a discussion of the design on the Cryptography mailing
list. Hal Finney gave a good high-level overview:
One thing I might mention is that in many ways bitcoin is two
independent ideas: a way of solving the kinds of problems James lists
here, of creating a globally consistent but decentralized database; and
then using it for a system similar to Wei Dai’s b-money (which is
referenced in the paper) but transaction/coin based rather than account
based. Solving the global, massively decentralized database problem is
arguably the harder part, as James emphasizes. The use of proof-of-work
as a tool for this purpose is a novel idea well worth further review
IMO.
Normally I would keep the symbols in, but they increased the size of
the EXE from 6.5MB to 50MB so I just couldn’t justify not stripping
them. I guess I made the wrong decision, at least for this early
version. I’m kind of surprised there was a crash, I’ve tested heavily
and haven’t had an outright exception for a while. Come to think of it,
there isn’t even an exception print at the end of debug.log. I’ve been
testing on XP SP2, maybe SP3 is something.
I’ve attached bitcoin.exe with symbols. (gcc symbols for gdb, if
you’re using MSVC I can send you an MSVC build with symbols)
Thanks for your help!
Hi Satoshi - I tried running bitcoin.exe from the 0.1.0 package, and
it crashed. I am running on an up to date version of XP, SP3. The
debug.log output is attached. There was also a file db.log but it was
empty.
The crash allowed me to start up a debugger, but there were no
symbols. The exception was at address 00930AF7. The displayed call stack
was 942316 called by 508936.
When I have a chance, I’ll try building it, although it looks like it
would take me a while to acquire all the dependencies.
Hal
Source file: finneynakamotoemails.pdf
Re: Crash in bitcoin 0.1.0
Hal Finney correspondence — January 10, 2009 — source: 9.md
I was temporarily able to reproduce the bug and narrowed it down to
the “mapAddresses.count” in the following code. It was absolutely the
last piece of code to go in and mainly only got tested with the MSVC
build. It’s not essential and I’m inclined to turn off optimization and
delete the section of code until I figure out what’s going on.
I’m attaching a dbg exe you can try that deletes the line of code and
turns off optimization. I’m not able to reproduce it anymore at the
moment.
irc.cpp:
if (pszName[0] == ‘u’)
{
CAddress addr;
if (DecodeAddress(pszName, addr))
{
CAddrDB addrdb;
if (AddAddress(addrdb, addr))
printf("new ");
else
{
// make it try connecting sooner
CRITICAL_BLOCK(cs_mapAddresses)
if (mapAddresses.count(addr.GetKey()))
mapAddresses[addr.GetKey()\].nLastFailed = 0;
}
addr.print();
}
else
{
printf("decode failed\n");
}
}
Yes, actually the version with MSVC symbols would be better, that is
the one I am using.
I found that if I launched this one from a cygwin shell, it does not
crash. But if I launch it from Windows, double-clicking on the file, it
does crash similarly to the previous version. However, I am pretty sure
that the previous version did crash even when I launched it from
cygwin.
I have to go out but I’ll leave this version running for a while.
Hal
Source file: finneynakamotoemails.pdf
Re: Citation of your Hashcash paper
Adam Back correspondence (Satoshi Nakamoto) — January 10, 2009 — source: adam-back-emails.txt#email-1
From: Satoshi Nakamoto Sent: Sat
1/10/2009 6:46:45 PM (UTC) To: adam@cypherspace.orgSubject: Re:
Citation of your Hashcash paper
Thanks for the pointers you gave me to Wei Dai's b-money paper and others.
I just released the open source implementation of my paper, Bitcoin v0.1.
Details, download and screenshots are at www.bitcoin.org
The main idea of the system is the generation of a chain of hash based
proof-of-work to create self evident proof of the majority consensus.
Users get new coins by contributing proof-of-work to the chain.
There was a discussion of the design on the Cryptography mailing list.
Hal Finney gave a good high-level overview:
| One thing I might mention is that in many ways bitcoin is two independent
| ideas: a way of solving the kinds of problems James lists here, of
| creating a globally consistent but decentralized database; and then using
| it for a system similar to Wei Dai's b-money (which is referenced in the
| paper) but transaction/coin based rather than account based. Solving the
| global, massively decentralized database problem is arguably the harder
| part, as James emphasizes. The use of proof-of-work as a tool for this
| purpose is a novel idea well worth further review IMO.
Satoshi
>Yes citation looks fine, I'll take a look at your paper. You maybe
>aware of the "B-money" proposal, I guess google can find it for you,
>by Wei Dai which sounds to be somewhat related to your paper. (The
>b-money idea is just described concisely on his web page, he didnt
>write up a paper).
>
>Adam
>
>On Wed, Aug 20, 2008 at 6:30 PM, satoshi@anonymousspeech.com
><satoshi@anonymousspeech.com> wrote:
>> I'm getting ready to release a paper that references your Hashcash paper and I wanted to make sure I
have the citation right. Here's what I have:
>>
>> [5] A. Back, "Hashcash - a denial of service counter-measure,"
http://www.hashcash.org/papers/hashcash.pdf, 2002.
>>
>> I think you would find it interesting, since it finds a new use for hash-based proof-of-work as a way to
make e-cash work. You can download a pre-release draft at http://www.upload.ae/file/6157/ecash-
pdf.html Feel free to forward it to anyone else you think would be interested. I'm also nearly finished
with a C++ implementation to release as open source.
>>
>> Title: Electronic Cash Without a Trusted Third Party
>>
>> Abstract: A purely peer-to-peer version of electronic cash would allow online payments to be sent
directly from one party to another without the burdens of going through a financial institution. Digital
signatures offer part of the solution, but the main benefits are lost if a trusted party is still required to
prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer
network. The network timestamps transactions by hashing them into an ongoing chain of hash-based
proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest
chain not only serves as proof of the sequence of events witnessed, but proof that it came from the
largest pool of CPU power. As long as honest nodes control the most CPU power on the network, they
can generate the longest chain and outpace any attackers. The network itself requires minimal structure.
Messages are broadcasted on a best effort basis, and nodes can leave and rejoin the network at will,
accepting the longest proof-of-work chain as proof of what happened while they were gone.
>>
>> satoshi@anonymousspeech.com
>>
>>
>>
>
Re: Crash in bitcoin 0.1.0
Hal Finney correspondence — January 10, 2009 — source: 10.md
I isolated the problem. If I spawn a thread and do
mapAddresses.count, even as the very first thing in the program, it
segfaults. The workaround is to needlessly call mapAddresses.count in
the main thread once and it’s fine from then on. I hate to blame the
compiler, and I’ve never had a GCC compiler bug before, but this feels
like one. Maybe some bit of init code it tries to optimize out if it’s
not called at least once in the same thread, or some STL optimization
that’s not thread friendly. I’m really dismayed to have this botch up
the release after all that stress testing.
The attached file: bitcoin-0.1.1.rar (filesize 2,132,686) is the
version where I deleted the mapAddresses.count line, and that should be
the safest version. (that was the only use of mapAddresses.count) If you
could try this version and confirm that the crash is fixed, I’d
appreciate it.
Thanks,
Satoshi
Source file: finneynakamotoemails.pdf
Re: Crash in bitcoin 0.1.0
Hal Finney correspondence — January 10, 2009 — source: 12.md
OK, thanks. The one in bitcoin-0.1.1-exe-dbg.rar is the same build as
in bitcoin-0.1.1.rar. I forgot, when you build debug on MSVC, it uses
the debug versions of the runtime DLLs, which aren’t included with
Windows distributions. Actually, MSVC 6.0’s runtime (MSVC60.DLL) is the
last version that shipped preinstalled on Windows, which is why the
continued interest in that ancient version of the compiler. Later Visual
C versions can’t create a standalone EXE that doesn’t require additional
runtime packages installed.
I can’t use MSVC 6.0 for the release because its optimization of the
SHA-256 routines is too slow.
I’ve attached a copy of the debug runtime DLLs. (They’re
redistributable)
Hi Satoshi - The version with the .pdb file did not run for me, I got
an error about MSVCP60D.DLL not being found. I imagine this is due to
the version incompatibility you were worried about.
The next version, that deleted the questionable line of code and
turned off optimization, seems to run fine for me. So the problem may be
related to that bit.
Hal
Source file: finneynakamotoemails.pdf
Crash in bitcoin 0.1.0
Hal Finney correspondence — January 10, 2009 — source: 6.md
Hi Satoshi - I tried running bitcoin.exe from the 0.1.0 package, and
it crashed. I am running on an up to date version of XP, SP3. The
debug.log output is attached. There was also a file db.log but it was
empty.
The crash allowed me to start up a debugger, but there were no
symbols. The exception was at address 00930AF7. The displayed call stack
was 942316 called by 508936.
When I have a chance, I’ll try building it, although it looks like it
would take me a while to acquire all the dependencies.
Satoshi Nakamoto writes:
> Announcing the first release of Bitcoin, a new electronic cash
> system that uses a peer-to-peer network to prevent double-spending.
> It's completely decentralized with no server or central authority.
>
> See bitcoin.org for screenshots.
>
> Download link:
> http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar
Congratulations to Satoshi on this first alpha release. I am looking
forward to trying it out.
> Total circulation will be 21,000,000 coins. It'll be distributed
> to network nodes when they make blocks, with the amount cut in half
> every 4 years.
>
> first 4 years: 10,500,000 coins
> next 4 years: 5,250,000 coins
> next 4 years: 2,625,000 coins
> next 4 years: 1,312,500 coins
> etc...
It's interesting that the system can be configured to only allow a
certain maximum number of coins ever to be generated. I guess the
idea is that the amount of work needed to generate a new coin will
become more difficult as time goes on.
One immediate problem with any new currency is how to value it. Even
ignoring the practical problem that virtually no one will accept it
at first, there is still a difficulty in coming up with a reasonable
argument in favor of a particular non-zero value for the coins.
As an amusing thought experiment, imagine that Bitcoin is successful and
becomes the dominant payment system in use throughout the world. Then the
total value of the currency should be equal to the total value of all
the wealth in the world. Current estimates of total worldwide household
wealth that I have found range from $100 trillion to $300 trillion. With
20 million coins, that gives each coin a value of about $10 million.
So the possibility of generating coins today with a few cents of compute
time may be quite a good bet, with a payoff of something like 100 million
to 1! Even if the odds of Bitcoin succeeding to this degree are slim,
are they really 100 million to one against? Something to think about...
Hal
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Re: How's v0.1.2 going?
Hal Finney correspondence — January 11, 2009 — source: 13.md
Well this doesn’t look good. After you upgraded to 0.1.2, your node
responded to one or two messages and then stopped replying to messages.
It’s still accepting connections and seems to be alive on IRC. That
could happen if ThreadSocketHandler or ThreadMessageHandler is hung or
crashed or blocked. Usually when there’s an exception or other problem,
it only stops the affected thread and everything else keeps running.
I’m attaching the msvc debug version in case you need it.
Satoshi
Source file: finneynakamotoemails.pdf
v0.1.2 gcc debug build attached
Hal Finney correspondence — January 11, 2009 — source: 14.md
gdb is easier to use than you’d think. gdb.exe is the only file. You
run
gdb bitcoin.exe
then type “run”
then if it crashes, type “backtrace” for a stack dump, or it may do
it automatically. (The stack trace doesn’t always go far enough back
unfortunately)
Source file: finneynakamotoemails.pdf
Re: v0.1.2 debug.log
Hal Finney correspondence — January 11, 2009 — source: 16.md
OK, so no crash or exception window or anything. debug.log is all I
need then.
It looks like there’s a “select failed: 10038” error (the sockets
select function failed) and then network communication goes quiet after
that (except for IRC which is still working). I’ve never had select fail
before. It looks like sockets is somehow partially hosed. At least now I
know what’s wrong now.
You should restart it. It’s not doing anything right now. I don’t
know if it’ll just get the “select failed” error again, or be fine for a
while.
If I can’t think of anything else, I can always shut down and restart
sockets if it gets hosed like that. I’m sure everyone who’s written an
internet app like a browser or p2p app had to slog through all the ways
the Internet can trash you. The Internet is a brutal, rough and tumble
place.
The issue of bitcoin.exe still running after you close it is a known
issue. It does a careful shutdown of everything to be extra safe, in
case some important transaction is in progress, but it’s completely fine
and totally safe to just kill it if it doesn’t exit on its own. I’ll
have to work on figuring out what’s getting hung up. I may just have it
kill itself after a timeout.
Thanks!
Hi Satoshi - debug.log attached. When I started 0.1.2 this afternoon,
I first quit the previous version which was running. However, 0.1.2
would not start up. Looking at the debug log, it said “Existing instance
found”. I ran task manager, and found two processes called bitcoin.exe
running. I killed them both and started up the new one, and it seemed to
run OK. It says at the bottom “3 connections”. I haven’t tried the debug
version, I’m not sure what I would look for.
Hal
Source file: finneynakamotoemails.pdf
select failed 10038 fix
Hal Finney correspondence — January 11, 2009 — source: 17.md
I believe I’ve fixed the bug related to “select failed: 10038” (error
WSAENOTSOCK). The select error is not a big deal, but it led the
communications thread to get blocked on a socket that should have been
in non-blocking mode but wasn’t. It never came up until now because as
long as select never failed, receive would never be called unless there
was data.
Without this fix, your node’s communication sometimes goes dead.
Connections are still made, but no data is passed. Any generated blocks
would probably not be accepted since you can’t broadcast them and other
nodes will leave your branch behind. That’s why Generate doesn’t run
when you’re not connected.
This could also have caused bitcoin.exe to fail to exit. There’s no
reason for shutdown to wait for the com thread, so I made it only wait
for the message processing thread. I’ll do a more thorough forced
shutdown later.
Looks like your node’s com thread just now got blocked on this bug
again. It went for a few hours this time before it did.
Version 0.1.3 exe attached.
Source file: finneynakamotoemails.pdf
[bitcoin-list] Bitcoin v0.1.2 now available
bitcoin-list Mailing List (Satoshi Nakamoto) — January 11, 2009 — source: sni-emails.json#email-43
Bitcoin v0.1.2 is now available for download.
See http://www.bitcoin.org for the download link.
All the problems I've been finding are in the code that
automatically finds and connects to other nodes, since I wasn't
able to test it in the wild until now. There are many more ways
for connections to get screwed up on the real Internet.
Bugs fixed:
- Fixed various problems that were making it hard for new nodes to
see other nodes to connect to.
- If you're behind a firewall, it could only receive one
connection, and the second connection would constantly disconnect
and reconnect.
These problems are kind of screwing up the network and will get
worse as more users arrive, so please make sure to upgrade.
Satoshi Nakamoto
On Fri, 2009-01-09 at 03:27 +0800, Satoshi Nakamoto wrote:
> Announcing the first release of Bitcoin, a new electronic cash
> system that uses a peer-to-peer network to prevent double-spending.
> It's completely decentralized with no server or central authority.
I'm currently reading through your paper. At the timestamp server
section you mention newspapers and usenet, so I thought you might be
interested in this if you have not seen it already:
http://www.publictimestamp.org/
By the way, I'm also currently running the alpha code on one of my
workstations. So far it has two "Generated" messages, however the
"Credit" field for those is 0.00 and the balance hasn't changed. Is
this due to the age/maturity requirement for a coin to be valid?
Cheers,
--
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
Re: v0.1.2 debug.log
Hal Finney correspondence — January 12, 2009 — source: 15.md
Hi Satoshi - debug.log attached. When I started 0.1.2 this afternoon,
I first quit the previous version which was running. However, 0.1.2
would not start up. Looking at the debug log, it said “Existing instance
found”. I ran task manager, and found two processes called bitcoin.exe
running. I killed them both and started up the new one, and it seemed to
run OK. It says at the bottom “3 connections”. I haven’t tried the debug
version, I’m not sure what I would look for.
Hal
Source file: finneynakamotoemails.pdf
Re: select failed 10038 fix
Hal Finney correspondence — January 12, 2009 — source: 18.md
Thanks, Satoshi, this new version seems to be running much better.
I’ve got 8 connections, and watching debug.log there seems to be quite a
bit of activity. I see you sent me a payment, thanks! Let me know your
address and I will try sending one to you. I managed to generate a block
yesterday and the coins are about to mature, if I understand it
correctly.
Hal
Source file: finneynakamotoemails.pdf
Re: select failed 10038 fix
Hal Finney correspondence — January 12, 2009 — source: 20.md
Looks like 0.1.3 crashed during the night, unfortunately. Next time I
will try running the debug version. Today I am working and will need to
take this computer up and down quite a bit, so I won’t be able to run it
for most of the day. Tonight I will try to look at it a little bit.
Hal
Source file: finneynakamotoemails.pdf
Re: select failed 10038 fix
Hal Finney correspondence — January 12, 2009 — source: 19.md
It definitely looks like 0.1.3 solved it. It was getting so there
were so many zombie nodes, I was having a hard time getting a reply to
any of my messages. Now, four inventory messages go out, four getdata
messages come back.
Did you get any “not accepted” blocks? The connectivity bug could
have caused a generated block not to be accepted if the node wasn’t able
to broadcast at the time. Once the status is above 5 or so it’s safely
accepted.
Unfortunately, I can’t receive incoming connections from where I am,
which has made things more difficult. Your node receiving incoming
connections was the main thing keeping the network going the first day
or two.
You can send to my Bitcoin address if you want to, but you won’t get
to see the full transfer sequence:
1NSwywA5Dvuyw89sfs3oLPvLiDNGf48cPD
You could always findstr /c:“version message” debug.log and send a
test to some random person you’re connected to near the end of the list.
The ones ending in port 8333 can receive connections.
I just thought of something. Eventually there’ll be some interest in
brute force scanning bitcoin addresses to find one with the first few
characters customized to your name, kind of like getting a phone number
that spells out something. Just by chance I have my initials.
Satoshi
Thanks, Satoshi, this new version seems to be running much better.
I’ve got 8 connections, and watching debug.log there seems to be quite a
bit of activity. I see you sent me a payment, thanks! Let me know your
address and I will try sending one to you. I managed to generate a block
yesterday and the coins are about to mature, if I understand it
correctly.
Hal
Source file: finneynakamotoemails.pdf
Re: select failed 10038 fix
Hal Finney correspondence — January 12, 2009 — source: 21.md
Could you send me the debug.log from the 0.1.3 crash?
I can usually get a lot just from that.
I’ll send you the debug builds shortly.
Looks like 0.1.3 crashed during the night, unfortunately. Next time I
will try running the debug version. Today I am working and will need to
take this computer up and down quite a bit, so I won’t be able to run it
for most of the day. Tonight I will try to look at it a little bit.
Hal
Source file: finneynakamotoemails.pdf
Re: v0.1.3 msvc debug build
Hal Finney correspondence — January 12, 2009 — source: 22.md
Looks like 0.1.3 crashed during the night, unfortunately. Next time I
will try running the debug version. Today I am working and will need to
take this computer up and down quite a bit, so I won’t be able to run it
for most of the day. Tonight I will try to look at it a little bit.
Hal
Source file: finneynakamotoemails.pdf
Re: v0.1.3 gcc debug build
Hal Finney correspondence — January 12, 2009 — source: 23.md
Looks like 0.1.3 crashed during the night, unfortunately. Next time I
will try running the debug version. Today I am working and will need to
take this computer up and down quite a bit, so I won’t be able to run it
for most of the day. Tonight I will try to look at it a little bit.
Hal
Source file: finneynakamotoemails.pdf
[bitcoin-list] Bitcoin v0.1 Alpha release notes
bitcoin-list Mailing List (Satoshi Nakamoto) — January 12, 2009 — source: sni-emails.json#email-44
Release notes for Bitcoin v0.1 Alpha
Bitcoin is a new electronic cash system that uses a peer-to-peer
network to prevent double-spending. It's completely decentralized
with no server or central authority.
You can find screenshots and the download link at:
http://www.bitcoin.org
Windows only for now. Open source C++ code is included.
- Unpack the files into a directory
- Run BITCOIN.EXE
- It automatically connects to other nodes
If you can keep a node running that accepts incoming connections,
you'll really be helping the network a lot. Port 8333 on your
firewall needs to be open to receive incoming connections.
The software is still alpha and experimental. There's no guarantee
the system's state won't have to be restarted at some point if it
becomes necessary, although I've done everything I can to build in
extensibility and versioning.
You can get coins by getting someone to send you some, or turn on
Options->Generate Coins to run a node and generate blocks. I made
the proof-of-work difficulty ridiculously easy to start with, so
for a little while in the beginning a typical PC will be able to
generate coins in just a few hours. It'll get a lot harder when
competition makes the automatic adjustment drive up the difficulty.
Generated coins must wait 120 blocks to mature before they can be
spent.
There are two ways to send money. If the recipient is online, you
can enter their IP address and it will connect, get a new public
key and send the transaction with comments. If the recipient is
not online, it is possible to send to their Bitcoin address, which
is a hash of their public key that they give you. They'll receive
the transaction the next time they connect and get the block it's
in. This method has the disadvantage that no comment information
is sent, and a bit of privacy may be lost if the address is used
multiple times, but it is a useful alternative if both users can't
be online at the same time or the recipient can't receive incoming
connections.
Total circulation will be 21,000,000 coins. It'll be distributed
to network nodes when they make blocks, with the amount cut in half
every 4 years.
first 4 years: 10,500,000 coins
next 4 years: 5,250,000 coins
next 4 years: 2,625,000 coins
next 4 years: 1,312,500 coins
etc...
When that runs out, the system can support transaction fees if
needed. It's based on open market competition, and there will
probably always be nodes willing to process transactions for free.
Satoshi Nakamoto
On Tue, 2009-01-13 at 02:33 +0800, Satoshi Nakamoto wrote:
> Thanks, I hadn't seen that yet. It looks very well presented.
> There was an older one that's been running for a long time that
> publishes its hashes to Usenet. I'm surprised this one isn't
> using Usenet, although it is kind of difficult to get access to
> post to Usenet in an automated way these days. If they can get a
> magazine or newspaper to publish their hashes, it would work a lot
> easier in court for their purposes. Bitcoin and all timestamp
> servers share the basic functionality of periodically collecting
> things into blocks and hashing them into a chain.
It actually posts the hash blocks to a Google Group called
'proof-hashes', so similar result as if it were posting to Usenet.
http://groups.google.com/group/proof-hashes
Since I run that group, and it's sole purpose is to archive
proof-of-work hashes, feel free to join an account to have your system
post there as well if you like.
> Right, the credit field stays 0.00 until it matures, then it'll be
> 50.00. Do you think it would be clearer if I left the credit
> field blank until it matures? I should put some text in the
> transaction details (when you double click on it) explaining how
> it works. (was it obvious you can doubleclick on a line for
> details?)
No, I think having $0.00 there is more appropriate than being blank.
The entries in my BitCoin software (4 of them now) all say 'unconfirmed'
however, so I'm not sure what that means, but I did grok that the coins
were generated and just not 'mature' yet, but I had also read your
whitepaper so I may have understood that concept from there. When the
coins mature, will that generate a new 'credit' transaction, or will the
existing generation transaction line's credit field be updated?
No, I was unaware that you could double-click a transaction line for
further details... I just did that and it currently just has the same
information there that is in the transaction line. Putting more
information there would definitely be useful.
> Be sure to upgrade to v0.1.3 if you haven't already. This version
> has really stabilized things.
I was running 0.1.1... I will update now. Perhaps a new version
notification or auto-update feature is in order? (:
Electronic currency and cryptography are two things that I am very
interested in so as you would assume I was drawn to this project
immediately when I saw it posted to the Cryptography email list. Feel
free to ping me for feedback or to test out new features, I'll be happy
to help out.
Cheers,
--
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
On Tue, 2009-01-13 at 02:33 +0800, Satoshi Nakamoto wrote:
> Be sure to upgrade to v0.1.3 if you haven't already. This version
> has really stabilized things.
Two issues with upgrading:
When closing my previous version (help said 0.1.1 but I think it was
really 0.1.0), the process did not exit. The UI exited but the process
remained. I had to manually kill the process before I was able to start
version 0.1.3.
Upon opening version 0.1.3, all four of my transaction entries still say
'unconfirmed', but now the Descriptions say 'Generated (not accepted)'.
Does this mean that some other node had extended the chain first and my
coins were generated in a dead branch? If so, why did the previous
instance of the software not detect this immediately and begin
generating coins in the winning branch? Bug in 0.1.0?
I'll watch this instance and see how it goes...
Thanks,
--
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
One other question I had... What prevents the single node with the most
CPU power from generating and retaining the majority of the BitCoins?
If every node is working independently of all others, if one is
significantly more powerful than the others, isn't it probable that this
node will reach the proper conclusion before other nodes? An
underpowered node may get lucky once in a while, but if they are at a
significant horsepower advantage I would expect the majority of BitCoins
to be generated by the most powerful node.
--
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
[bitcoin-list] Bitcoin v0.1.3
bitcoin-list Mailing List (Satoshi Nakamoto) — January 12, 2009 — source: sni-emails.json#email-45
It looks like we're through with the worst of the Internet
connection issues. 0.1.3 fixed a problem where your node's
communications could go dead after a while. The network is
running much more smoothly now with this version.
If you've successfully generated a block, you've seen it has a
maturation countdown before you can spend it. Once it matures,
the Credit column will change from 0.00 to 50.00. For a block to
be valid, it has to be broadcasted to the network and get into the
block chain, which is why Generate does not run if you're not
connected. If you generated a block without being connected, the
network wouldn't know about it and would continue building the
chain without it, leaving it behind, and the maturation countdown
would change to "(not accepted)" when your node sees that it
wasn't used. If you subtract 1 from the status column, that's how
many blocks have been chained after yours.
Satoshi Nakamoto
Re: select failed 10038 fix
Hal Finney correspondence — January 12, 2009 — source: 25.md
Definitely the disk full. I completely put off disk full handling
until a later version. Probably about time I did it now.
Well, that’s a relief.
Satoshi
Hi Satoshi - Sorry I have not been able to do more today, this looks
like a busy week for me. I started 0.1.3 again under the MSVC debugger
this time so if it crashes tonight I may be able to get some more
information.
I remember now that last night, my disk filled up. I had downloaded a
bunch of the dependencies (boost, etc) with an eye towards trying to
build it myself, and my disk was already pretty full. I’m pretty sure
this is what caused 0.1.3 to crash. I’ve attached the debug.log, which
also includes some other runs. The error is about 1/3 of the way down
and says,
EXCEPTION: NSt8ios_base7failureE
CAutoFile::read : end of file
Normally this should be a rare occurrence with the large disk sizes
people have today.
Hal
Source file: finneynakamotoemails.pdf
Re: select failed 10038 fix
Hal Finney correspondence — January 13, 2009 — source: 24.md
Hi Satoshi - Sorry I have not been able to do more today, this looks
like a busy week for me. I started 0.1.3 again under the MSVC debugger
this time so if it crashes tonight I may be able to get some more
information.
I remember now that last night, my disk filled up. I had downloaded a
bunch of the dependencies (boost, etc) with an eye towards trying to
build it myself, and my disk was already pretty full. I’m pretty sure
this is what caused 0.1.3 to crash. I’ve attached the debug.log, which
also includes some other runs. The error is about 1/3 of the way down
and says,
EXCEPTION: NSt8ios_base7failureE
CAutoFile::read : end of file
Normally this should be a rare occurrence with the large disk sizes
people have today.
> I'm currently reading through your paper. At the timestamp server
> section you mention newspapers and usenet, so I thought you might be
> interested in this if you have not seen it already:
>
> http://www.publictimestamp.org/
Thanks, I hadn't seen that yet. It looks very well presented.
There was an older one that's been running for a long time that
publishes its hashes to Usenet. I'm surprised this one isn't
using Usenet, although it is kind of difficult to get access to
post to Usenet in an automated way these days. If they can get a
magazine or newspaper to publish their hashes, it would work a lot
easier in court for their purposes. Bitcoin and all timestamp
servers share the basic functionality of periodically collecting
things into blocks and hashing them into a chain.
> By the way, I'm also currently running the alpha code on one of my
> workstations. So far it has two "Generated" messages, however the
> "Credit" field for those is 0.00 and the balance hasn't changed. Is
> this due to the age/maturity requirement for a coin to be valid?
Right, the credit field stays 0.00 until it matures, then it'll be
50.00. Do you think it would be clearer if I left the credit
field blank until it matures? I should put some text in the
transaction details (when you double click on it) explaining how
it works. (was it obvious you can doubleclick on a line for
details?)
Be sure to upgrade to v0.1.3 if you haven't already. This version
has really stabilized things.
Satoshi
Re: disk full
Hal Finney correspondence — January 13, 2009 — source: 26.md
If you build the dependencies, let me know how that goes. Everything
is always harder to build on Windows than Linux. I’ve always hated
projects with a lot of big dependencies, but there’s no avoiding it,
each one is essential.
I still haven’t figured out how you managed to get a read exception
rather than a write exception when your disk filled up. It’s unlikely
but maybe possible that the incident could have messed up your block
data file. In that case, it might manifest as a similar exception again,
or if your block count in the status bar stopped going up, that would
also indicate a problem. As of this moment it’s at 375 blocks.
If there is a problem, it could easily be solved by deleting your
block files, as follows:
(exit Bitcoin and make sure it’s stopped)
cd /d “%appdata%”
(backup this directory first)
del blk0001.dat
del blkindex.dat
It’ll then re-download the block chain. Your transactions and
generated blocks show as 0/unconfirmed until it’s done downloading.
The crucial file to backup is wallet.dat. If bitcoin is running then
you have to backup the whole %appdata%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.
Satoshi
Hi Satoshi - Sorry I have not been able to do more today, this looks
like a busy week for me. I started 0.1.3 again under the MSVC debugger
this time so if it crashes tonight I may be able to get some more
information.
I remember now that last night, my disk filled up. I had downloaded a
bunch of the dependencies (boost, etc) with an eye towards trying to
build it myself, and my disk was already pretty full. I’m pretty sure
this is what caused 0.1.3 to crash. I’ve attached the debug.log, which
also includes some other runs. The error is about 1/3 of the way down
and says,
EXCEPTION: NSt8ios_base7failureE
CAutoFile::read : end of file
Normally this should be a rare occurrence with the large disk sizes
people have today.
> It actually posts the hash blocks to a Google Group called
> 'proof-hashes', so similar result as if it were posting to Usenet.
>
> http://groups.google.com/group/proof-hashes
>
> Since I run that group, and it's sole purpose is to archive
> proof-of-work hashes, feel free to join an account to have your system
> post there as well if you like.
Sweet, I was looking for a group like that on Usenet at one point to see
what I would use if I needed, and nothing really fit. I'm sure Google
groups is a lot easier to post to.
There are some scenarios where a Usenet or Google group could be used as
a supplemental defence. Bitcoin is at its most vulnerable in the
beginning when the total network CPU power is small. That's offset by
the fact that the incentive to attack it is also low when it's small.
Hopefully the easy solution of just growing up and getting past that
stage will work. If not, there are ways a Google group could help, if
it really came to that.
> Electronic currency and cryptography are two things that I am very
> interested in so as you would assume I was drawn to this project
> immediately when I saw it posted to the Cryptography email list. Feel
> free to ping me for feedback or to test out new features, I'll be happy
> to help out.
We definitely have similar interests!
You know, I think there were a lot more people interested in the 90's,
but after more than a decade of failed Trusted Third Party based systems
(Digicash, etc), they see it as a lost cause. I hope they can make the
distinction, that this is the first time I know of that we're trying a
non-trust based system.
> When the
> coins mature, will that generate a new 'credit' transaction, or will the
> existing generation transaction line's credit field be updated?
The existing transaction line will change.
> Upon opening version 0.1.3, all four of my transaction entries still say
> 'unconfirmed', but now the Descriptions say 'Generated (not accepted)'.
> Does this mean that some other node had extended the chain first and my
> coins were generated in a dead branch? If so, why did the previous
> instance of the software not detect this immediately and begin
> generating coins in the winning branch? Bug in 0.1.0?
You're right, sorry about that. It's the bug that was fixed in 0.1.3.
The communications thread would get blocked, so you would make
connections, but they would go silent after a while. When you found a
block, you couldn't broadcast it to the network, so it didn't get into
the chain. You weren't receiving anything either to know that the
network had gone on without you, until you restarted it.
The bug is also what caused bitcoin.exe to fail to exit. The
communications thread was blocked and failed to exit. Bitcoin does a
careful shutdown in case it might be in the middle of an important
transaction, but actually it's completely safe to kill it.
This is all fixed in 0.1.3. If you give me your IP, I'll send you some
coins.
> One other question I had... What prevents the single node with the most
> CPU power from generating and retaining the majority of the BitCoins?
> If every node is working independently of all others, if one is
> significantly more powerful than the others, isn't it probable that this
> node will reach the proper conclusion before other nodes? An
> underpowered node may get lucky once in a while, but if they are at a
> significant horsepower advantage I would expect the majority of BitCoins
> to be generated by the most powerful node.
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.
> I'll watch this instance and see how it goes...
Let me know how it goes. If you have any trouble with it, send me your
debug.log file. I can often figure out what went wrong just from that.
Satoshi
On Tue, 2009-01-13 at 15:39 +0800, Satoshi Nakamoto wrote:
> Sweet, I was looking for a group like that on Usenet at one point to see
> what I would use if I needed, and nothing really fit. I'm sure Google
> groups is a lot easier to post to.
Yea, that particular group is completely open, you don't have to join to
post (in fact I think I made it difficult for people to actually join),
you just email proof-hashes@googlegroups.com and the content of the
email gets posted to the group.
> There are some scenarios where a Usenet or Google group could be used as
> a supplemental defence. Bitcoin is at its most vulnerable in the
> beginning when the total network CPU power is small. That's offset by
> the fact that the incentive to attack it is also low when it's small.
> Hopefully the easy solution of just growing up and getting past that
> stage will work. If not, there are ways a Google group could help, if
> it really came to that.
Yea, I was thinking you could have a client post the current block chain
every 10k blocks or something, just to occasionally document the current
winning proof-of-work chain.
> We definitely have similar interests!
Indeed.
> You know, I think there were a lot more people interested in the 90's,
> but after more than a decade of failed Trusted Third Party based systems
> (Digicash, etc), they see it as a lost cause. I hope they can make the
> distinction, that this is the first time I know of that we're trying a
> non-trust based system.
Yea, that was the primary feature that caught my eye. The real trick
will be to get people to actually value the BitCoins so that they become
currency. Currently, they're just collections of bits...
> This is all fixed in 0.1.3. If you give me your IP, I'll send you some
> coins.
I'm currently at 24.28.79.95, but that's dynamic so it may change. I've
had that address for a while though so hopefully my dhcp client is being
successful at renewing and not losing my address. It does change from
time to time, but that address should be good for a while.
> 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.
Ahh I see... So each guess is like the spin of a roulette wheel,
completely independent from all other guesses and the extra CPU power
just translates to more successful guesses than anyone else.
Unfortunately my ability to understand complex mathematics is conversely
proportional to how interested I am in cryptography (:
> Let me know how it goes. If you have any trouble with it, send me your
> debug.log file. I can often figure out what went wrong just from that.
Will do...
--
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
I'm glad to see you considered the possibility of a BitCoin client
making a payment to itself and have an appropriate description in the
transaction log (:
I did this primarily so that I could get a packet capture of the network
traffic during a transaction to analyze. Without knowing your packet
structure, I only see a bit of cleartext information in the packets,
mostly just what is shown in the transaction detail such as name and
comments. There are a couple of other strings that show upon the wire
such as 'version' and 'reply', but the rest is pretty cryptic.
While pondering transactions, I realized that there is no identifiable
information involved other than an IP address or a BitCoin address. In
the case of the IP transaction, the BitCoin client seems to trust that
the IP that it has connected to really is the intended recipient of the
transaction. It is fairly trivial to launch a man-in-the-middle attack
and steal incoming transactions. Consider the scenario where a
co-worker and myself have our workstations on the same LAN. Being
nefarious, I could be ARP poisoning the local broadcast domain and
routing all traffic destined for his workstation through my workstation
as an intermediary. Both of us, not being good employees, play the
MMORPG-du-jour and like to buy and sell game items using BitCoins. I
could easily watch for incoming connections on TCP port 8333 and
terminate them at my workstation rather than passing those particular
connections on to his workstation. A bit convoluted, yes, but it
illustrates the point. This type of attack could be performed at any
hop along the route between the two transacting parties. If I were an
evil admin at Big ISP USA, well, you get the idea.
I would recommend not allowing the use of network addresses as the
address of an intended recipient. I would think it would be a bit more
secure to always require a BitCoin address and do transactions that way.
If I understand how that is done correctly, you just compute the
transaction into the block chain and let the intended recipient
'discover' it, correct? An alternative could be to allow the network
nodes to provide a resolution service, where they ask around for the
network address of a BitCoin address, and if that node is online, once a
consensus is agreed upon by the network for that address the sending
BitCoin application connects directly there. Because the BitCoin
addresses are tied to the keys of the node, I would think that some
method could be devised to prove ownership of that BitCoin address by
the sending node and not to proceed with the transaction if so. At the
very least I would recommend, if you intend to retain the recipient
addressing by IP method is to allow for matching a hash of a shared
secret between the parties or something that an intermediary would not
know, but since you have the crypto in place, keys generated, etc.
anyhow, using that would be a much stronger solution.
Or am I over-thinking this and the network connection is just to send
immediate notification of the transaction and context information such
as the comment? The BitCoin application mentioned getting the
recipient's public key and a few other things, and there seems to be a
lot more going on in the network traffic than what would be required for
a simple notification.
Talk to you soon,
--
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
On Fri, 2009-01-16 at 03:42 +0800, Satoshi Nakamoto wrote:
> Sending by IP requests a new public key, so yes, it's vulnerable
> to type 1 man-in-the-middle. If that's a concern, sending to a
> Bitcoin address doesn't have that vulnerability, although there's
> a small privacy tradeoff. I have a feeling most of the time
> people will get Bitcoin addresses off of non-SSL websites and
> unsigned cleartext e-mail, which is already vulnerable to type 1
> and type 2 through DNS poisoning.
True, but the upside to using the BitCoin address is that two people can
communicate via a number of different channels to verify the address.
If my friend gets my address off my website, and thinks something fishy
is going on, he can call me, or IM me, or email me, etc. to verify the
address. An attacker would then have to basically be replacing my
address with the malicious one in every possible communications channel,
including voice, which is a difficult feat. MITMing the direct
communication via network addresses doesn't have that benefit because
the attacker is spoofing the address or intercepting. My friend can
verify what my address is with me in the same ways, however verifying
the address doesn't actually improve the situation.
> One solution would be to use both the IP and Bitcoin addresses
> when sending (maybe 1.2.3.4-1Kn8iojk...), where the recipient uses
> the public key of the Bitcoin address to sign the new public key
> to prove that you're sending to who you think you are. If the
> system starts to be used for real business purposes, I will
> certainly implement that. Another solution is to use SSL.
That is a good solution. If you transact regularly you probably already
have the other person's BitCoin address in your address book.
> Another feature for later is an option to encrypt your wallet.
One thing that came to mind on this topic is the potential for BitCoin
loss if you have a system failure. The application doesn't seem to
store any data in the directory that it runs in, so I assume it's stored
in the registry and other places (haven't cracked out ProcessExplorer
yet to check myself), so it may be a good idea to have the application
be able to export everything that it needs for recovery to a file that
could be backed up off of the system.
> It would be nice to only need the Bitcoin address and have the IP
> worked out behind the scenes. Might have privacy or denial of
> service issues. Certainly before another sending method is
> implemented, there's plenty of time now to fully think through the
> design and make sure it's the best way.
You could always make that optional, such as a toggle that says
'Advertise my BitCoin address to the network' that the user could turn
on or off. If you're not found on the network when searched for by
BitCoin address, the transaction is inserted into the block-chain as
normal. If you are, the transaction meta-data could be communicated to
the network address.
One other thing I noticed today is that if you close the application it
doesn't appear to cleanly close it's network sockets (TCP RST's start
flying). Probably an item for the low-priority todo list (:
Talk to you later,
--
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
On Fri, 2009-01-16 at 03:10 +0800, Satoshi Nakamoto wrote:
> There's at least one node who's inbound IP keeps changing all the
> time within the same class B. Maybe every time the program is
> run. I wasn't expecting that.
Pretty sure that's not me. My BitCoin application at work should be
coming from our static NAT address and my connection at home has had the
IP that I gave you for at least 3 days now (that I've been transferring
coins between them for test purposes).
> Do you mind if I CC the rest of this to bitcoin-list or
> Cryptography?
Sure, no problem.
> BTW, bitcoin-list is:
> bitcoin-list@lists.sourceforge.net
> Subscribe/unsubscribe page:
> http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
> Archives:
> http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list
I'll join right now, thanks (:
> 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 TTP
> gets cold feet.
Yes, I saw that message and was one of the other reasons I started up a
node so quickly. My systems aren't doing much of anything else while
idle, so why not create BitCoins? And if they're worth something
someday...? Bonus!
> Even if it doesn't take off straight away, it's now available for
> use by the next guy who comes up with a plan that needs some kind
> of token or electronic currency. It could get started in a closed
> system or narrow niche like reward points, donation tokens,
> currency for a game or micropayments for adult sites. 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.
I can see how various types of sites that have a need for micropayments
could use them, however I also see an impedement to adoption if they
want to use an existing BitCoin peer group rather than a closed system
since they would first have to generate enough coins to support what
they intend to do (or buy them from someone else). A closed system
obviously doesn't have that problem.
> 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."
Interesting application (:
> 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.
Another good idea.
--
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
> I've had that address for a while though so hopefully my dhcp
> client is being successful at renewing and not losing my address.
> It does change from time to time, but that address should be good
> for a while.
There's at least one node who's inbound IP keeps changing all the
time within the same class B. Maybe every time the program is
run. I wasn't expecting that.
Do you mind if I CC the rest of this to bitcoin-list or
Cryptography?
BTW, bitcoin-list is:
bitcoin-list@lists.sourceforge.net
Subscribe/unsubscribe page:
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list
> Dustin D. Trammell wrote:
> > Satoshi Nakamoto wrote:
> > You know, I think there were a lot more people interested in the 90's,
> > but after more than a decade of failed Trusted Third Party based systems
> > (Digicash, etc), they see it as a lost cause. I hope they can make the
> > distinction that this is the first time I know of that we're trying a
> > non-trust-based system.
>
> Yea, that was the primary feature that caught my eye. The real trick
> will be to get people to actually value the BitCoins so that they become
> currency.
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 TTP
gets cold feet.
Even if it doesn't take off straight away, it's now available for
use by the next guy who comes up with a plan that needs some kind
of token or electronic currency. It could get started in a closed
system or narrow niche like reward points, donation tokens,
currency for a game or micropayments for adult sites. 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.
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.
Satoshi
I group attacks into two classes:
1) Attacks that can only be done by someone actually in the chain
of communication
2) Attacks that can be done by anyone on the Internet from anywhere
Type 1 exposes you to people in your house or company on your
local LAN, admins at ISPs in between, and the LAN on the
recipient's side. Type 2 exposes you to a billion people who can
self-select to be attackers and get economy of scale when they
develop one technique to attack multiple victims.
Sending by IP requests a new public key, so yes, it's vulnerable
to type 1 man-in-the-middle. If that's a concern, sending to a
Bitcoin address doesn't have that vulnerability, although there's
a small privacy tradeoff. I have a feeling most of the time
people will get Bitcoin addresses off of non-SSL websites and
unsigned cleartext e-mail, which is already vulnerable to type 1
and type 2 through DNS poisoning.
One solution would be to use both the IP and Bitcoin addresses
when sending (maybe 1.2.3.4-1Kn8iojk...), where the recipient uses
the public key of the Bitcoin address to sign the new public key
to prove that you're sending to who you think you are. If the
system starts to be used for real business purposes, I will
certainly implement that. Another solution is to use SSL.
For now, it's pretty obvious that if you send to an IP, you didn't
give any other identifying information about the recipient, so
you're blindly sending to whoever answers that IP.
Another feature for later is an option to encrypt your wallet.
> If I understand how that is done correctly, you just compute the
> transaction into the block chain and let the intended recipient
> 'discover' it, correct?
That's correct.
> An alternative could be to allow the network
> nodes to provide a resolution service, where they ask around for the
> network address of a BitCoin address, and if that node is online, once a
> consensus is agreed upon by the network for that address the sending
> BitCoin application connects directly there.
It would be nice to only need the Bitcoin address and have the IP
worked out behind the scenes. Might have privacy or denial of
service issues. Certainly before another sending method is
implemented, there's plenty of time now to fully think through the
design and make sure it's the best way.
Satoshi
Bitcoin v0.1 released
Cryptography Mailing List (Satoshi Nakamoto) — January 16, 2009 — source: sni-emails.json#email-35
> Dustin D. Trammell wrote:
> > Satoshi Nakamoto wrote:
> > You know, I think there were a lot more people interested in the 90's,
> > but after more than a decade of failed Trusted Third Party based systems
> > (Digicash, etc), they see it as a lost cause. I hope they can make the
> > distinction that this is the first time I know of that we're trying a
> > non-trust-based system.
>
> Yea, that was the primary feature that caught my eye. The real trick
> will be to get people to actually value the BitCoins so that they become
> currency.
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.
It could get started in a narrow niche like reward points,
donation tokens, currency for a game or micropayments for adult
sites. Initially it can be used in proof-of-work applications
for services that could almost be free but not quite.
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.
It might make sense just to get some in case it catches on. If
enough people think the same way, that becomes a self fulfilling
prophecy. 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.
Satoshi Nakamoto
http://www.bitcoin.org
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
> One thing that came to mind on this topic is the potential for BitCoin
> loss if you have a system failure. The application doesn't seem to
> store any data in the directory that it runs in, so I assume it's stored
> in the registry and other places (haven't cracked out ProcessExplorer
> yet to check myself), so it may be a good idea to have the application
> be able to export everything that it needs for recovery to a file that
> could be backed up off of the system.
The files are in "%appdata%\Bitcoin", that's the directory to
backup. The data is stored in a transactional database DBM, so
it should be safe from loss if there's a crash or power failure.
%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.
> One other thing I noticed today is that if you close the application it
> doesn't appear to cleanly close it's network sockets (TCP RST's start
> flying). Probably an item for the low-priority todo list (:
Just now added code to the next release for that.
Satoshi
Bitcoin v0.1 released
Cryptography Mailing List (Jonathan Thornburg) — January 17, 2009 — source: sni-emails.json#email-36
On Sat, 17 Jan 2009, Satoshi Nakamoto wrote:
[[various possible uses of Bitcoin et al]]
> 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.
In the modern world, no major government wants to allow untracable
international financial transactions above some fairly modest size
thresholds. (The usual catch-phrases are things like "laundering
drug money", "tax evasion", and/or "financing terrorist groups".)
To this end, electronic financial transactions are currently monitored
by various governments & their agencies, and any but the smallest of
transactions now come with various ID requirements for the humans
on each end.
But if each machine in a million-node botnet sends 10 cents to a
randomly chosen machine in another botnet on the other side of the
world, you've just moved $100K, in a way that seems very hard to
trace. To me, this means that no major government is likely to allow
Bitcoin in its present form to operate on a large scale.
I also worry about other "domestic" ways nasty people could exploit
a widespread Bitcoin deployment:
* Spammer botnets could burn through pay-per-send email filters
trivially (as usual, the costs would fall on people other than the
botnet herders & spammers).
* If each machine in a botnet sends 1 cent to a herder, that can add
up to a significant amount of money. In other words, Bitcoin would
make botnet herding and the assorted malware industry even more
profitable than it already is.
Is there something obvious I've missed? Is there a clever aspect of
the design which prevents botnets from exploiting the system? Is there
a way for every major government to monitor all Bitcoin transactions
to watch for botnet-to-botnet sending?
--
-- From: "Jonathan Thornburg [remove -animal to reply]" <jthorn at astro.indiana-zebra.edu>
Dept of Astronomy, Indiana University, Bloomington, Indiana, USA
"Washing one's hands of the conflict between the powerful and the
powerless means to side with the powerful, not to be neutral."
-- quote by Freire / poster by Oxfam
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Hey Satoshi,
After that first transfer of 25.00, you didn't send me another 100.00
did you? I sent myself 100.00 from my BitCoin application at work to my
one at home using the BitCoin address rather than by IP. My application
at home has a 100.00 transfer received, however it's transaction details
say "Received with: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv". That
is not my BitCoin address from work, so I assume this means that I
received the payment encoded with a block that was computed by your
client? If so, how did it know your name in addition to the BitCoin
address that generated it? I don't recall there being a place in my
application to even put my name.
--
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
On Mon, 2009-01-19 at 00:54 +0800, Satoshi Nakamoto wrote:
> It should be your Bitcoin address at home that you received it
> with. There's no way for it to know who it's from, so the best
> it can do is tell which of your addresses it was received on.
> You can create multiple addresses and give a different address
> to each person and label them to help figure out who's sending
> to you.
Ah! I didn't even notice it was my address at home, you're right (: I
do have multiple addresses created at home so I didn't make the
connection.
> It doesn't know any names other than what you tell it. The name
> printed there is what's associated in your address book for that
> address, either under the Address Book button or the "Change..."
> button to the right of your Bitcoin address.
Ahh you're right, 'Satoshi' is associated with the address that received
the payment under the Change button's addresses. I don't recall setting
that value though, is that the default or something? (this is the first,
default, address that the application generated itself when I first ran
it)
--
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
It should be your Bitcoin address at home that you received it
with. There's no way for it to know who it's from, so the best
it can do is tell which of your addresses it was received on.
You can create multiple addresses and give a different address
to each person and label them to help figure out who's sending
to you.
It doesn't know any names other than what you tell it. The name
printed there is what's associated in your address book for that
address, either under the Address Book button or the "Change..."
button to the right of your Bitcoin address.
>Hey Satoshi,
>
>After that first transfer of 25.00, you didn't send me another 100.00
>did you? I sent myself 100.00 from my BitCoin application at work to my
>one at home using the BitCoin address rather than by IP. My application
>at home has a 100.00 transfer received, however it's transaction details
>say "Received with: Satoshi 12higDjoCCNXSA95xZMWUdPvXNmkAduhWv". That
>is not my BitCoin address from work, so I assume this means that I
>received the payment encoded with a block that was computed by your
>client? If so, how did it know your name in addition to the BitCoin
>address that generated it? I don't recall there being a place in my
>application to even put my name.
>
>--
>Dustin D. Trammell
>dtrammell@dustintrammell.com
>http://www.dustintrammell.com
>
On Tue, 2009-01-20 at 00:44 +0800, Satoshi Nakamoto wrote:
> The first default one is labelled "Your Address" when it's created.
>
> All the places where address book labels are set are where the user manually sets it. The only time it automatically adds a label is a blank one when you send to a new address. I guess you could have entered the label on an address you thought was mine but the software was confusing and you put it in the wrong place.
That would make sense, I bet that's what happened.
> Address book labels for receiving addresses is confusing but I'm not sure what else to do. Anyone using it for more than just simple purposes would need to create different receiving addresses for each payer so they could tell who's paying them. That concept doesn't have much analogy in the real world.
I think had it said "Received with address: X" rather than just
"Received with: X" I think I would have understood, although I'm sure
that address being mislabeled 'Satoshi' was the primary reason for my
initial confusion. You're right though, there's really nothing
comparable in the current financial system that people are used to other
than maybe being able to use multiple recipient email addresses for
PayPal. Perhaps it could say "Received payment to: X"?
--
Dustin D. Trammell
dtrammell@dustintrammell.com
http://www.dustintrammell.com
>On Mon, 2009-01-19 at 00:54 +0800, Satoshi Nakamoto wrote:
>> It should be your Bitcoin address at home that you received it
>> with. There's no way for it to know who it's from, so the best
>> it can do is tell which of your addresses it was received on.
>> You can create multiple addresses and give a different address
>> to each person and label them to help figure out who's sending
>> to you.
>
>Ah! I didn't even notice it was my address at home, you're right (: I
>do have multiple addresses created at home so I didn't make the
>connection.
>
>> It doesn't know any names other than what you tell it. The name
>> printed there is what's associated in your address book for that
>> address, either under the Address Book button or the "Change..."
>> button to the right of your Bitcoin address.
>
>Ahh you're right, 'Satoshi' is associated with the address that received
>the payment under the Change button's addresses. I don't recall setting
>that value though, is that the default or something? (this is the first,
>default, address that the application generated itself when I first ran
>it)
The first default one is labelled "Your Address" when it's created.
All the places where address book labels are set are where the user manually sets it. The only time it automatically adds a label is a blank one when you send to a new address. I guess you could have entered the label on an address you thought was mine but the software was confusing and you put it in the wrong place.
Address book labels for receiving addresses is confusing but I'm not sure what else to do. Anyone using it for more than just simple purposes would need to create different receiving addresses for each payer so they could tell who's paying them. That concept doesn't have much analogy in the real world.
Satoshi
Re: disk full
Hal Finney correspondence — January 24, 2009 — source: 27.md
I hate duplicating code, but the compiler forces us. Copy the body of
the function above it, like this:
void insert(iterator it, const_iterator first, const_iterator last)
{
if (it == vch.begin() + nReadPos && last - first <= nReadPos)
{
// special case for inserting at the front when there's room
nReadPos -= (last - first);
memcpy(&vch\[nReadPos\], &first\[0\], last - first);
}
else
vch.insert(it, first, last);
}
#if !defined(_MSC_VER) || _MSC_VER >= 1300
void insert(iterator it, const char* first, const char* last)
{
if (it == vch.begin() + nReadPos && last - first <= nReadPos)
{
// special case for inserting at the front when there's room
nReadPos -= (last - first);
memcpy(&vch\[nReadPos\], &first\[0\], last - first);
}
else
vch.insert(it, first, last);
}
#endif
The modified version of serialize.h is attached.
BTW, in my tests, VC8 produced an EXE that would only run on systems
that had VC8 installed on them. The error it gives is extremely vague. I
think they expect you to install a package during setup, but bitcoin
doesn’t have a setup.
My testing has been with MSVC 6.0 SP6 and GCC 3.4.5. GCC is the
release build. There’s nothing wrong with the MSVC 6.0 build other than
its optimization of the SHA routines for generating blocks is slow.
Satoshi
Source file: finneynakamotoemails.pdf
Bitcoin v0.1 released
Cryptography Mailing List (Hal Finney) — January 24, 2009 — source: sni-emails.json#email-37
Jonathan Thornburg writes:
> In the modern world, no major government wants to allow untracable
> international financial transactions above some fairly modest size
> thresholds. (The usual catch-phrases are things like "laundering
> drug money", "tax evasion", and/or "financing terrorist groups".)
> To this end, electronic financial transactions are currently monitored
> by various governments & their agencies, and any but the smallest of
> transactions now come with various ID requirements for the humans
> on each end.
>
> But if each machine in a million-node botnet sends 10 cents to a
> randomly chosen machine in another botnet on the other side of the
> world, you've just moved $100K, in a way that seems very hard to
> trace. To me, this means that no major government is likely to allow
> Bitcoin in its present form to operate on a large scale.
Certainly a valid point, and one which has been widely discussed in
the debates over the years about electronic cash. Bitcoin has a couple
of things going for it: one is that it is distributed, with no single
point of failure, no "mint", no company with officers that can be
subpoenaed and arrested and shut down. It is more like a P2P network,
and as we have seen, despite degrees of at least governmental distaste,
those are still around.
Bitcoin could also conceivably operate in a less anonymous mode, with
transfers being linked to individuals, rather than single-use keys. It
would still be useful to have a large scale, decentralized electronic
payment system.
It also might be possible to refactor and restructure Bitcoin to separate
out the key new idea, a decentralized, global, irreversible transaction
database. Such a functionality might be useful for other purposes. Once
it exists, using it to record monetary transfers would be a sort of side
effect and might be harder to shut down.
> I also worry about other "domestic" ways nasty people could exploit
> a widespread Bitcoin deployment:
> * Spammer botnets could burn through pay-per-send email filters
> trivially (as usual, the costs would fall on people other than the
> botnet herders & spammers).
> * If each machine in a botnet sends 1 cent to a herder, that can add
> up to a significant amount of money. In other words, Bitcoin would
> make botnet herding and the assorted malware industry even more
> profitable than it already is.
It's important to understand that the proof-of-work (POW) aspect of
Bitcoin is primarily oriented around ensuring the soundness of the
historical transaction database. Each Bitcoin data block records a set
of transactions, and includes a hash collision. Subsequent data blocks
have their own transactions, their own collisions, and also chain to
all earlier hashes. The result is that once a block is "buried" under
enough new blocks, it is essentially certain (given the threat model,
namely that attackers cannot muster more than X% of the compute power
of legitimate node operators) that old transactions can't be reversed.
Creating new coins is indeed currently also being done by POW, but I
think that is seen as a temporary expedient, and in fact the current
software phases that out over several years. Hence worries about botnets
being able to manufacture large quantities of POW tokens are only a
temporary concern, in the context of Bitcoin.
There have been a number of discussions in the past about POW tokens as
anti spam measures, given the botnet threat. References are available from
"Proof-of-work system" on Wikipedia. Analyses have yielded mixed results,
depending on the assumptions and system design.
If POW tokens do become useful, and especially if they become money,
machines will no longer sit idle. Users will expect their computers to
be earning them money (assuming the reward is greater than the cost to
operate). A computer whose earnings are being stolen by a botnet will
be more noticeable to its owner than is the case today, hence we might
expect that in that world, users will work harder to maintain their
computers and clean them of botnet infestations.
Countermeasures by botnet operators would include moderating their take,
perhaps only stealing 10% of the productive capacity of invaded computers,
so that their owners would be unlikely to notice. This kind of thinking
quickly degenerates into unreliable speculation, but it points out the
difficulties of analyzing the full ramifications of a world where POW
tokens are valuble.
Hal Finney
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin v0.1 released
Cryptography Mailing List (Bill Frantz) — January 24, 2009 — source: sni-emails.json#email-38
hal at finney.org ("Hal Finney") on Saturday, January 24, 2009 wrote:
>Countermeasures by botnet operators would include moderating their take,
>perhaps only stealing 10% of the productive capacity of invaded computers,
>so that their owners would be unlikely to notice. This kind of thinking
>quickly degenerates into unreliable speculation, but it points out the
>difficulties of analyzing the full ramifications of a world where POW
>tokens are valuble.
Some people tell me that the 0wned machines are among the most secure on
the network because botnet operators work hard to keep others from
compromising "their" machines. I could see the operators moving toward
being legitimate security firms, protecting computers against compromise in
exchange for some of the proof of work (POW) money.
Cheers - Bill
-------------------------------------------------------------------------
Bill Frantz | When it comes to the world | Periwinkle
(408)356-8506 | around us, is there any choice | 16345 Englewood Ave
www.pwpconsult.com | but to explore? - Lisa Randall | Los Gatos, CA 95032
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Bitcoin v0.1 released
Cryptography Mailing List (dan at geer.org) — January 25, 2009 — source: sni-emails.json#email-39
Bill Frantz writes:
-+-----------------
| Some people tell me that the 0wned machines are among the most
| secure on the network because botnet operators work hard to
| keep others from compromising "their" machines. I could see the
| operators moving toward being legitimate security firms,
| protecting computers against compromise in exchange for some of
| the proof of work (POW) money.
I'm one of those people. Quoting from my speech of 1/20:
> Virus attacks have, of course, become rarer over time, which is
> to say that where infectious agents once ruled, today it is
> parasites. Parasites have no reason to kill their hosts -- on
> the contrary they want their hosts to survive well enough to
> feed the parasite. A parasite will generally not care to be all
> that visible, either. The difference between parasitism and
> symbiosis can be a close call in some settings, and of the folks
> who famously bragged of being able to take the Internet down in
> twenty minutes, one has said that a computer may be better
> managed once it is in a botnet than before since the bot-master
> will be serious about closing the machine up tight against
> further penetration and similarly serious about patch
> management. Therefore, since one can then say that both the
> machine's nominal owner and the bot master are mutually helped,
> what we see is evolution from parasite to symbiont in action.
> According to Margulis and Sagan, "Life did not take over the
> globe by combat, but by networking." On this basis and others,
> bot-nets are a life form.
Rest of text upon request. Incidentally, I *highly* recommend
Daniel Suarez's _Daemon_; trust me as to its relevance. Try
this for a non-fiction taste:
http://fora.tv/2008/08/08/Daniel_Suarez_Daemon_Bot-Mediated_Reality
--dan
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
[bitcoin-list] Problems
bitcoin-list Mailing List (Nicholas Bohm) — January 25, 2009 — source: sni-emails.json#email-47
I have had a couple of problems running bitcoin: is this an appropriate
list for reporting them (with about 70kb of attachments)?
Nicholas Bohm
--
Salkyns, Great Canfield, Takeley,
Bishop's Stortford CM22 6SX, UK
Phone 01279 870285 (+44 1279 870285)
Mobile 07715 419728 (+44 7715 419728)
PGP public key ID: 0x899DD7FF. Fingerprint:
5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF
Bitcoin v0.1 released
Cryptography Mailing List (Satoshi Nakamoto) — January 25, 2009 — source: sni-emails.json#email-40
Hal Finney wrote:
> > * Spammer botnets could burn through pay-per-send email filters
> > trivially
> If POW tokens do become useful, and especially if they become money,
> machines will no longer sit idle. Users will expect their computers to
> be earning them money (assuming the reward is greater than the cost to
> operate). A computer whose earnings are being stolen by a botnet will
> be more noticeable to its owner than is the case today, hence we might
> expect that in that world, users will work harder to maintain their
> computers and clean them of botnet infestations.
Another 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.
Satoshi Nakamoto
---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com
Re: [bitcoin-list] Problems
bitcoin-list Mailing List (Satoshi Nakamoto) — January 25, 2009 — source: sni-emails.json#email-48
From: Nicholas Bohm 2009-01-25 10:17
> I have had a couple of problems running bitcoin: is this an appropriate
> list for reporting them (with about 70kb of attachments)?
What's the problem you're having?
If you send me your debug.log file directly (best not to send attachments
to the list), I can take a look at what's happening.
Satoshi Nakamoto
bitcoin-help at vistomail dot com
[bitcoin-list] Bitcoin v0.1.5 released
bitcoin-list Mailing List (Satoshi Nakamoto) — February 04, 2009 — source: sni-emails.json#email-49
Version 0.1.5 is now available. It includes the fix for the problem
Nicholas had, checking for disk full and changes to try to improve
things that were confusing.
Special thanks to Nicholas and Dustin for all their help and feedback!
Download link:
http://sourceforge.net/project/showfiles.php?group_id=244765&package_id=298441
Changes:
- disk full warning
- fixed a bug that could occur if dns lookup failed
- prevent entering your own address in the address book,
which confusingly changed the label for your own address
- moved change address button to menu under options
- tweaks to make it get connected faster
- close sockets on exit
- created minimum fee for transactions less than 1 cent
- hid the transaction-type selection box that only had one choice
- cleaned up ParseMoney a little
- slightly cleaner reformatting of message text
- changed the font in transaction details dialog
- added some explanation text to transaction details for generated coins
- reworded the description for transactions received with bitcoin address
Satoshi Nakamoto
http://www.bitcoin.org
[p2p-research] Bitcoin open source implementation of P2P currency
P2P Research Mailing List (Satoshi Nakamoto) — February 11, 2009 — source: sni-emails.json#email-64
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 <a href="http://www.bitcoin.org/">http://www.bitcoin.org</a>
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
<a href="http://www.bitcoin.org/bitcoin.pdf">http://www.bitcoin.org/bitcoin.pdf</a>
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.
Satoshi Nakamoto
<a href="http://www.bitcoin.org/">http://www.bitcoin.org</a>
[p2p-research] Bitcoin open source implementation of P2P currency
P2P Research Mailing List (Michel Bauwens) — February 12, 2009 — source: sni-emails.json#email-65
Thanks for sharing this initiative, I hope some of our more expert members
will intervene.
I have an extra request if possible, our pages on Japanese initiatives, I'm
assuming that is where you are based, though I could of course be wrong, are
still very undeveloped, so I'm wondering if you could not add a few of the
important open/free and commons oriented initiatives that you know about,
including your own.
See <a href="http://p2pfoundation.net/Japan">http://p2pfoundation.net/Japan</a>
Michel
On Thu, Feb 12, 2009 at 5:30 AM, Satoshi Nakamoto <<a href="http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org">satoshin at gmx.com</a>> wrote:
><i> I've developed a new open source P2P e-cash system called Bitcoin. It's
</i>><i> completely decentralized, with no central server or trusted parties, because
</i>><i> everything is based on crypto proof instead of trust. Give it a try, or
</i>><i> take a look at the screenshots and design paper:
</i>><i>
</i>><i> Download Bitcoin v0.1 at <a href="http://www.bitcoin.org/">http://www.bitcoin.org</a>
</i>><i>
</i>><i> The root problem with conventional currency is all the trust that's
</i>><i> required to make it work. The central bank must be trusted not to debase
</i>><i> the currency, but the history of fiat currencies is full of breaches of that
</i>><i> trust. Banks must be trusted to hold our money and transfer it
</i>><i> electronically, but they lend it out in waves of credit bubbles with barely
</i>><i> a fraction in reserve. We have to trust them with our privacy, trust them
</i>><i> not to let identity thieves drain our accounts. Their massive overhead
</i>><i> costs make micropayments impossible.
</i>><i>
</i>><i> A generation ago, multi-user time-sharing computer systems had a similar
</i>><i> problem. Before strong encryption, users had to rely on password protection
</i>><i> to secure their files, placing trust in the system administrator to keep
</i>><i> their information private. Privacy could always be overridden by the admin
</i>><i> based on his judgment call weighing the principle of privacy against other
</i>><i> concerns, or at the behest of his superiors. Then strong encryption became
</i>><i> available to the masses, and trust was no longer required. Data could be
</i>><i> secured in a way that was physically impossible for others to access, no
</i>><i> matter for what reason, no matter how good the excuse, no matter what.
</i>><i>
</i>><i> It's time we had the same thing for money. With e-currency based on
</i>><i> cryptographic proof, without the need to trust a third party middleman,
</i>><i> money can be secure and transactions effortless.
</i>><i>
</i>><i> One of the fundamental building blocks for such a system is digital
</i>><i> signatures. A digital coin contains the public key of its owner. To
</i>><i> transfer it, the owner signs the coin together with the public key of the
</i>><i> next owner. Anyone can check the signatures to verify the chain of
</i>><i> ownership. It works well to secure ownership, but leaves one big problem
</i>><i> unsolved: double-spending. Any owner could try to re-spend an already spent
</i>><i> coin by signing it again to another owner. The usual solution is for a
</i>><i> trusted company with a central database to check for double-spending, but
</i>><i> that just gets back to the trust model. In its central position, the
</i>><i> company can override the users, and the fees needed to support the company
</i>><i> make micropayments impractical.
</i>><i>
</i>><i> Bitcoin's solution is to use a peer-to-peer network to check for
</i>><i> double-spending. In a nutshell, the network works like a distributed
</i>><i> timestamp server, stamping the first transaction to spend a coin. It takes
</i>><i> advantage of the nature of information being easy to spread but hard to
</i>><i> stifle. For details on how it works, see the design paper at
</i>><i> <a href="http://www.bitcoin.org/bitcoin.pdf">http://www.bitcoin.org/bitcoin.pdf</a>
</i>><i>
</i>><i> The result is a distributed system with no single point of failure. Users
</i>><i> hold the crypto keys to their own money and transact directly with each
</i>><i> other, with the help of the P2P network to check for double-spending.
</i>><i>
</i>><i> Satoshi Nakamoto
</i>><i> <a href="http://www.bitcoin.org/">http://www.bitcoin.org</a>
</i>><i>
</i>><i> _______________________________________________
</i>><i> p2presearch mailing list
</i>><i> <a href="http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org">p2presearch at listcultures.org</a>
</i>><i> <a href="http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org">http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org</a>
</i>><i>
</i>
--
The P2P Foundation researches, documents and promotes peer to peer
alternatives.
Wiki and Encyclopedia, at <a href="http://p2pfoundation.net;/">http://p2pfoundation.net;</a> Blog, at
<a href="http://blog.p2pfoundation.net;/">http://blog.p2pfoundation.net;</a> Newsletter, at
<a href="http://integralvisioning.org/index.php?topic=p2p">http://integralvisioning.org/index.php?topic=p2p</a>
Basic essay at <a href="http://www.ctheory.net/articles.aspx?id=499;">http://www.ctheory.net/articles.aspx?id=499;</a> interview at
<a href="http://poynder.blogspot.com/2006/09/p2p-very-core-of-world-to-come.html">http://poynder.blogspot.com/2006/09/p2p-very-core-of-world-to-come.html</a>
BEST VIDEO ON P2P:
<a href="http://video.google.com.au/videoplay?docid=4549818267592301968&hl=en-AU">http://video.google.com.au/videoplay?docid=4549818267592301968&hl=en-AU</a>
KEEP UP TO DATE through our Delicious tags at <a href="http://del.icio.us/mbauwens">http://del.icio.us/mbauwens</a>
The work of the P2P Foundation is supported by SHIFTN,
<a href="http://www.shiftn.com/">http://www.shiftn.com/</a>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <<a href="http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090212/41b802b7/attachment-0001.html">http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090212/41b802b7/attachment-0001.html</a>>
[p2p-research] Bitcoin open source implementation of P2P currency
P2P Research Mailing List (Martien van Steenbergen) — February 12, 2009 — source: sni-emails.json#email-66
Very interesting. Is this akin to David Chaum's anonymous digital
money? His concept makes sure money is anonymous unless it is
compromised, i.e. the same money spent more than once. As soon as it's
compromised, the ‘counterfeiter’ is immediately publicly exposed.
Also, in bitcoin, is there a limited supply of money (that must be
managed)? Or is money created exaclty at the moment of transaction?
Succes en plezier,
Martien.
On 11 Feb 2009, at 23:30 , Satoshi Nakamoto wrote:
><i> I've developed a new open source P2P e-cash system called Bitcoin.
</i>><i> It's completely decentralized, with no central server or trusted
</i>><i> parties, because everything is based on crypto proof instead of
</i>><i> trust. Give it a try, or take a look at the screenshots and design
</i>><i> paper:
</i>><i>
</i>><i> Download Bitcoin v0.1 at <a href="http://www.bitcoin.org/">http://www.bitcoin.org</a>
</i>><i>
</i>><i> The root problem with conventional currency is all the trust that's
</i>><i> required to make it work. The central bank must be trusted not to
</i>><i> debase the currency, but the history of fiat currencies is full of
</i>><i> breaches of that trust. Banks must be trusted to hold our money and
</i>><i> transfer it electronically, but they lend it out in waves of credit
</i>><i> bubbles with barely a fraction in reserve. We have to trust them
</i>><i> with our privacy, trust them not to let identity thieves drain our
</i>><i> accounts. Their massive overhead costs make micropayments impossible.
</i>><i>
</i>><i> A generation ago, multi-user time-sharing computer systems had a
</i>><i> similar problem. Before strong encryption, users had to rely on
</i>><i> password protection to secure their files, placing trust in the
</i>><i> system administrator to keep their information private. Privacy
</i>><i> could always be overridden by the admin based on his judgment call
</i>><i> weighing the principle of privacy against other concerns, or at the
</i>><i> behest of his superiors. Then strong encryption became available to
</i>><i> the masses, and trust was no longer required. Data could be secured
</i>><i> in a way that was physically impossible for others to access, no
</i>><i> matter for what reason, no matter how good the excuse, no matter what.
</i>><i>
</i>><i> It's time we had the same thing for money. With e-currency based on
</i>><i> cryptographic proof, without the need to trust a third party
</i>><i> middleman, money can be secure and transactions effortless.
</i>><i>
</i>><i> One of the fundamental building blocks for such a system is digital
</i>><i> signatures. A digital coin contains the public key of its owner.
</i>><i> To transfer it, the owner signs the coin together with the public
</i>><i> key of the next owner. Anyone can check the signatures to verify
</i>><i> the chain of ownership. It works well to secure ownership, but
</i>><i> leaves one big problem unsolved: double-spending. Any owner could
</i>><i> try to re-spend an already spent coin by signing it again to another
</i>><i> owner. The usual solution is for a trusted company with a central
</i>><i> database to check for double-spending, but that just gets back to
</i>><i> the trust model. In its central position, the company can override
</i>><i> the users, and the fees needed to support the company make
</i>><i> micropayments impractical.
</i>><i>
</i>><i> Bitcoin's solution is to use a peer-to-peer network to check for
</i>><i> double-spending. In a nutshell, the network works like a
</i>><i> distributed timestamp server, stamping the first transaction to
</i>><i> spend a coin. It takes advantage of the nature of information being
</i>><i> easy to spread but hard to stifle. For details on how it works, see
</i>><i> the design paper at <a href="http://www.bitcoin.org/bitcoin.pdf">http://www.bitcoin.org/bitcoin.pdf</a>
</i>><i>
</i>><i> The result is a distributed system with no single point of failure.
</i>><i> Users hold the crypto keys to their own money and transact directly
</i>><i> with each other, with the help of the P2P network to check for
</i>><i> double-spending.
</i>><i>
</i>><i> Satoshi Nakamoto
</i>><i> <a href="http://www.bitcoin.org/">http://www.bitcoin.org</a>
</i>><i>
</i>><i> _______________________________________________
</i>><i> p2presearch mailing list
</i>><i> <a href="http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org">p2presearch at listcultures.org</a>
</i>><i> <a href="http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org">http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org</a>
</i>
[p2p-research] Bitcoin open source implementation of P2P currency
P2P Research Mailing List (Satoshi Nakamoto) — February 12, 2009 — source: sni-emails.json#email-67
Martien van Steenbergen wrote:
><i> Very interesting. Is this akin to David Chaum's anonymous digital money?
</i>><i> His concept makes sure money is anonymous unless it is compromised, i.e.
</i>><i> the same money spent more than once. As soon as it's compromised, the
</i>><i> ‘counterfeiter’ is immediately publicly exposed.
</i>
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.
><i> Also, in bitcoin, is there a limited supply of money (that must be
</i>><i> managed)? Or is money created exaclty at the moment of transaction?
</i>
There is a limited supply of money. Circulation will be 21,000,000
coins. Transactions only transfer ownership.
Thank you for your questions,
Satoshi
<a href="http://www.bitcoin.org/">http://www.bitcoin.org</a>
[p2p-research] Bitcoin open source implementation of P2P currency
P2P Research Mailing List (Martien van Steenbergen) — February 12, 2009 — source: sni-emails.json#email-68
On 12 Feb 2009, at 20:01 , Satoshi Nakamoto wrote:
><i> Martien van Steenbergen wrote:
</i>>><i> Very interesting. Is this akin to David Chaum's anonymous digital
</i>>><i> money? His concept makes sure money is anonymous unless it is
</i>>><i> compromised, i.e. the same money spent more than once. As soon as
</i>>><i> it's compromised, the ‘counterfeiter’ is immediately publicly
</i>>><i> exposed.
</i>><i>
</i>><i> It's similar in that it uses digital signatures for coins, but
</i>><i> different in the approach to privacy and preventing double-
</i>><i> spending. The recipient of a Bitcoin payment is able to check
</i>><i> whether it is the first spend or not, and second-spends are not
</i>><i> accepted. There isn't an off-line mode where double-spenders are
</i>><i> caught and shamed after the fact, because that would require
</i>><i> participants to have identities.
</i>
Thanks for clearing this up.
><i> To protect privacy, key pairs are used only once, with a new one for
</i>><i> every transaction. The owner of a coin is just whoever has its
</i>><i> private key.
</i>
IC.
><i> Of course, the biggest difference is the lack of a central server.
</i>><i> That was the Achilles heel of Chaumian systems; when the central
</i>><i> company shut down, so did the currency.
</i>
Yes, that's really great. Reminds me of:
AardRock » Wizard Rabbit Treasurer; and
AardRock » Pekunio
>><i> Also, in bitcoin, is there a limited supply of money (that must be
</i>>><i> managed)? Or is money created exaclty at the moment of transaction?
</i>><i>
</i>><i> There is a limited supply of money. Circulation will be 21,000,000
</i>><i> coins. Transactions only transfer ownership.
</i>
Would love to also see support for not having to supply and managing
money. Would make it easier and cheaper to maintain and results in
have sufficient money, always and everywhere. No scarcity, no
abundance, exactly the right amount all times, self-organizing.
Are you familiar with Ripple?
Is bitcoin also available as a protocol spec (facilitating differen
language bindings and implementations; unite on specs, compete on
implementation).
Succes en plezier,
Martien.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <<a href="http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090212/9c83bdd1/attachment.html">http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090212/9c83bdd1/attachment.html</a>>
[p2p-research] Bitcoin open source implementation of P2P currency
P2P Research Mailing List (Satoshi Nakamoto) — February 13, 2009 — source: sni-emails.json#email-69
Martien van Steenbergen wrote:
> Would love to also see support for not having to supply and
> managing money. Would make it easier and cheaper to maintain
> and results in have sufficient money, always and everywhere.
> No scarcity, no abundance, exactly the right amount all times,
> self-organizing.
That's do-able. It can be programmed to follow any set of rules.
I see Bitcoin as a foundation and first step if you want to implement
programmable P2P social currencies like Marc's ideas and others
discussed here. First you need normal, basic P2P currency working.
Once that is established and proven out, dynamic smart money is an easy
next step.
I love the idea of virtual, non-geographic communities experimenting
with new economic paradigms.
><i> Reminds me of:
</i>><i>
</i>><i> * AardRock » Wizard Rabbit Treasurer
</i>><i> <<a href="http://wiki.aardrock.com/Wizard_Rabbit_Treasurer">http://wiki.aardrock.com/Wizard_Rabbit_Treasurer</a>>; and
</i>><i> * AardRock » Pekunio <<a href="http://wiki.aardrock.com/Pekunio">http://wiki.aardrock.com/Pekunio</a>>
</i>
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.
><i> Are you familiar with Ripple?
</i>
As trust systems go, Ripple is unique in spreading trust around rather
than concentrating it.
><i> Is bitcoin also available as a protocol spec (facilitating differen
</i>><i> language bindings and implementations; unite on specs, compete on
</i>><i> implementation).
</i>
It would be best to refer to the C++ source code. I plan to implement
interfaces for using the software to send and receive transactions from
any language, so server side code can easily use it for web based
e-commerce sites.
Satoshi
[p2p-research] Bitcoin open source implementation of P2P currency
P2P Research Mailing List (Michel Bauwens) — February 13, 2009 — source: sni-emails.json#email-70
Hi Satoshi,
how operational is your project? how soon do you think people will be able
to use it in real life?
Michel
On Fri, Feb 13, 2009 at 9:31 AM, Satoshi Nakamoto <<a href="http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org">satoshin at gmx.com</a>> wrote:
><i> Martien van Steenbergen wrote:
</i>><i> > Would love to also see support for not having to supply and
</i>><i> > managing money. Would make it easier and cheaper to maintain
</i>><i> > and results in have sufficient money, always and everywhere.
</i>><i> > No scarcity, no abundance, exactly the right amount all times,
</i>><i> > self-organizing.
</i>><i>
</i>><i> That's do-able. It can be programmed to follow any set of rules.
</i>><i>
</i>><i> I see Bitcoin as a foundation and first step if you want to implement
</i>><i> programmable P2P social currencies like Marc's ideas and others discussed
</i>><i> here. First you need normal, basic P2P currency working. Once that is
</i>><i> established and proven out, dynamic smart money is an easy next step.
</i>><i>
</i>><i> I love the idea of virtual, non-geographic communities experimenting with
</i>><i> new economic paradigms.
</i>><i>
</i>><i> Reminds me of:
</i>>><i>
</i>>><i> * AardRock » Wizard Rabbit Treasurer
</i>>><i> <<a href="http://wiki.aardrock.com/Wizard_Rabbit_Treasurer">http://wiki.aardrock.com/Wizard_Rabbit_Treasurer</a>>; and
</i>>><i> * AardRock » Pekunio <<a href="http://wiki.aardrock.com/Pekunio">http://wiki.aardrock.com/Pekunio</a>>
</i>>><i>
</i>><i>
</i>><i> Indeed, it is much like Pekunio in the concept of spraying redundant copies
</i>><i> of every transaction to a number of peers on the network, but the
</i>><i> implementation is not a reputation network like Wizard Rabbit Treasurer. In
</i>><i> fact, Bitcoin does not use reputation at all. It sees the network as just a
</i>><i> big crowd and doesn't much care who it talks to or who tells it something,
</i>><i> as long as at least one of them relays the information being broadcast
</i>><i> around the network. It doesn't care because there's no way to lie to it.
</i>><i> Either you tell it crypto proof of something, or it ignores you.
</i>><i>
</i>><i> Are you familiar with Ripple?
</i>>><i>
</i>><i>
</i>><i> As trust systems go, Ripple is unique in spreading trust around rather than
</i>><i> concentrating it.
</i>><i>
</i>><i> Is bitcoin also available as a protocol spec (facilitating differen
</i>>><i> language bindings and implementations; unite on specs, compete on
</i>>><i> implementation).
</i>>><i>
</i>><i>
</i>><i> It would be best to refer to the C++ source code. I plan to implement
</i>><i> interfaces for using the software to send and receive transactions from any
</i>><i> language, so server side code can easily use it for web based e-commerce
</i>><i> sites.
</i>><i>
</i>><i> Satoshi
</i>><i>
</i>><i>
</i>><i> _______________________________________________
</i>><i> p2presearch mailing list
</i>><i> <a href="http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org">p2presearch at listcultures.org</a>
</i>><i> <a href="http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org">http://listcultures.org/mailman/listinfo/p2presearch_listcultures.org</a>
</i>><i>
</i>
--
The P2P Foundation researches, documents and promotes peer to peer
alternatives.
Wiki and Encyclopedia, at <a href="http://p2pfoundation.net;/">http://p2pfoundation.net;</a> Blog, at
<a href="http://blog.p2pfoundation.net;/">http://blog.p2pfoundation.net;</a> Newsletter, at
<a href="http://integralvisioning.org/index.php?topic=p2p">http://integralvisioning.org/index.php?topic=p2p</a>
Basic essay at <a href="http://www.ctheory.net/articles.aspx?id=499;">http://www.ctheory.net/articles.aspx?id=499;</a> interview at
<a href="http://poynder.blogspot.com/2006/09/p2p-very-core-of-world-to-come.html">http://poynder.blogspot.com/2006/09/p2p-very-core-of-world-to-come.html</a>
BEST VIDEO ON P2P:
<a href="http://video.google.com.au/videoplay?docid=4549818267592301968&hl=en-AU">http://video.google.com.au/videoplay?docid=4549818267592301968&hl=en-AU</a>
KEEP UP TO DATE through our Delicious tags at <a href="http://del.icio.us/mbauwens">http://del.icio.us/mbauwens</a>
The work of the P2P Foundation is supported by SHIFTN,
<a href="http://www.shiftn.com/">http://www.shiftn.com/</a>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <<a href="http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090213/148aa6a5/attachment.html">http://listcultures.org/pipermail/p2presearch_listcultures.org/attachments/20090213/148aa6a5/attachment.html</a>>
[p2p-research] Bitcoin open source implementation of P2P currency
P2P Research Mailing List (Satoshi Nakamoto) — February 13, 2009 — source: sni-emails.json#email-71
Michel Bauwens wrote:
><i> how operational is your project? how soon do you think people will be
</i>><i> able to use it in real life?
</i>
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.
I'll forward the release introduction in the next message.
Satoshi
<a href="http://www.bitcoin.org/">http://www.bitcoin.org</a>
[p2p-research] Bitcoin P2P e-currency v0.1 released
P2P Research Mailing List (Satoshi Nakamoto) — February 13, 2009 — source: sni-emails.json#email-72
Announcing the release of Bitcoin, a new open source peer-to-peer
electronic cash system that's completely decentralized, with no central
server or trusted parties. 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.
Windows NT/2000/XP/Vista. Open source C++ code is included.
Download: <a href="http://www.bitcoin.org/">http://www.bitcoin.org</a>
- Unpack the files into a directory
- Run BITCOIN.EXE
- It automatically connects to other nodes
If you can keep a node running that accepts incoming connections, you'll
really be helping the network a lot. Port 8333 on your firewall needs
to be open to receive incoming connections.
You can get coins by getting someone to send you some, or turn on
Options->Generate Coins to run a node and generate blocks. I made the
proof-of-work difficulty ridiculously easy to start with, so for a
little while in the beginning a typical PC will be able to generate
coins in just a few hours. It'll get a lot harder when competition
makes the automatic adjustment drive up the difficulty. Generated coins
must wait 120 blocks to mature before they can be spent.
There are two ways to send money. If the recipient is online, you can
enter their IP address and it will connect, get a new public key and
send the transaction with comments. If the recipient is not online, it
is possible to send to their Bitcoin address, which is a hash of their
public key that they give you. They'll receive the transaction the next
time they connect and get the block it's in. This method has the
disadvantage that no comment information is sent, and a bit of privacy
may be lost if the address is used multiple times, but it is a useful
alternative if both users can't be online at the same time or the
recipient can't receive incoming connections.
Total circulation will be 21,000,000 coins. It'll be distributed to
network nodes when they make blocks, with the amount cut in half every 4
years.
first 4 years: 10,500,000 coins
next 4 years: 5,250,000 coins
next 4 years: 2,625,000 coins
next 4 years: 1,312,500 coins
etc...
When that runs out, the system can support transaction fees if needed.
It's based on open market competition, and there will probably always be
nodes willing to process transactions for free.
Satoshi Nakamoto
<a href="http://www.bitcoin.org/">http://www.bitcoin.org</a>
[bitcoin-list] Bitcoin v0.1.5 released
bitcoin-list Mailing List (Nicholas Bohm) — February 18, 2009 — source: sni-emails.json#email-50
Version 0.1.5 seems to be running trouble free. I have a list of 201
transactions, I've accumulated about bc8550. Transfers in and out seem
to work fine (after a bit of head-scratching to understand the labelling
of incoming transactions).
What's next?
Nicholas Bohm
--
Salkyns, Great Canfield, Takeley,
Bishop's Stortford CM22 6SX, UK
Phone 01279 870285 (+44 1279 870285)
Mobile 07715 419728 (+44 7715 419728)
PGP public key ID: 0x899DD7FF. Fingerprint:
5248 1320 B42E 84FC 1E8B A9E6 0912 AE66 899D D7FF
Re: [bitcoin-list] Bitcoin v0.1.5 released
bitcoin-list Mailing List (Satoshi Nakamoto) — February 22, 2009 — source: sni-emails.json#email-51
> What's next?
The next thing for v0.1.6 is to take advantage of multiple
processors to generate blocks. Currently it only starts one
thread. If you have a multi-core processor like a Core Duo or
Quad this will double or quadruple your production.
Later I want to add interfaces to make it really easy to integrate
into websites from any server side language.
Satoshi
http://www.bitcoin.org
Re: [bitcoin-list] Bitcoin v0.1.5 released
bitcoin-list Mailing List (Hal Finney) — February 27, 2009 — source: sni-emails.json#email-52
On Sun, Feb 22, 2009 at 9:35 AM, Satoshi Nakamoto <satoshi@...> wrote:
>> What's next?
>
> The next thing for v0.1.6 is to take advantage of multiple
> processors to generate blocks. Currently it only starts one
> thread. If you have a multi-core processor like a Core Duo or
> Quad this will double or quadruple your production.
That sounds good. I'd also like to be able to run multiple coin/block
generators on multiple machines, all behind a single NAT address. I
haven't tried this yet so I don't know if it works on the current
software.
BTW I don't remember if we talked about this, but the other day some
people were mentioning secure timestamping. You want to be able to
prove that a certain document existed at a certain time in the past.
Seems to me that bitcoin's stack of blocks would be perfect for this.
> Later I want to add interfaces to make it really easy to integrate
> into websites from any server side language.
Right, and I'd like to see more of a library interface that could be
called from programming or scripting languages, on the client side as
well.
Hal
Re: [bitcoin-list] Bitcoin v0.1.5 released
bitcoin-list Mailing List (Satoshi Nakamoto) — March 04, 2009 — source: sni-emails.json#email-53
Hal Finney wrote:
> That sounds good. I'd also like to be able to run multiple coin/block
> generators on multiple machines, all behind a single NAT address. I
> haven't tried this yet so I don't know if it works on the current
> software.
The current version will work fine. They'll each connect over the
Internet, while incoming connections only come to the host that
port 8333 is routed to.
As an optimisation, I'll make a switch "-connect=1.2.3.4" to make
it only connect to a specific address. You could make your extra
nodes connect to your primary, and only the primary connects over
the Internet. It doesn't really matter for now, since the network
would have to get huge before the bandwidth is anything more than
trivial.
> BTW I don't remember if we talked about this, but the other day some
> people were mentioning secure timestamping. You want to be able to
> prove that a certain document existed at a certain time in the past.
> Seems to me that bitcoin's stack of blocks would be perfect for this.
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.
> > > Later I want to add interfaces to make it really easy to integrate
> > > into websites from any server side language.
>
> Right, and I'd like to see more of a library interface that could be
> called from programming or scripting languages, on the client side as
> well.
Exactly.
Satoshi Nakamoto
http://www.bitcoin.org
From: Mike Hearn Date: Sun, Apr 12,
2009 at 12:46 PM To: satoshin@gmx.comThread: Questions
about BitCoin
Hi Satoshi,
I read your paper on BitCoin with great interest. I found it a bit
confusing though - I believe it may be easier to follow if you provide
some examples.
Specifically, it's not quite clear to me what blocks contain. If I
understand correctly, there is only one (or maybe a few) global
chain[s] into which all transactions are hashed. If there is only one
chain recording "the story of the economy" so to speak, how does this
scale? In an imaginary planet-wide deployment there would be millions
of even billions of transactions per hour being hashed into the chain.
I realize that each PoW can wrap many transactions in one block,
nonetheless, that's a large amount of data to hash. If there are many
chains, how are transactions assigned to each chain such that it is
still difficult to overpower the network? Eg, if there are 10 global
chains, the amount of cpu power you need to beat the system is only
10% of what it was previously.
I also wonder if the assumption of 1 core = 1 vote is sound. If the
majority of nodes are on standard computers, it seems likely that an
attacker could use FPGA or custom ASICs to get significantly better
performance. What are your thoughts on using custom hardware to beat
the chain?
I found the section on incentives hard to follow. In particular, I'm
not clear on what triggers the transition from minting new coins as a
reason to run a node, to charging transaction fees (isn't the point of
BitCoin largely to zero transaction costs anyway?). Presumably there's
some human in charge of the system - eg, you decided somehow that 24
million coins was a good number to have, and would distribute some
kind of rules file saying "coins minted after this timestamp must have
an N+1 zero bits prefix", which honest nodes enforce.
How did you decide on the inflation schedule for v1? Where did 24
million coins come from? What denominations are these coins? You
mention a way to combine and split value but I'm not clear on how this
works. For instance are bitcoins always denominated by an integer or
can you have fractional bitcoins?
So many questions :) But it's rare that I encounter truly
revolutionary ideas. The last time I was this excited about a new
monetary scheme was when I discovered Ripple. If you have any thoughts
on Ripple, I'd also love to hear them.
thanks -mike
Questions about BitCoin — reply 2
Mike Hearn correspondence (Satoshi Nakamoto) — April 12, 2009 — source: hearn-thread1.html#msg-2
From: Satoshi Nakamoto Date: Sun,
Apr 12, 2009 at 10:44 PM To: Mike Hearn mike@plan99.netThread: Questions
about BitCoin
Hi Mike,
I'm glad to answer any questions you have. If I get time, I ought to write a FAQ to supplement the paper.
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.
Eventually, most nodes may be run by specialists with multiple GPU cards. For now, it's nice that anyone with a PC can play without worrying about what video card they have, and hopefully it'll stay that way for a while. More computers are shipping with fairly decent GPUs these days, so maybe later we'll transition to that.
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.
Satoshi
[Quoted text hidden]
From: Mike Hearn Date: Mon, Apr 13,
2009 at 1:39 PM To: Satoshi Nakamoto satoshin@gmx.comThread: Questions
about BitCoin
Thanks Satoshi,
I tried the app yesterday. It seems to work pretty well running on
Wine (I tried it on MacOS but it should run on Linux too, and will try
that next week when I am back at work).
In the lower right hand corner it has a block count which increases
rapidly and then stops. Is this the length of the global chain? It
seems to advance far too fast for that. Or is this the number of
genesis blocks that have been tried but did not result in a partial
collision? I'm not sure if the way it stops and starts is expected, or
some glitch caused by it running under emulation. My best guess - it
is the length of the global chain, and the rapid advance at the start
is as the software downloads and verifies the preceding blocks in the
chain as being valid.
With regards to the buyer/seller experience, I understand that the
global chain advances at about 6-7 blocks per hour under the current
settings. If we assume that 0.1% is a good risk rate, then z=5 thus
any transaction must wait a bit less than an hour before being
solidified in the chain. As micropayments for things like web content
or virtual goods are by definition something that requires low
overhead, waiting an hour seems like quite a significant hurdle.
I understand that nodes attempt to find a POW to advance the global
chain in an uncoordinated fashion. This sentence however:
"If a majority of CPU power is controlled by honest nodes, the
honest chain will grow the fastest and outpace any competing chains."
is confusing for me, because it appears the only way the honest chain
can grow faster than a chain worked on by 1 attacking cpu is if the
keyspace to scan looking for a partial collision is sharded evenly
amongst the participating honest nodes. That way the speed at which
collisions are found would be proportional to the number of nodes. Yet
I don't see any discussion of such work sharding, which obviously adds
complexity. Likewise:
"To compensate for increasing hardware speed and varying interest
in running nodes over time,
the proof-of-work difficulty is determined by a moving average
targeting an average number of
blocks per hour. If they're generated too fast, the difficulty increases."
How is the required difficulty of each block communicated through the
network and agreed upon?
Thanks once again. I have yet more questions but this is enough for
one email :) I will be happy to summarize these discussions into an
FAQ-like document at some point. Apologies if the questions seem
trivial.
-mike
[Quoted text hidden]
From: Mike Hearn Date: Mon, Apr 13,
2009 at 10:51 PM To: Satoshi Nakamoto satoshin@gmx.comThread: Questions
about BitCoin
Something else that isn't clear to me - does the global chain only get
extended when there is actual work to do? Currently it seems to grow
all the time, although there are only a few people in the network. So
presumably it gets extended with null blocks. Is this actually
required? The timestamping doesn't have to be actually in parallel
with real time does it ... it's merely establishing an ordering of
events.
[Quoted text hidden]
Questions about BitCoin — reply 5
Mike Hearn correspondence (Satoshi Nakamoto) — April 13, 2009 — source: hearn-thread1.html#msg-5
From: Satoshi Nakamoto Date: Mon,
Apr 13, 2009 at 11:00 PM To: Mike Hearn mike@plan99.netThread: Questions
about BitCoin
Mike Hearn wrote:
My best guess - it
is the length of the global chain, and the rapid advance at the start
is as the software downloads and verifies the preceding blocks in the
chain as being valid.
Right. I'm trying to think of more clear wording for that, maybe "%d network blocks" or "%d block chain".
If we assume that 0.1% is a good risk rate, then z=5 thus
any transaction must wait a bit less than an hour before being
solidified in the chain. As micropayments for things like web content
or virtual goods are by definition something that requires low
overhead, waiting an hour seems like quite a significant hurdle.
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.
is confusing for me, because it appears the only way the honest chain
can grow faster than a chain worked on by 1 attacking cpu is if the
keyspace to scan looking for a partial collision is sharded evenly
amongst the participating honest nodes. That way the speed at which
collisions are found would be proportional to the number of nodes. Yet
I don't see any discussion of such work sharding, which obviously adds
complexity.
The keyspace is huge, 2^256. The thing being hashed includes the node's public key and a random nonce, so the chance of any two nodes duplicating work on the same space is negligible.
How is the required difficulty of each block communicated through the
network and agreed upon?
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.
Thanks once again. I have yet more questions but this is enough for
one email :) I will be happy to summarize these discussions into an
FAQ-like document at some point. Apologies if the questions seem
trivial.
No problem, thanks for testing it on Mac Wine.
Satoshi
[Quoted text hidden]
Questions about BitCoin — reply 6
Mike Hearn correspondence (Satoshi Nakamoto) — April 13, 2009 — source: hearn-thread1.html#msg-6
From: Satoshi Nakamoto Date: Mon,
Apr 13, 2009 at 11:11 PM To: Mike Hearn mike@plan99.netThread: Questions
about BitCoin
It keeps getting extended all the time. If it stopped, an attacker would have time to catch up. Don't worry, empty blocks aren't very big.
As you say, it's the order of events that matters.
[Quoted text hidden]
From: Mike Hearn Date: Mon, Apr 13,
2009 at 11:18 PM To: Satoshi Nakamoto satoshin@gmx.comThread: Questions
about BitCoin
Oh yes, of course, that's fundamental. Silly me. Thanks for your
answers. I'd recommend being over-explicit for early versions of the
software, something like "Global chain is currently %d blocks long".
I guess the key problem right now is that once you generate coins,
there's nobody to test it with, even for dummy transactions. Is there
a plan for a mailing list or some kind of trivial marketplace to give
people something to do with their newly minted bitcoins?
Questions about BitCoin — reply 8
Mike Hearn correspondence (Satoshi Nakamoto) — April 14, 2009 — source: hearn-thread1.html#msg-8
From: Satoshi Nakamoto Date: Tue,
Apr 14, 2009 at 7:41 PM To: Mike Hearn mike@plan99.netThread: Questions
about BitCoin
I started implementing a marketplace feature earlier that facilitates offering things for sale and taking orders, it's only half done though. A bit like e-bay but without auctions, just "buy now". Among other things, it would make it easy for anyone to offer currency exchange.
If you send to 1PhUXucRd8FzQved2KGK3g1eKfTHPG
jgFu and e-mail me your bitcoin address, or IP if you can accept incoming connections, I'll send back the same amount +50.
[Quoted text hidden]
From: Mike Hearn Date: Sat, Apr 18,
2009 at 3:08 PM To: Satoshi Nakamoto satoshin@gmx.comThread: Questions
about BitCoin
Hi Satoshi,
I sent you 32.51 coins, my bitcoin address is 1JuEjh9znXwqsy5RrnKqgzqY4Ldg7r
nj5n
My IP is currently 84.73.233.199, however, it's a laptop so may or may
not be online at the time you act on this mail. I suggest using the
bitcoin address instead. It'd be convenient if the same comment
functionality was available via indirect transfer. Can the comment be
encrypted using the public key of the receiver and placed into a
block?
[Quoted text hidden]
From: Satoshi Nakamoto Date: Sat,
Apr 18, 2009 at 6:16 PM To: Mike Hearn mike@plan99.netThread: Questions
about BitCoin
I sent back 32.51 and 50.00.
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.
[Quoted text hidden]
From: Mike Hearn Date: Sat, Apr 18,
2009 at 9:25 PM To: Satoshi Nakamoto satoshin@gmx.comThread: Questions
about BitCoin
Thanks. I sent you back 50, so now we're even.
For some reason your transfer to me shows up as "From: unknown" even
though I added you to my address book.
I have a "Generated (not accepted)" line in my transaction list, it
seems like an attempt to generate a coin went wrong somehow. Not sure
what happened here - presumably my node successfully solved a block
but then I went offline before it was sent to the network?
I suppose for sending metadata with a transaction some other mechanism
will be needed, for instance, broadcast of encrypted messages
associated with a transaction that persist for (say) a month, with
some kind of budget on how much storage a node can use for messages.
Alternatively, a payee could generate some reference number which is
of some significance to themselves but otherwise opaque, and give it
to the payer, thus it does not need to be encrypted and can be put
into the block directly.
[Quoted text hidden]
From: Satoshi Nakamoto Date: Sat,
Apr 18, 2009 at 10:52 PM To: Mike Hearn mike@plan99.netThread: Questions
about BitCoin
Got the 50.
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.
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.
[Quoted text hidden]
From: Mike Hearn Date: Sat, Apr 18,
2009 at 11:23 PM To: Satoshi Nakamoto satoshin@gmx.comThread: Questions
about BitCoin
Yes, I believe most P2P clients use the UPnP protocol to get routers
to open up the port automatically. That would probably improve the
listen rate significantly. I just discovered DMZ wasn't enabled on my
router, though I thought it was. That's now fixed.
Is there a way to be told of new versions? Does the app auto update
itself? Again, some kind of mailing list would be excellent.
I was thinking through how a practical micropayment implementation for
the web might work in the last few days. One key issue is ensuring
micropayments are fully automatic, yet can't be easily abused to drain
the users account. I think the right approach would be to allow any
website that presents an EV SSL cert to automatically request a
micropayment, by default the browser always accepts as long as the
charge is "low" and displays a small notification of what has
occurred. Sites can then show that content requires payment in any way
that suits their site design. Abusive sites that don't meet some
simple guidelines (eg, showing unambiguously that clicking a link will
trigger payment, or taking payment from direct search engine links)
would simply have their SSL cert blacklisted, much like anti-phishing
filters work today.
The protocol could be very straightforward and implemented by a
Firefox extension or an IE BHO. Some static file (eg, a protocol
buffer) is hosted on the site. It specifies the charge, a transaction
description, the target IP and a URL for the browser to load after the
transaction was accepted by the target node, to which the user
identifier is sent in a URL parameter. The site can then give back a
cookie and the paywalled content. The entire process is automatic and
simply results in, say, a little coin animation in the URL bar. Thus
it's as convenient as regular web browsing. The users software would
have some limit on what payments are automatically accepted.
The main problem with this approach is that somebody has to decide
what the user interface guidelines are, then enforce them via
blacklisting, as well as decide what payment requirements are low
enough to be automatic vs requiring a user prompt. This introduces a
trusted authority back into the system. However, it's one that the
user can choose in an open market.
By the way, if you're not already using protocol buffers for the
node-to-node traffic, I recommend them. We use them here at Google for
everything, they solve a lot of versioning problems simply and
efficiently.
From: Satoshi Nakamoto Date: Sun,
Apr 19, 2009 at 2:14 AM To: Mike Hearn mike@plan99.netThread: Questions
about BitCoin
The list is:
bitcoin-list@lists.sourceforge
.net
Subscribe/unsubscribe page:
http://lists.sourceforge.net/m
ailman/listinfo/bitcoin-list
Archives:
http://sourceforge.net/mailarc
hive/forum.php?forum_name=
bitcoin-list
I'll always announce new versions there. Automatic update, or at least notification of new versions, is definitely on the list. There could potentially be necessary changes in the future where nobody will want to talk to you until you upgrade, and there needs to be code in the older version to convey that to the user. This is all the harder in the context of not trusting anyone.
Your approach to micropayments sounds right. At first, it might be a good idea to default to asking permission until the user gets comfortable and is ready to set it to automatic. The end goal though should get to something like you describe, where it's similar to using your cell phone without really having to think about the per minute charges.
I looked at Google protocol buffers when they were released last year, but I had already written everything by then. What I did was something similar to Boost Serialisation. For this application, where I was parsing messages from strangers who might have extreme incentive to hack the protocol, it was necessary to make it as basic as possible so I could crawl over every line of code to convince myself it was airtight. It became clear that any unnecessary degrees of freedom in the binary format multiplied the potential angles of attack. You guys are so right though to standardize across the company on protocol buffers. I think you've got the optimal solution in the general case.
From: Mike Hearn Date: Sat, Apr 25,
2009 at 9:30 PM To: Satoshi Nakamoto satoshin@gmx.comThread: Lack of
chargeback support
Hi Satoshi,
I just read the following wiki page:
http://en.wikipedia.org/wiki/
Chargeback
which claims that "U.S. debit card holders are guaranteed reversal
rights by Federal Reserve Regulation E under the Electronic Funds
Transfer Act. Similar rights extend globally pursuant to the rules
established by the corresponding card association or bank network."
The "Electronic Funds Transfer Act" sounds awfully generic, do you
think it'd apply to BitCoin? If so, would the inability to do
chargebacks risk making it illegal?
Lack of chargeback support — reply 2
Mike Hearn correspondence (Satoshi Nakamoto) — April 27, 2009 — source: hearn-thread2.html#msg-2
From: Satoshi Nakamoto Date: Mon,
Apr 27, 2009 at 12:11 AM To: Mike Hearn mike@plan99.netThread: Lack of
chargeback support
I am not a lawyer and I can't possibly answer that. I suppose if the law applies to a bank or financial institution or other intermediary, then it would not apply since there is no bank involved, only two parties trading directly with each other, as they would in person with cash or barter with physical commodities.
Bitcoin is fundamentally designed to be able to do non-reversible transactions, and there certainly are applications that need that.
If someone wants the possibility of chargeback, they can use an escrow transaction, which isn't implemented yet but will be one of the next things. For instance, a transaction can be written to designate a third party to decide whether it is returned if the payer does not release it, with auto-release after a number of days. I'll implement a more basic form of escrow first, but the network infrastructure includes a predicate language that can express any number of options.
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.
Satoshi
Martti Malmi wrote:
> Message body follows:
>
> Hello,
>
> I'm Trickstern from the anti-state.com forum, and I would
> like to help with Bitcoin, if there's something I can do.
>
> I have a good touch on Java and C languages from school
> courses (I'm studying CS), but not so very much development
> experience yet. I think I could learn the C++ tricks quite
> easily on that basis. I could also do testing or
> documentation.
>
> Best regards,
> Martti Malmi
>
> --
> This message has been sent to you, a registered SourceForge.net user,
> by another site user, through the SourceForge.net site. This message
> has been delivered to your SourceForge.net mail alias. You may reply
> to this message using the "Reply" feature of your email client, or
> using the messaging facility of SourceForge.net at:
> https://sourceforge.net/sendmessage.php?touser=2495503
>
All right, I can do the website and the FAQ. I'll start writing the
FAQ now with the questions that I can think of.
I have a feature suggestion for the program: a UI tool for creating
password protected private keys and saving them into a custom
location. Backups of the key will be needed to be safe from losing the
control of your coins, and for using the coins on more than one
computers. Password protection would be needed to make using your
money more difficult for someone who happens to find your key file.
Maybe a bug/feature tracker could be set up at the Sourceforge project page?
I'm running a bitcoin node always when my PC is powered on, which
means about 24/7. Bitcoin is a great project, and it's really cool to
participate!
-Martti Malmi
Quoting Satoshi Nakamoto <satoshin@gmx.com>:
> 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.
>
> Satoshi
>
>
> Martti Malmi wrote:
>> Message body follows:
>>
>> Hello,
>>
>> I'm Trickstern from the anti-state.com forum, and I would like to
>> help with Bitcoin, if there's something I can do.
>>
>> I have a good touch on Java and C languages from school courses
>> (I'm studying CS), but not so very much development experience yet.
>> I think I could learn the C++ tricks quite easily on that basis. I
>> could also do testing or documentation.
>>
>> Best regards,
>> Martti Malmi
>>
>> --
>> This message has been sent to you, a registered SourceForge.net user,
>> by another site user, through the SourceForge.net site. This message
>> has been delivered to your SourceForge.net mail alias. You may reply
>> to this message using the "Reply" feature of your email client, or
>> using the messaging facility of SourceForge.net at:
>> https://sourceforge.net/sendmessage.php?touser=2495503
>>
mmalmi@cc.hut.fi wrote:
> All right, I can do the website and the FAQ. I'll start writing the FAQ
> now with the questions that I can think of.
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.
> I have a feature suggestion for the program: a UI tool for creating
> password protected private keys and saving them into a custom location.
> Backups of the key will be needed to be safe from losing the control of
> your coins, and for using the coins on more than one computers. Password
> protection would be needed to make using your money more difficult for
> someone who happens to find your key file.
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.
> I'm running a bitcoin node always when my PC is powered on, which means
> about 24/7. Bitcoin is a great project, and it's really cool to
> participate!
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.
**** QUESTION AND ANSWER DUMP ****
Any questions used for the FAQ should probably be rephrased.
questions:
> The bottom of the UI shows:
>
> Generating 4 connections 4024 blocks 164 transactions
>
> I understand "generating"; I assume I am connected to 4 other nodes; and
> I know I have recorded 164 transactions (including failed generation
> attempts). I'm not clear what the "blocks" figure describes. It's much
> smaller than the total of all the blocks shown against all my
transactions.
>
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.
Satoshi
> My best guess - it
> is the length of the global chain, and the rapid advance at the start
> is as the software downloads and verifies the preceding blocks in the
> chain as being valid.
Right. I'm trying to think of more clear wording for that, maybe "%d
network blocks" or "%d block chain".
> I'm having an unusual run of (block not-accepted) failures, and
thought I'd let you know in
> case this was of any significance.
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.
Satoshi
[note: I have some improvements in 0.1.6 to reduce this problem somewhat,
and it'll also improve when the network is larger]
> For some reason your transfer to me shows up as "From: unknown" even
> though I added you to my address book.
>
> I have a "Generated (not accepted)" line in my transaction list, it
> seems like an attempt to generate a coin went wrong somehow. Not sure
> what happened here - presumably my node successfully solved a block
> but then I went offline before it was sent to the network?
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.
> ...So far it has two "Generated" messages, however the
> "Credit" field for those is 0.00 and the balance hasn't changed. Is
> this due to the age/maturity requirement for a coin to be valid?
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.
> ...understand correctly, there is only one (or maybe a few) global
> chain[s] into which all transactions are hashed. If there is only one
> chain recording "the story of the economy" so to speak, how does this
> scale? In an imaginary planet-wide deployment there would be millions
> of even billions of transactions per hour being hashed into the chain...
> ...I found the section on incentives hard to follow. In particular, I'm
> not clear on what triggers the transition from minting new coins as a
> reason to run a node, to charging transaction fees (isn't the point of
> BitCoin largely to zero transaction costs anyway?). Presumably there's
> some human in charge of the system...
> ...How did you decide on the inflation schedule for v1? Where did 21
> million coins come from? What denominations are these coins? You
> mention a way to combine and split value but I'm not clear on how this
> works. For instance are bitcoins always denominated by an integer or
> can you have fractional bitcoins?...
> ...it's rare that I encounter truly
> revolutionary ideas. The last time I was this excited about a new
> monetary scheme was when I discovered Ripple. If you have any thoughts
> on Ripple, I'd also love to hear them.
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.
Satoshi
> If we assume that 0.1% is a good risk rate, then z=5 thus
> any transaction must wait a bit less than an hour before being
> solidified in the chain. As micropayments for things like web content
> or virtual goods are by definition something that requires low
> overhead, waiting an hour seems like quite a significant hurdle.
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.
> How is the required difficulty of each block communicated through the
> network and agreed upon?
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.
> Is the code free/open source or just open source?
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.
Satoshi
> Is there a way to be told of new versions? Does the app auto update
> itself? Some kind of mailing list would be excellent.
The list is:
bitcoin-list@lists.sourceforge.net
Subscribe/unsubscribe page:
http://lists.sourceforge.net/mailman/listinfo/bitcoin-list
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-list
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]
> Since they can be created for free (or at the cost
> of computer power people have anyway for other reasons),
> monetizing them means simply giving away money.
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.
> Why would they, when they make money by generating
> new ones
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.
Satoshi
> As more capable
> computer hardware comes out, the natural supply per user
> doubles at every cycle of Moore's law.
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.
> I do not recall any economic history of a commodity subject
> to natural inflation ever being used as money
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.
> Won't there be massive inflation as computers get faster and are able
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.
> If someone double spends, then the transaction record
> can be unblinded revealing the identity of the cheater?
Identities are not used, and there's no reliance on recourse. It's all
prevention.
> ...You're saying
> there's no effort to identify and exclude nodes that don't
> cooperate? I suspect this will lead to trouble and possible DOS
> attacks.
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.
> But in the absence of identity, there's no downside to them
> if spends become invalid, if they've already received the
> goods they double-spent for (access to website, download,
> whatever). The merchants are left holding the bag with
> "invalid" coins, unless they wait that magical "few blocks"
> (and how can they know how many?) before treating the spender
> as having paid.
>
> The consumers won't do this if they spend their coin and it takes
> an hour to clear before they can do what they spent their coin on.
> The merchants won't do it if there's no way to charge back a
> customer when they find the that their coin is invalid because
> the customer has doublespent.
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.
Satoshi
[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.
Satoshi
> One other question I had... What prevents the single node with the most
> CPU power from generating and retaining the majority of the BitCoins?
> If every node is working independently of all others, if one is
> significantly more powerful than the others, isn't it probable that this
> node will reach the proper conclusion before other nodes? An
> underpowered node may get lucky once in a while, but if they are at a
> significant horsepower advantage I would expect the majority of BitCoins
> to be generated by the most powerful node.
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
cd "%appdata%\bitcoin"
On XP it would typically be:
C:\Documents and Settings\[username]\Application Data\Bitcoin
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.
> > You know, I think there were a lot more people interested in the 90's,
> > but after more than a decade of failed Trusted Third Party based
systems
> > (Digicash, etc), they see it as a lost cause. I hope they can make the
> > distinction that this is the first time I know of that we're trying a
> > non-trust-based system.
>
> Yea, that was the primary feature that caught my eye. The real trick
> will be to get people to actually value the Bitcoins so that they become
> currency.
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.]
> Spammer botnets could burn through pay-per-send email filters
> trivially (as usual, the costs would fall on people other than the
> botnet herders & spammers).
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.
> > * Spammer botnets could burn through pay-per-send email filters
> > trivially
> If POW tokens do become useful, and especially if they become money,
> machines will no longer sit idle. Users will expect their computers to
> be earning them money (assuming the reward is greater than the cost to
> operate). A computer whose earnings are being stolen by a botnet will
> be more noticeable to its owner than is the case today, hence we might
> expect that in that world, users will work harder to maintain their
> computers and clean them of botnet infestations.
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.
> The last thing we need is to deploy a system designed to burn all
> available cycles, consuming electricity and generating carbon dioxide,
> all over the Internet, in order to produce small amounts of bitbux to
> get emails or spams through.
>
> Can't we just convert actual money in a bank account into bitbux --
> cheaply and without a carbon tax? Please?
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.
Satoshi
> BTW I don't remember if we talked about this, but the other day some
> people were mentioning secure timestamping. You want to be able to
> prove that a certain document existed at a certain time in the past.
> Seems to me that bitcoin's stack of blocks would be perfect for this.
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.
http://listcultures.org/pipermail/p2presearch_listcultures.org/2009-February/thread.html
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
http://www.bitcoin.org/bitcoin.pdf
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.
Satoshi Nakamoto
http://www.bitcoin.org
Martien van Steenbergen Martien at AardRock.COM
Thu Feb 12 08:40:53 CET 2009
Very interesting. Is this akin to David Chaum's anonymous digital
money? His concept makes sure money is anonymous unless it is
compromised, i.e. the same money spent more than once. As soon as it's
compromised, the ‘counterfeiter’ is immediately publicly exposed.
Also, in bitcoin, is there a limited supply of money (that must be
managed)? Or is money created exaclty at the moment of transaction?
Succes en plezier,
Martien.
Martien van Steenbergen wrote:
> Very interesting. Is this akin to David Chaum's anonymous digital money?
> His concept makes sure money is anonymous unless it is compromised, i.e.
> the same money spent more than once. As soon as it's compromised, the
> ‘counterfeiter’ is immediately publicly exposed.
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.
> Also, in bitcoin, is there a limited supply of money (that must be
> managed)? Or is money created exaclty at the moment of transaction?
There is a limited supply of money. Circulation will be 21,000,000
coins. Transactions only transfer ownership.
Thank you for your questions,
Satoshi
Martien van Steenbergen wrote:
> Reminds me of:
>
> * AardRock » Wizard Rabbit Treasurer
> <http://wiki.aardrock.com/Wizard_Rabbit_Treasurer>; and
> * AardRock » Pekunio <http://wiki.aardrock.com/Pekunio>
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.
> Are you familiar with Ripple?
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?"]
Michel Bauwens wrote:
> how operational is your project? how soon do you think people will be
> able to use it in real life?
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.)
http://www.mail-archive.com/cryptography@metzdowd.com/mail3.html
A little follow up when the software was released.
http://www.mail-archive.com/cryptography@metzdowd.com/mail2.html
My description of how Bitcoin solves the Byzantine Generals' problem:
http://www.bitcoin.org/byzantine.html
Quoting Satoshi Nakamoto <satoshin@gmx.com>:
> 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.
Oh, that's not me but another guy who wanted to help. I've seen him on
the Freedomain Radio forum. My name is Martti Malmi and my Sourceforge
account is sirius-m. No problem!
Thanks for your answered questions, I'll add them to the faq. Here's
what I've done so far:
**** Bitcoin FAQ ****
General Questions
1 What is bitcoin?
Bitcoin is a peer-to-peer network based anonymous digital
currency. Peer-to-peer (P2P) means that there is no central
authority to issue new money or to keep track of the
transactions. Instead, those tasks are managed collectively by
the nodes of the network. Anonymity means that the real world
identity of the parties of a transaction can be kept hidden from
the public or even from the parties themselves.
2 How does bitcoin work?
Bitcoin utilizes public/private key cryptography. When a coin is
transfered from user A to user B, A adds B's public key to the
coin and signs it with his own private key. Now B owns the coin
and can transfer it further. To prevent A from transfering the
already used coin to another user C, a public list of all the
previous transactions is collectively maintained by the network
of bitcoin nodes, and before each transaction the coin's
unusedness will be checked.
For details, see chapter Advanced Questions.
3 What is bitcoin's value backed by?
Bitcoin is valued for the things it can be exchanged to, just
like all the traditional paper currencies are.
When the first user publicly announces that he will make a pizza
for anyone who gives him a hundred bitcoins, then he can use
bitcoins as payment to some extent - as much as people want pizza
and trust his announcement. A pizza-eating hairdresser who trusts
him as a friend might then announce that she starts accepting
bitcoins as payment for fancy haircuts, and the value of the
bitcoin would be higher - now you could buy pizzas and haircuts
with them. When bitcoins have become accepted widely enough, he
could retire from his pizza business and still be able to use his
bitcoin-savings.
4 How are new bitcoins created?
New coins are generated by a network node each time it finds the
solution to a certain calculational problem. In the first 4 years
of the bitcoin network, amount X of coins will be created. The
amount is halved each 4 years, so it will be X/2 after 4 years,
X/4 after 8 years and so on. Thus the total number of coins will
approach 2X.
5 Is bitcoin safe?
Yes, as long as you make backups of your coin keys, protect them
with strong passwords and keep keyloggers away from your
computer. If you lose your key or if some unknown attacker
manages to unlock it, there's no way to get your coins back. If
you have a large amount of coins, it is recommended to distribute
them under several keys. You propably wouldn't either keep all
your dollars or euros as paper in a single wallet and leave it
unguarded.
6 Why should I use bitcoin?
• Transfer money easily through the internet, without having to
trust third parties.
• Third parties can't prevent or control your transactions.
• Be safe from the unfair monetary policies of the monopolistic
central banks and the other risks of centralized power over a
money supply. The limited inflation of the bitcoin system's
money supply is distributed evenly (by CPU power) throughout
the network, not monopolized to a banking elite.
• Bitcoin's value is likely to increase as the growth of the
bitcoin economy exceeds the inflation rate - consider bitcoin
an investment and start running a node today!
7 Where can I get bitcoins?
Find a bitcoin owner and sell her something - MMORPG equipement,
IT support, lawn mowing, dollars or whatever you can trade with
her. You can also generate new bitcoins for yourself by running a
bitcoin network node.
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.
mmalmi@cc.hut.fi wrote:
> Quoting Satoshi Nakamoto <satoshin@gmx.com>:
>
>> 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.
>
> Oh, that's not me but another guy who wanted to help. I've seen him on
> the Freedomain Radio forum. My name is Martti Malmi and my Sourceforge
> account is sirius-m. No problem!
>
> Thanks for your answered questions, I'll add them to the faq. Here's
> what I've done so far:
>
> **** Bitcoin FAQ ****
>
> General Questions
>
> 1 What is bitcoin?
>
> Bitcoin is a peer-to-peer network based anonymous digital
> currency. Peer-to-peer (P2P) means that there is no central
> authority to issue new money or to keep track of the
> transactions. Instead, those tasks are managed collectively by
> the nodes of the network. Anonymity means that the real world
> identity of the parties of a transaction can be kept hidden from
> the public or even from the parties themselves.
>
> 2 How does bitcoin work?
>
> Bitcoin utilizes public/private key cryptography. When a coin is
> transfered from user A to user B, A adds B's public key to the
> coin and signs it with his own private key. Now B owns the coin
> and can transfer it further. To prevent A from transfering the
> already used coin to another user C, a public list of all the
> previous transactions is collectively maintained by the network
> of bitcoin nodes, and before each transaction the coin's
> unusedness will be checked.
>
> For details, see chapter Advanced Questions.
>
> 3 What is bitcoin's value backed by?
>
> Bitcoin is valued for the things it can be exchanged to, just
> like all the traditional paper currencies are.
>
> When the first user publicly announces that he will make a pizza
> for anyone who gives him a hundred bitcoins, then he can use
> bitcoins as payment to some extent - as much as people want pizza
> and trust his announcement. A pizza-eating hairdresser who trusts
> him as a friend might then announce that she starts accepting
> bitcoins as payment for fancy haircuts, and the value of the
> bitcoin would be higher - now you could buy pizzas and haircuts
> with them. When bitcoins have become accepted widely enough, he
> could retire from his pizza business and still be able to use his
> bitcoin-savings.
>
> 4 How are new bitcoins created?
>
> New coins are generated by a network node each time it finds the
> solution to a certain calculational problem. In the first 4 years
> of the bitcoin network, amount X of coins will be created. The
> amount is halved each 4 years, so it will be X/2 after 4 years,
> X/4 after 8 years and so on. Thus the total number of coins will
> approach 2X.
>
> 5 Is bitcoin safe?
>
> Yes, as long as you make backups of your coin keys, protect them
> with strong passwords and keep keyloggers away from your
> computer. If you lose your key or if some unknown attacker
> manages to unlock it, there's no way to get your coins back. If
> you have a large amount of coins, it is recommended to distribute
> them under several keys. You propably wouldn't either keep all
> your dollars or euros as paper in a single wallet and leave it
> unguarded.
>
> 6 Why should I use bitcoin?
>
> • Transfer money easily through the internet, without having to
> trust third parties.
>
> • Third parties can't prevent or control your transactions.
>
> • Be safe from the unfair monetary policies of the monopolistic
> central banks and the other risks of centralized power over a
> money supply. The limited inflation of the bitcoin system's
> money supply is distributed evenly (by CPU power) throughout
> the network, not monopolized to a banking elite.
>
> • Bitcoin's value is likely to increase as the growth of the
> bitcoin economy exceeds the inflation rate - consider bitcoin
> an investment and start running a node today!
>
> 7 Where can I get bitcoins?
>
> Find a bitcoin owner and sell her something - MMORPG equipement,
> IT support, lawn mowing, dollars or whatever you can trade with
> her. You can also generate new bitcoins for yourself by running a
> bitcoin network node.
>
Quoting Satoshi Nakamoto <satoshin@gmx.com>:
> 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.
Ok. Could you set the project MySQL database passwords so that I can
set up a CMS on the site? I was thinking about WordPress, as it seems
simple and well maintained. I need a password for the read/write
account and one database (or the database admin pass to create it
myself). This can be done somewhere in the project admin pages, I think.
> 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.
Ok, that's good to know.
> 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.
Well, I guess that's true after all.
Quoting mmalmi@cc.hut.fi:
>> 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.
>
> Well, I guess that's true after all.
...the difference being, though, that not everyone can easily transfer
their regular bank money into an uncontrollable location. In bitcoin
anyone can do it.
mmalmi@cc.hut.fi wrote:
>> 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.
>
> Ok. Could you set the project MySQL database passwords so that I can set
> up a CMS on the site? I was thinking about WordPress, as it seems simple
> and well maintained. I need a password for the read/write account and
> one database (or the database admin pass to create it myself). This can
> be done somewhere in the project admin pages, I think.
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.
https://apps.sourceforge.net/wordpress/bitcoin/wp-admin/
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
https://apps.sourceforge.net/admin/Bitcoin
# Documentation: Guide to MySQL Database Services
http://p.sf.net/sourceforge/mysql
# Hostname: mysql-b (exactly as shown, with no domain suffix)
# Database name prefix: b244765_ -- i.e. "CREATE DATABASE b244765_myapp"
as your ADMIN user.
# RO user: b244765ro (SELECT)
# RW user: b244765rw (SELECT, INSERT, DELETE, UPDATE)
# ADMIN user: b244765admin (has RW account privileges, and CREATE, DROP,
ALTER, INDEX, LOCK TABLES)
# web-access URL: https://mysql-b.sourceforge.net/
passwords:
b244765ro EaG3nHLL
b244765rw sNKgyt4W
b244765admin Mz589ZKf
> ...the difference being, though, that not everyone can easily
> transfer their regular bank money into an uncontrollable location. In
> bitcoin anyone can do it.
That's true.
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.
Quoting Satoshi Nakamoto <satoshin@gmx.com>:
> They have Wordpress built in, you might not need to set up any database
> stuff manually.
>
> They also have support for MediaWiki if you want it.
The built-in Wordpress comes with ads, and new plugins and themes need
to be installed by the Sourceforge staff, so I installed Wordpress at
http://bitcoin.sourceforge.net/. The admin page is at .../wp-admin/,
with admin/Wubreches3eS as login. If there's something to add or
change, feel free to.
The current layout is just a quickly applied free theme, but I'll see
if I can do something more visual myself.
The MediaWiki might be quite useful for maintaining the FAQ, which
could be retrieved from there to the main site somehow. The wiki says
I need to be an editor or admin to create a new page, which is funny,
because
https://apps.sourceforge.net/mediawiki/bitcoin/index.php?title=Special:ListGroupRights says that users can create
pages.
Lainaus mmalmi@cc.hut.fi:
> The current layout is just a quickly applied free theme, but I'll see
> if I can do something more visual myself.
And of course I'll continue improving the contents also.
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:
User list
* S nakamoto <- it thinks I'm this one
* S nakamoto (admin, editor)
* Sirius-m
I tried deleting and re-enabling the feature, no help. Oh well.
mmalmi@cc.hut.fi wrote:
> Quoting Satoshi Nakamoto <satoshin@gmx.com>:
>
>> They have Wordpress built in, you might not need to set up any database
>> stuff manually.
>>
>> They also have support for MediaWiki if you want it.
>
> The built-in Wordpress comes with ads, and new plugins and themes need
> to be installed by the Sourceforge staff, so I installed Wordpress at
> http://bitcoin.sourceforge.net/. The admin page is at .../wp-admin/,
> with admin/Wubreches3eS as login. If there's something to add or change,
> feel free to.
>
> The current layout is just a quickly applied free theme, but I'll see if
> I can do something more visual myself.
>
> The MediaWiki might be quite useful for maintaining the FAQ, which could
> be retrieved from there to the main site somehow. The wiki says I need
> to be an editor or admin to create a new page, which is funny, because
> https://apps.sourceforge.net/mediawiki/bitcoin/index.php?title=Special:ListGroupRights
> says that users can create pages.
Quoting Satoshi Nakamoto <satoshin@gmx.com>:
> 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:
> User list
> * S nakamoto <- it thinks I'm this one
> * S nakamoto (admin, editor)
> * Sirius-m
>
> I tried deleting and re-enabling the feature, no help. Oh well.
I think this has something to do with the underscore character in your
username; MediaWiki handles them as spaces. I could ask SF Support
about this.
Quoting mmalmi@cc.hut.fi:
> Quoting Satoshi Nakamoto <satoshin@gmx.com>:
>
>> 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:
>> User list
>> * S nakamoto <- it thinks I'm this one
>> * S nakamoto (admin, editor)
>> * Sirius-m
>>
>> I tried deleting and re-enabling the feature, no help. Oh well.
>
> I think this has something to do with the underscore character in your
> username; MediaWiki handles them as spaces. I could ask SF Support
> about this.
Or could you control the MediaWiki with your account nakamoto2?
Quoting mmalmi@cc.hut.fi:
> Quoting mmalmi@cc.hut.fi:
>
>> Quoting Satoshi Nakamoto <satoshin@gmx.com>:
>>
>>> 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:
>>> User list
>>> * S nakamoto <- it thinks I'm this one
>>> * S nakamoto (admin, editor)
>>> * Sirius-m
>>>
>>> I tried deleting and re-enabling the feature, no help. Oh well.
>>
>> I think this has something to do with the underscore character in your
>> username; MediaWiki handles them as spaces. I could ask SF Support
>> about this.
>
> Or could you control the MediaWiki with your account nakamoto2?
Oh, sorry for spamming with emails, but the problem is indeed with the
underscore character:
http://apps.sourceforge.net/trac/sourceforge/ticket/300
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.
mmalmi@cc.hut.fi wrote:
> Quoting mmalmi@cc.hut.fi:
>
>> Quoting mmalmi@cc.hut.fi:
>>
>>> Quoting Satoshi Nakamoto <satoshin@gmx.com>:
>>>
>>>> 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:
>>>> User list
>>>> * S nakamoto <- it thinks I'm this one
>>>> * S nakamoto (admin, editor)
>>>> * Sirius-m
>>>>
>>>> I tried deleting and re-enabling the feature, no help. Oh well.
>>>
>>> I think this has something to do with the underscore character in your
>>> username; MediaWiki handles them as spaces. I could ask SF Support
>>> about this.
>>
>> Or could you control the MediaWiki with your account nakamoto2?
>
> Oh, sorry for spamming with emails, but the problem is indeed with the
> underscore character:
> http://apps.sourceforge.net/trac/sourceforge/ticket/300
>
> 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 user group privileges seemingly can't be changed without changing
the wiki source files, which can only be done by the SF admins as a
hosted app is concerned. The hosted apps are also otherwise quite
inflexible: you can only login with a SF account, you can't change
themes by yourself and of course there's the ad-bar above the pages.
I think that replacing the current Wordpress installation at
bitcoin.sourceforge.net with TikiWiki could be a great solution.
TikiWiki supports CMS features, forums, wikis, bug trackers, and many
other features also if needed. Perhaps the best looking example of a
TikiWiki installation is at http://support.mozilla.com/.
I'll take backup of the current site and see if TikiWiki can be
installed at SF. If it doesn't work, I'll see how wiki/forum features
can be integrated with Wordpress or think of something else.
I couldn't get TikiWiki to work, so I installed Bitweaver, which is a
lightweight TikiWiki derivative. Its functionality looks good for the
purpose and it's easy to customize.
The admin account password is Wubreches3eS again. New users can
register to the site and write to the wiki and the forums. Next I'm
going to look into how custom menus and custom layouts are made.
Now that the project web is up and running, do you think that setting
up a custom VHOST for the bitcoin.org domain would be a good idea?
Instructions:
http://apps.sourceforge.net/trac/sourceforge/wiki/Custom%20VHOSTs
Also, could you please send me a link to a SF Logo for statistics, as
instructed at:
http://apps.sourceforge.net/trac/sourceforge/wiki/Use%20of%20sflogo%20for%20statistics%20tracking
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.
mmalmi@cc.hut.fi wrote:
> Now that the project web is up and running, do you think that setting up
> a custom VHOST for the bitcoin.org domain would be a good idea?
> Instructions:
> http://apps.sourceforge.net/trac/sourceforge/wiki/Custom%20VHOSTs
>
> Also, could you please send me a link to a SF Logo for statistics, as
> instructed at:
> http://apps.sourceforge.net/trac/sourceforge/wiki/Use%20of%20sflogo%20for%20statistics%20tracking
>
>
> 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.
I made the changes. You could also register to the site or use the
admin account to make necessary changes yourself, since the pages are
located in the wiki.
> Someone came up with the word "cryptocurrency"... maybe it's a word we
> should use when describing Bitcoin, do you like it?
It sounds good. "The P2P Cryptocurrency" could be considered as the
slogan, even if it's a bit more difficult to say than "The Digital P2P
Cash". It still describes the system better and sounds more
interesting, I think.
I could notify the mailing list about the new site and invite them to
write on the forums and to the wiki.
mmalmi@cc.hut.fi wrote:
> I made the changes. You could also register to the site or use the admin
> account to make necessary changes yourself, since the pages are located
> in the wiki.
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)
> 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)
Problem fixed. I switched to a fixed width layout, which is also
easier to read as the lines are shorter.
Hi,
I made a post on the Bitcoin developer's forum at SF about a month ago
and sent you, David and Hal a notification about it to your
users.sourceforge.net emails. A few days ago I wondered why no one had
replied, and tried if the SF mail aliases even work - and they didn't,
at least in the case of my account. So could you please forward this
message to the others?
Best regards,
sirius-m
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.
mmalmi@cc.hut.fi wrote:
> Hi,
>
> I made a post on the Bitcoin developer's forum at SF about a month ago
> and sent you, David and Hal a notification about it to your
> users.sourceforge.net emails. A few days ago I wondered why no one had
> replied, and tried if the SF mail aliases even work - and they didn't,
> at least in the case of my account. So could you please forward this
> message to the others?
>
> Best regards,
> sirius-m
>
> 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
That's strange, I haven't had any problems with that. Clearly the
banking establishment got scared and banned your account (and founded
www.bitcoin.com in attempt to fetch the trademark), eh. You could ask
if the SF staff at sfnet_ops@corp.sourceforge.com can help you.
> 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.
Oh, that sounds tough. Take your time.
> It would help if there was something for people to use it for. We need
> an application to bootstrap it. Any ideas?
I've been thinking about a currency exchange service that sells and
buys bitcoins for euros and other currencies. Direct exchangeability
to an existing currency would give bitcoin the best possible initial
liquidity and thus the best adoptability for new users. Everyone
accepts payment in coins that are easily exchangeable for common
money, but not everyone accepts payment in coins that are only
guaranteed to buy a specific kind of a product.
The instructional formula for stable pricing in euros would be something like:
(The amount of euros that you're ready to trade for bc + the
euro-value of goods that other people are selling for bc) /
(Total number of bc in circulation - own bc assets).
So if there's a total of 1M bitcoins of which you own 100K, you have
1000 eur and no one else trades with bitcoin yet, you can safely offer the
exchange rate of 1 eur / 900 bc, without having to devaluate
even if everyone sold their coins to you. This could be guaranteed as
the minimal exchange rate, but the rate could be also higher when
demand is high.
Initially, when others aren't yet offering anything for bitcoins, you
can increase your bitcoin assets cheaply - for the minimum price that
people bother to do the transaction for. If you had all the existing
coins for yourself, you could set the price to whatever you want,
because you wouldn't face the risk of having to buy even a single coin
with that price (not counting the new money created by others). So
it's best to get as much coins as possible before backing bitcoin with
all your available euros.
Profit can be gained, as usually in trading, by having a margin
between the buying and selling prices. Making Bitcoin as usable as
possible will make the business run better, as people do not only want
to sell all their coins to you, but also want to buy them and use them
as a medium of exchange.
At its simplest this exchange service could be a website where
traders, who can be individual persons, can post their rates, and
random users can leave trade requests. Some kind of an average rate
estimate could be shown on the site. Small-scale trading by
individuals would be outside legal hassle in most countries, and
putting all the eggs in the same basket would be avoided.
Another idea, which could be additional to the previous one, would be
an automated exchange service. The service would automatically
calculate the exchange rate and perform the transactions. This would
be nicer to the user: completion of the transaction request would be
certain and instantaneous. Making this service might actually be quite
easy if there was a command line interface to Bitcoin: just take any
web application framework and use PayPal back-end integration to
automatically send euros when Bitcoins are received, and vice versa.
This kind of business would also work great on larger scale if you set
up a company and take care of all the bureaucracy needed to practice
currency exchange. (I actually have a registered company that I've
used for billing of some IT work, I could use that as a base.)
This exchange business thing is something that I'd be interested in
doing, and I also have the sufficient technical skills to do it.
Although, before this can be done, there should be a non-alpha version
of Bitcoin (and the command line interface / API).
> 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.
If this gets started, donors / high-risk investors would be very
welcome to bring capital for the currency's backup.
So, what do you think about the idea? Note that this is not something
that I'm asking you to do (unless you want to) if you're busy with
other things. I can do it myself, if I get positive reviews about the
plan.
I've had quite a few errors coming up when trying to build the
third-party libraries and adding them to the Bitcoin build. Do you
happen to have a ready-to-build package that you could upload to the
CVS or somewhere else? I use mingw + msys, but I guess I could try
Visual C++ also, if it's easier that way.
I got it compile with MinGW + MSYS when I used wxPack instead of just
wxWidgets. Maybe wxAdditions was required. The bitcoin.exe filesize
was 52MB though, I should see how that can be fixed.
Next I'm going to implement the "minimize to tray" feature and the
option to autostart Bitcoin with Windows, so the number of nodes
online would stay higher. After that I could see if I can do a Linux
port or the command line interface needed for web app frameworks.
Drop by at #bitcoin-dev on FreeNode some time if you use IRC.
And again, thanks for the great work you've done with Bitcoin.
Quote mmalmi@cc.hut.fi:
> I've had quite a few errors coming up when trying to build the
> third-party libraries and adding them to the Bitcoin build. Do you
> happen to have a ready-to-build package that you could upload to the
> CVS or somewhere else? I use mingw + msys, but I guess I could try
> Visual C++ also, if it's easier that way.
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.
>> It would help if there was something for people to use it for. We need
>> an application to bootstrap it. Any ideas?
>
> I've been thinking about a currency exchange service that sells and
> buys bitcoins for euros and other currencies. Direct exchangeability
> to an existing currency would give bitcoin the best possible initial
> liquidity and thus the best adoptability for new users. Everyone
> accepts payment in coins that are easily exchangeable for common
> money, but not everyone accepts payment in coins that are only
> guaranteed to buy a specific kind of a product.
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.
> At its simplest this exchange service could be a website where
> traders, who can be individual persons, can post their rates, and
> random users can leave trade requests. Some kind of an average rate
> estimate could be shown on the site. Small-scale trading by
> individuals would be outside legal hassle in most countries, and
> putting all the eggs in the same basket would be avoided.
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.
> Another idea, which could be additional to the previous one, would be
> an automated exchange service. The service would automatically
> calculate the exchange rate and perform the transactions. This would
> be nicer to the user: completion of the transaction request would be
> certain and instantaneous. Making this service might actually be quite
> easy if there was a command line interface to Bitcoin: just take any
> web application framework and use PayPal back-end integration to
> automatically send euros when Bitcoins are received, and vice versa.
> This kind of business would also work great on larger scale if you set
> up a company and take care of all the bureaucracy needed to practice
> currency exchange. (I actually have a registered company that I've
> used for billing of some IT work, I could use that as a base.)
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.
> This exchange business thing is something that I'd be interested in
> doing, and I also have the sufficient technical skills to do it.
> Although, before this can be done, there should be a non-alpha version
> of Bitcoin (and the command line interface / API).
>
> If this gets started, donors / high-risk investors would be very
> welcome to bring capital for the currency's backup.
>
> So, what do you think about the idea? Note that this is not something
> that I'm asking you to do (unless you want to) if you're busy with
> other things. I can do it myself, if I get positive reviews about the
> plan.
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.
mmalmi@cc.hut.fi wrote:
> I got it compile with MinGW + MSYS when I used wxPack instead of just
> wxWidgets. Maybe wxAdditions was required. The bitcoin.exe filesize was
> 52MB though, I should see how that can be fixed.
>
> Next I'm going to implement the "minimize to tray" feature and the
> option to autostart Bitcoin with Windows, so the number of nodes online
> would stay higher. After that I could see if I can do a Linux port or
> the command line interface needed for web app frameworks.
>
> Drop by at #bitcoin-dev on FreeNode some time if you use IRC.
>
> And again, thanks for the great work you've done with Bitcoin.
>
> Quote mmalmi@cc.hut.fi:
>
>> I've had quite a few errors coming up when trying to build the
>> third-party libraries and adding them to the Bitcoin build. Do you
>> happen to have a ready-to-build package that you could upload to the
>> CVS or somewhere else? I use mingw + msys, but I guess I could try
>> Visual C++ also, if it's easier that way.
>
>
>
> 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.
That might be a good idea.
> 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.
Bitcoin could be promoted to the users of virtual communities like
World of Warcraft and Second Life, which both have millions of users.
It would be great if not only peer-to-peer item traders, but also
providers of some existing virtual services that already have a lot of
customers, were to adopt the currency early on.
A programming question: What do you think about using the Boost's
program_options to write settings like the transaction fee into a file
bitcoin.config? Or is it better to save them in the database as it is
now? Having a config file would make it easier to change the settings
when running the program on a remote server with a console access only.
> Next I'm going to implement the "minimize to tray" feature and the
> option to autostart Bitcoin with Windows, so the number of nodes online
> would stay higher.
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.
Just for information: I committed my working copy to the svn/branches.
There's the minimize to tray feature and some other changes. It's
nicer to run in the background now, but it's still incomplete and I'm
working on it. The bugs are listed in bugs.txt.
Did you get your Sourceforge account work yet?
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.
mmalmi@cc.hut.fi wrote:
> Just for information: I committed my working copy to the svn/branches.
> There's the minimize to tray feature and some other changes. It's nicer
> to run in the background now, but it's still incomplete and I'm working
> on it. The bugs are listed in bugs.txt.
>
> Did you get your Sourceforge account work yet?
>
I made a Windows installer for the latest version of Bitcoin, which
includes the autostart and minimize to tray features. The installer
makes a start menu shortcut and a startup registry entry. I first
implemented the autostart with a shortcut to the startup folder, but I
found out that it doesn't always work by default and ended up doing it
with a registry entry. The registry entry is removed by the
uninstaller and can be also disabled from the options menu, so I don't
think it's such a big menace to the user after all.
I made the installer with NSIS, and the nsi script can be found in the SVN.
Could you add the installer to the SF download page? Here's the file:
http://bitcoin.sourceforge.net/uploads/Bitcoin_setup.exe
There are some new users registered to the bitcoin.sf.net site. One of
them just announced that he's trading Bitcoins for dollars. Here's his
site: http://newlibertystandard.wetpaint.com/. Making an exchange
service first seemed a bit premature for the time being, but on the
other hand it's good that people show interest towards the project,
and this might attract even more interested people (and hopefully more
developers). I just sent the guy an email.
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.
mmalmi@cc.hut.fi wrote:
> I made a Windows installer for the latest version of Bitcoin, which
> includes the autostart and minimize to tray features. The installer
> makes a start menu shortcut and a startup registry entry. I first
> implemented the autostart with a shortcut to the startup folder, but I
> found out that it doesn't always work by default and ended up doing it
> with a registry entry. The registry entry is removed by the uninstaller
> and can be also disabled from the options menu, so I don't think it's
> such a big menace to the user after all.
>
> I made the installer with NSIS, and the nsi script can be found in the SVN.
>
> Could you add the installer to the SF download page? Here's the file:
> http://bitcoin.sourceforge.net/uploads/Bitcoin_setup.exe
>
> There are some new users registered to the bitcoin.sf.net site. One of
> them just announced that he's trading Bitcoins for dollars. Here's his
> site: http://newlibertystandard.wetpaint.com/. Making an exchange
> service first seemed a bit premature for the time being, but on the
> other hand it's good that people show interest towards the project, and
> this might attract even more interested people (and hopefully more
> developers). I just sent the guy an email.
>
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Sun, 18 Oct
2009 18:59:42 +0100 Subject: Re: Setup, Autorun,
v0.1.6
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?
Satoshi Nakamoto wrote:
> 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.
>
> mmalmi@cc.hut.fi wrote:
>> I made a Windows installer for the latest version of Bitcoin, which
>> includes the autostart and minimize to tray features. The installer
>> makes a start menu shortcut and a startup registry entry. I first
>> implemented the autostart with a shortcut to the startup folder, but I
>> found out that it doesn't always work by default and ended up doing it
>> with a registry entry. The registry entry is removed by the
>> uninstaller and can be also disabled from the options menu, so I don't
>> think it's such a big menace to the user after all.
Well, the code worked and made a shortcut in the startup folder. For
some reason it didn't automatically start when booting, but worked
fine when you clicked on it in the menu. Now I tried making a shortcut
manually, and this time it works on autostart, don't know why. I could
try again with the older code.
> 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?
>
> Satoshi Nakamoto wrote:
>> 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.
>>
>> mmalmi@cc.hut.fi wrote:
>>> I made a Windows installer for the latest version of Bitcoin,
>>> which includes the autostart and minimize to tray features. The
>>> installer makes a start menu shortcut and a startup registry
>>> entry. I first implemented the autostart with a shortcut to the
>>> startup folder, but I found out that it doesn't always work by
>>> default and ended up doing it with a registry entry. The registry
>>> entry is removed by the uninstaller and can be also disabled from
>>> the options menu, so I don't think it's such a big menace to the
>>> user after all.
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.
mmalmi@cc.hut.fi wrote:
> Well, the code worked and made a shortcut in the startup folder. For
> some reason it didn't automatically start when booting, but worked fine
> when you clicked on it in the menu. Now I tried making a shortcut
> manually, and this time it works on autostart, don't know why. I could
> try again with the older code.
>
>> 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?
>>
>> Satoshi Nakamoto wrote:
>>> 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.
>>>
>>> mmalmi@cc.hut.fi wrote:
>>>> I made a Windows installer for the latest version of Bitcoin,
>>>> which includes the autostart and minimize to tray features. The
>>>> installer makes a start menu shortcut and a startup registry
>>>> entry. I first implemented the autostart with a shortcut to the
>>>> startup folder, but I found out that it doesn't always work by
>>>> default and ended up doing it with a registry entry. The registry
>>>> entry is removed by the uninstaller and can be also disabled from
>>>> the options menu, so I don't think it's such a big menace to the
>>>> user after all.
>
>
>
>
> 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.
I'm using XP. I recompiled the older revision and this time the
startup shortcut works. It also works when testing on Vista
(non-admin). Maybe I just missed something the previous time.
> 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.
Here it's the other way around, I have all my startup programs in the
registry. But maybe the shortcut method is nicer for the user, if it
works just as well
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.
mmalmi@cc.hut.fi wrote:
>> 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.
>
> I'm using XP. I recompiled the older revision and this time the startup
> shortcut works. It also works when testing on Vista (non-admin). Maybe I
> just missed something the previous time.
>
>> 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.
>
> Here it's the other way around, I have all my startup programs in the
> registry. But maybe the shortcut method is nicer for the user, if it
> works just as well
>
[bitcoin-list] Does Bitcoin Crash in Windows?
bitcoin-list Mailing List (Liberty Standard) — October 23, 2009 — source: sni-emails.json#email-54
Do you Windows users experience occasional Bitcoin crashes?
Lately Bitcoin running in wine-1.0.1 has been crashing frequently. I was
just wondering whether this is a Wine issue or a Bitcoin issue. I speculate
it might have something to do with how many Bitcoins I have since it would
crash less when I had less bitcoins and now crashes more now that I have
more bitcoins. It makes me hesitant to send my balance of bitcoins to my
fresh Bitcoin installation. But this might just be my imagination since it
has crashed a few times after installing Bitcoin afresh.
The following four lines print from the terminal when I start Bitcoin.
fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
fixme:toolhelp:Heap32ListFirst : stub
fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
fixme:toolhelp:Heap32ListFirst : stub
I previously wasn't starting Bitcoin from the terminal, so I don't know what
gets printed out when it crashes, but I'll reply with the results the next
time it crashes.
While Bitcoin first downloads previously completed blocks, the file
debug.log grows grows to 17.4 MB and then stops growing. I imagine it will
continue to grow as more bitcoins are completed.
~NewLibertyStandard~
From: Satoshi Nakamoto satoshin@gmx.comTo: Liberty Standard newlibertystandard@gmail.comDate:
Sat, 24 Oct 2009 00:55:06 +0100 Subject: Re:
[bitcoin-list] Does Bitcoin Crash in Windows?
Liberty Standard wrote:
> Do you Windows users experience occasional Bitcoin crashes?
> Lately Bitcoin running in wine-1.0.1 has been crashing frequently. I was
> just wondering whether this is a Wine issue or a Bitcoin issue.
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.
> The following four lines print from the terminal when I start Bitcoin.
> fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
> fixme:toolhelp:Heap32ListFirst : stub
> fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
> fixme:toolhelp:Heap32ListFirst : stub
Those don't look like anything to worry about. Probably functions
unimplemented by Wine that are harmlessly stubbed out.
> I previously wasn't starting Bitcoin from the terminal, so I don't know what
> gets printed out when it crashes, but I'll reply with the results the next
> time it crashes.
>
> While Bitcoin first downloads previously completed blocks, the file
> debug.log grows grows to 17.4 MB and then stops growing. I imagine it will
> continue to grow as more bitcoins are completed.
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.
Satoshi
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
bitcoin-list mailing list
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list
Re: [bitcoin-list] Does Bitcoin Crash in Windows?
bitcoin-list Mailing List (Mike Hearn) — October 24, 2009 — source: sni-emails.json#email-56
>
>
> The following four lines print from the terminal when I start Bitcoin.
> fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
> fixme:toolhelp:Heap32ListFirst : stub
> fixme:toolhelp:CreateToolhelp32Snapshot Unimplemented: heap list snapshot
> fixme:toolhelp:Heap32ListFirst : stub
>
That just means it failed to create a minidump, so yeah, not the cause of
the crash.
To find the cause of the crash you'd need to run it with a +seh,+relay trace
and find out what the app was doing before it crashed, or look in the
bitcoin logs.
Re: [bitcoin-list] Does Bitcoin Crash in Windows?
bitcoin-list Mailing List (Eugen Leitl) — October 26, 2009 — source: sni-emails.json#email-57
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Mon, 26 Oct
2009 17:50:10 +0000 Subject: Fw:
bitcoin.sourceforge.net
Any idea what's going on with it? Every time I look, it's fine.
Eugen Leitl wrote:
On Sat, Oct 24, 2009 at 12:55:06AM +0100, Satoshi Nakamoto wrote:
> > bitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing
Doesn't work right now.
> > some maintenance.
Liberty Standard wrote:
> In case you weren't aware, the Bitcoin website is down.
>
> http://bitcoin.sourceforge.net/
>
> -----
> You are running bitweaver in TEST mode
>
> * Click here to log a bug, if this appears to be an error with the
> application.
> * Go here to begin the installation process, if you haven't done so
> already.
> * To hide this message, please set the IS_LIVE constant to TRUE
in your
> kernel/config_inc.php file.
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.
mmalmi@cc.hut.fi wrote:
> IS_LIVE option was indeed set to false, but it only affects the
> visibility of error messages to user. I've noticed the site being slow
> at times, sometimes taking up to 30 seconds to load. I think it's
> related to the Sourceforge hosting. Bitweaver should be among the
> lightest PHP CMS'es, but I can check out if there are any issues to it.
>
> Off the topic, do you think that we could use Boost's thread and socket
> libraries instead of the Windows-specific ones? Are there other
> windows-only-functions used in the code?
>
>> Any idea what's going on with it? Every time I look, it's fine.
>>
>>
>> Eugen Leitl wrote:
>> On Sat, Oct 24, 2009 at 12:55:06AM +0100, Satoshi Nakamoto wrote:
>>> > bitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing
>>
>> Doesn't work right now.
>>
>>> > some maintenance.
>>
>>
>> Liberty Standard wrote:
>>> In case you weren't aware, the Bitcoin website is down.
>>>
>>> http://bitcoin.sourceforge.net/
>>>
>>> -----
>>> You are running bitweaver in TEST mode
>>>
>>> * Click here to log a bug, if this appears to be an error with the
>>> application.
>>> * Go here to begin the installation process, if you haven't done so
>>> already.
>>> * To hide this message, please set the IS_LIVE constant to TRUE
>>> in your
>>> kernel/config_inc.php file.
>
>
>
IS_LIVE option was indeed set to false, but it only affects the
visibility of error messages to user. I've noticed the site being slow
at times, sometimes taking up to 30 seconds to load. I think it's
related to the Sourceforge hosting. Bitweaver should be among the
lightest PHP CMS'es, but I can check out if there are any issues to it.
Off the topic, do you think that we could use Boost's thread and
socket libraries instead of the Windows-specific ones? Are there other
windows-only-functions used in the code?
> Any idea what's going on with it? Every time I look, it's fine.
>
>
> Eugen Leitl wrote:
> On Sat, Oct 24, 2009 at 12:55:06AM +0100, Satoshi Nakamoto wrote:
>> > bitcoin.sourceforge.net looks fine now. Maybe sourceforge was doing
>
> Doesn't work right now.
>
>> > some maintenance.
>
>
> Liberty Standard wrote:
>> In case you weren't aware, the Bitcoin website is down.
>>
>> http://bitcoin.sourceforge.net/
>>
>> -----
>> You are running bitweaver in TEST mode
>>
>> * Click here to log a bug, if this appears to be an error with the
>> application.
>> * Go here to begin the installation process, if you haven't done so
>> already.
>> * To hide this message, please set the IS_LIVE constant to TRUE in your
>> kernel/config_inc.php file.
> 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?
It's not possible with the current version of Bitweaver. Bitweaver's
wiki and forum packages aren't so very highly advanced. SF hosting
also has its disadvantages, like the occasional slowness and lack of
e-mailer and user IP retrieving. I've been considering to buy web
hosting from prq.se (the host of Wikileaks and Pirate Bay, among
others) to be used later for the exchange service. I could maybe host
the project site there as well, under a separate user account for
better security. There I could set up Drupal or TikiWiki, which are
more advanced and have quite a lot bigger and more active
developer/user communities than Bitweaver.
> 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.
Ok. I replaced the Windows thread and socket library includes with
their POSIX equivalents, and now it only gives a few errors, mostly svn/branches, it doesn't need to be an official release yet.
> 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 do 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.
> Ok. I replaced the Windows thread and socket library includes with their
> POSIX equivalents, and now it only gives a few errors, mostly from the
> CriticalSections. If I make it work, I'll put it into svn/branches, it
> doesn't need to be an official release yet.
> 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.
Would the Boost mutex be of any help here?
http://www.boost.org/doc/libs/1_40_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts
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.
mmalmi@cc.hut.fi wrote:
>> 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.
>
> Would the Boost mutex be of any help here?
>
> http://www.boost.org/doc/libs/1_40_0/doc/html/thread/synchronization.html#thread.synchronization.mutex_concepts
>
>
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Fri, 30 Oct
2009 01:05:45 +0000 Subject: Re: Linux build
I fixed some non-portable stuff I came across:
QueryPerformanceCounter
%I64d in printf format strings
Sleep
CheckDiskSpace
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.
I made an #ifdef to replace QueryPerformanceCounter with Linux's
gettimeofday in util.h. Some Unicode/ANSI errors were resolved without
code changes when I updated to wxWidgets 2.9. The only compile error
I'm getting in Linux at the moment is from heapchk() in util.h.
> I fixed some non-portable stuff I came across:
> QueryPerformanceCounter
> %I64d in printf format strings
> Sleep
> CheckDiskSpace
>
> 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=<ip>" to connect to each other, one windows and one
linux. -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.
mmalmi@cc.hut.fi wrote:
> I made an #ifdef to replace QueryPerformanceCounter with Linux's
> gettimeofday in util.h. Some Unicode/ANSI errors were resolved without
> code changes when I updated to wxWidgets 2.9. The only compile error I'm
> getting in Linux at the moment is from heapchk() in util.h.
>
>> I fixed some non-portable stuff I came across:
>> QueryPerformanceCounter
>> %I64d in printf format strings
>> Sleep
>> CheckDiskSpace
>>
>> 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.
>
>
>
I uploaded what I've ported so far to the svn/branches. Util, script,
db and the headers compile fully now and net.cpp partially, so there's
still work to do.
_beginthread doesn't have a direct Linux equivalent, so I used Boost
threads instead.
I couldn't get connected using the Tor SOCKS proxy. That might be
because of the Freenode Tor policy which requires connecting to their
hidden service: http://freenode.net/irc_servers.shtml#tor
> 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=<ip>" to connect to each other, one windows and one
> linux. -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.
>
> mmalmi@cc.hut.fi wrote:
>> I made an #ifdef to replace QueryPerformanceCounter with Linux's
>> gettimeofday in util.h. Some Unicode/ANSI errors were resolved
>> without code changes when I updated to wxWidgets 2.9. The only
>> compile error I'm getting in Linux at the moment is from heapchk()
>> in util.h.
>>
>>> I fixed some non-portable stuff I came across:
>>> QueryPerformanceCounter
>>> %I64d in printf format strings
>>> Sleep
>>> CheckDiskSpace
>>>
>>> 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.
>>
>>
>>
From: Satoshi Nakamoto satoshin@gmx.comTo: mmalmi@cc.hut.fiDate: Tue, 03 Nov
2009 15:53:25 +0000 Subject: Re: Linux build, proxy
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.
mmalmi@cc.hut.fi wrote:
> I uploaded what I've ported so far to the svn/branches. Util, script, db
> and the headers compile fully now and net.cpp partially, so there's
> still work to do.
>
> _beginthread doesn't have a direct Linux equivalent, so I used Boost
> threads instead.
>
> I couldn't get connected using the Tor SOCKS proxy. That might be
> because of the Freenode Tor policy which requires connecting to their
> hidden service: http://freenode.net/irc_servers.shtml#tor
>
>> 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=<ip>" to connect to each other, one windows and one
>> linux. -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.
>>
>> mmalmi@cc.hut.fi wrote:
>>> I made an #ifdef to replace QueryPerformanceCounter with Linux's
>>> gettimeofday in util.h. Some Unicode/ANSI errors were resolved
>>> without code changes when I updated to wxWidgets 2.9. The only
>>> compile error I'm getting in Linux at the moment is from heapchk()
>>> in util.h.
>>>
>>>> I fixed some non-portable stuff I came across:
>>>> QueryPerformanceCounter
>>>> %I64d in printf format strings
>>>> Sleep
>>>> CheckDiskSpace
>>>>
>>>> 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.
>>>
>>>
>>>
>
>
>
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.
mmalmi@cc.hut.fi wrote:
> I uploaded what I've ported so far to the svn/branches. Util, script, db
> and the headers compile fully now and net.cpp partially, so there's
> still work to do.
>
> _beginthread doesn't have a direct Linux equivalent, so I used Boost
> threads instead.
>
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:
apt-get install build-essential
apt-get install libgtk2.0-dev
apt-get install libssl-dev
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.
> 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".
Enabling the proxy setting and restarting Bitcoin I got the first
connections in less than a minute and ultimately even 8 connections. I
wonder if they're all really through TOR. Netstat shows only 2
connections to localhost:9050 and 7 connections from local port 8333
to elsewhere. (Some of the shown connections may be already
disconnected ones.) For some reason there's no debug.log in the folder
where I'm running it.
> 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.
The wiki page sounds like a good and quickly applicable solution. I
could keep my ip updated there and we could ask others to do the same.
When the Linux build works, it's easier to set up nodes on servers
that are online most of the time and have a static IP. A static ip
list shipped with Bitcoin and a peer exchange protocol would be cool.
That way there'd be no need for an IRC server.
> 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.
Ok. I didn't get it linked on the first attempt, but I didn't look
further into the dependencies yet.
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Thu, 05 Nov
2009 05:31:03 +0000 Subject: Re: Linux build
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
mmalmi@cc.hut.fi wrote:
> Enabling the proxy setting and restarting Bitcoin I got the first
> connections in less than a minute and ultimately even 8 connections. I
> wonder if they're all really through TOR. Netstat shows only 2
> connections to localhost:9050 and 7 connections from local port 8333 to
> elsewhere. (Some of the shown connections may be already disconnected
> ones.) For some reason there's no debug.log in the folder where I'm
> running it.
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.
>> 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.
>
> The wiki page sounds like a good and quickly applicable solution. I
> could keep my ip updated there and we could ask others to do the same.
> When the Linux build works, it's easier to set up nodes on servers that
> are online most of the time and have a static IP. A static ip list
> shipped with Bitcoin and a peer exchange protocol would be cool. That
> way there'd be no need for an IRC server.
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=<someip>",
someip 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.
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Fri, 06 Nov
2009 06:20:15 +0000 Subject: Re: Linux build
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.
> 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.
The people who are interested in being stealthy tend to be more
technically able, and they probably don't have a problem following the
instructions to get perfect secrecy. Of course there could be a
connect-button in the UI that needs to be clicked before use, but the
tradeoff is that the UI becomes less straightforward for the average
user.
> 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.
One option would be ning.com. Ning.com is a popular community site and
many users who already have an account wouldn't need to register a new
account. Example: http://p2pfoundation.ning.com/. This seems to
support SSL.
Another option would be to relocate the whole site to some place where
we can run Drupal or TikiWiki. I've been thinking of buying virtual
server or web hosting for the exchange service sometime soon, and if
the platform allows for two separate accounts, we could run the site
there too. The CMS and its database can be always copied and relocated
to a new web host if needed.
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:
http://rapidshare.com/files/303914158/linux-0.1.6-test1.tar.bz2.html
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Sun, 08 Nov 2009 11:50:44 +0200
Subject: Re: Linux build ready for testing
That's great! A major waypoint reached. Seems to work fine here.
> 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:
> http://rapidshare.com/files/303914158/linux-0.1.6-test1.tar.bz2.html
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.
Liberty Standard wrote:
> That is what I meant. The blocks displayed in the status bar did not
> increase at all while i ran the program. I have attached my debug.log.
>
> A good way for you to test the tray icon in Gnome is to remove the
> notification area and then add it back. If the icon is still displayed
> after adding the notification back, then it's working correctly.
>
> I generally set application preferences to not minimize to the tray, but
> to close to the tray. And I keep the application minimized. That way I
> don't accidentally close the program and still have the convenience of
> being able to open the application from the tray. (I don't display open
> windows in the 'task bar' but I have an icon that if clicked displays
> open windows as sub-menu items.) Then if the tray icon disappears, I go
> into the settings disable and re-enable the tray icon setting to get it
> to reappear. That's currently not possible with the bitcoin preferences
> because the close to tray check mark can not be enabled without the
> minimize to tray check box being enabled.
>
>
> On Sun, Nov 8, 2009 at 9:08 AM, Satoshi Nakamoto <satoshin@gmx.com
> <mailto:satoshin@gmx.com>> wrote:
>
> Liberty Standard wrote:
>
> I downloaded it and it runs. It and it is using plenty of CPU,
> so I think it's working properly. It has not downloaded
> previously generated blocks. Is that a bug or a new feature?
>
>
> If you mean the blocks count in the status bar isn't working its way
> up to around 26600, then that's a bug, you should send me your
> debug.log. (which is at ~/.bitcoin/debug.log)
>
>
> The system tray in Gnome is not very reliable. Sometimes an icon
> will disappear leaving no way to get back to the program. I have
> verified that this can happen with bitcoin. It would be nice if
> starting bitcoin while it's already running would just bring up
> the GUI of the already running bitcoin process.
>
>
> We haven't figured out how to find and bring up the existing running
> program yet on Linux like it does on Windows. Given what you say, I
> should at least turn off the minimize to tray option initially by
> default.
>
>
I made a ning.com site for testing: bitcoin.ning.com. At least it's
there to get Google hits, even if we didn't use it.
> 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.
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.
mmalmi@cc.hut.fi wrote:
> I made a ning.com site for testing: bitcoin.ning.com. At least it's
> there to get Google hits, even if we didn't use it.
>
>> 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.
>
>
>
Liberty Standard wrote:
> Ok, blocks have now started to increase. It definitely takes longer for
> them to start increasing than with the Windows version. Also, I think
> they might be increasing at a slower rate than in with the Windows
> version. Is there perhaps debugging enabled in the Linux build that you
> sent me? Block are increasing at about 15 blocks per second (eyeball
> estimate while looking at a clock). I didn't time how fast they
> increased in the Windows version, but it seems like it was much faster.
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?
> When I launch bitcoin and the bitcoin port is not available, I get
> the following messages to the command line. I don't get those
> messages when the bitcoin port is available. Would it be possible
> for bitcoin to pick another port if the default port is taken? The
> same think sometimes happens to me with my BitTorrent client. When I
> restart it, my previously open port is closed. All I have to do is
> change the port and it starts working again.
>
> /usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64
> Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so
> /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF
> class: ELFCLASS64
> Failed to load module:
> /usr/lib/gio/modules/libgioremote-volume-monitor.so
> /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64
> Failed to load module: /usr/lib/gio/modules/libgiogconf.so
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
bitcoin -datadir=<directory>
For example, on Linux, the default directory is (don't use ~)
bitcoin -datadir=/home/yourusername/.bitcoin
You shouldn't normally have any need to use this switch. It still won't
let you run two instances at once.
Liberty Standard wrote:
> On Mon, Nov 9, 2009 at 3:23 AM, Satoshi Nakamoto <satoshin@gmx.com
> <mailto:satoshin@gmx.com>> wrote:
>
> Liberty Standard wrote:
>
> Ok, blocks have now started to increase. It definitely takes
> longer for them to start increasing than with the Windows
> version. Also, I think they might be increasing at a slower rate
> than in with the Windows version. Is there perhaps debugging
> enabled in the Linux build that you sent me? Block are
> increasing at about 15 blocks per second (eyeball estimate while
> looking at a clock). I didn't time how fast they increased in
> the Windows version, but it seems like it was much faster.
>
>
> 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.
>
>
> It took about a half hour for it to start incrementing quickly.
> Interestingly, the CPU usage increased before it started to increment
> steadily and then lowered when it started to increment steadily.
> Although this time the block incremented to 2 within the first few
> minutes. I have not yet generated any bitcoins. I'll wait for as long as
> I have patience to generate a bitcoin, but if none are created by the
> time I lose patience, I'm going to move back to the wine version.
>
> 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.
>
>
> I've included my current debug.log.
>
>
> Martti, how long did it take to start downloading blocks when you
> ran it, and how fast did it download?
>
>
> When I launch bitcoin and the bitcoin port is not available,
> I get
> the following messages to the command line. I don't get those
> messages when the bitcoin port is available. Would it be possible
> for bitcoin to pick another port if the default port is
> taken? The
> same think sometimes happens to me with my BitTorrent client.
> When I
> restart it, my previously open port is closed. All I have to
> do is
> change the port and it starts working again.
>
> /usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64
> Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so
> /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF
> class: ELFCLASS64
> Failed to load module:
> /usr/lib/gio/modules/libgioremote-volume-monitor.so
> /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64
> Failed to load module: /usr/lib/gio/modules/libgiogconf.so
>
>
> 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.
>
>
> The reason I run two instances at the same time is to transfer bitcoins
> from one bitcoin instance to another. They of course would need to be
> accessing different data directories. Perhaps that could be specified as
> a command line argument. I currently have to move my bitcoin data folder
> to a virtual machine to do this. Shutting down bitcoin and restarting it
> with a different data directory is a poor solution because shutting down
> bitcoin while there are unconfirmed bitcoins risks losing those bitcoins.
>
> Bitcoin was definitely not running when i get the busy port error. The
> process closes quickly and reliably from my experience, but it takes
> anywhere from 30 seconds to 3 minutes (estimation from memory) for the
> port to become available again. It occurred while switching from bitcoin
> 0.1.5 in Wine to the Linux build and again while switching from the
> Linux build to bitcoin 0.1.5 in Wine.
>
> Another thing that I noticed is that the about dialog text does not fit
> correctly and it cannot be resized.
>
> I'm not sure what those lib errors are, I'll do some searching.
>
>
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Mon, 09 Nov 2009 10:32:08 +0200
Subject: Re: Linux build ready for testing
> Martti, how long did it take to start downloading blocks when you ran
> it, and how fast did it download?
Started very quickly when I got connected and downloaded quicker than
my Windows PC, which has a slower CPU.
I'll have to focus on a school project (coincidentally C++ coding) for
about a month now, so I don't have that much time for active
developing until December. Let's keep contact anyway.
> Liberty Standard wrote:
>> Ok, blocks have now started to increase. It definitely takes longer
>> for them to start increasing than with the Windows version. Also,
>> I think they might be increasing at a slower rate than in with the
>> Windows version. Is there perhaps debugging enabled in the Linux
>> build that you sent me? Block are increasing at about 15 blocks per
>> second (eyeball estimate while looking at a clock). I didn't time
>> how fast they increased in the Windows version, but it seems like
>> it was much faster.
>
> 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?
>
>> When I launch bitcoin and the bitcoin port is not available, I get
>> the following messages to the command line. I don't get those
>> messages when the bitcoin port is available. Would it be possible
>> for bitcoin to pick another port if the default port is taken? The
>> same think sometimes happens to me with my BitTorrent client. When I
>> restart it, my previously open port is closed. All I have to do is
>> change the port and it starts working again.
>>
>> /usr/lib/gio/modules/libgvfsdbus.so: wrong ELF class: ELFCLASS64
>> Failed to load module: /usr/lib/gio/modules/libgvfsdbus.so
>> /usr/lib/gio/modules/libgioremote-volume-monitor.so: wrong ELF
>> class: ELFCLASS64
>> Failed to load module:
>> /usr/lib/gio/modules/libgioremote-volume-monitor.so
>> /usr/lib/gio/modules/libgiogconf.so: wrong ELF class: ELFCLASS64
>> Failed to load module: /usr/lib/gio/modules/libgiogconf.so
>
> 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.
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.
Liberty Standard wrote:
> Everyone that contributed to making this Linux build really did a great
> job! Thanks for the hard work. It has started maturing some bitcoins, so
> I'm going to continue to run the Linux client for the time being until I
> decide whether it's at least as good or better at generating coins than
> the Windows version running in Wine.
>
>
> On Mon, Nov 9, 2009 at 8:59 AM, Liberty Standard
> <newlibertystandard@gmail.com <mailto:newlibertystandard@gmail.com>> wrote:
>
> Another instance when I would like to run multiple instances is when
> I upgrade bitcoin. I will uncheck the generate coin check box in the
> outdated bitcoin, launch and start generating coins in the new
> bitcoin using a separate data directory, then when the old
> application's coins have matured I will send them to the new
> application and then close the old application. I prefer do do clean
> installs rather than upgrading while maintaining old data.
>
>
>
> On Mon, Nov 9, 2009 at 7:42 AM, Satoshi Nakamoto <satoshin@gmx.com
> <mailto:satoshin@gmx.com>> wrote:
>
> 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.
>
From: Satoshi Nakamoto satoshin@gmx.comTo: mmalmi@cc.hut.fiDate: Mon, 09 Nov
2009 19:41:11 +0000 Subject: Re: Linux build ready for
testing
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.
mmalmi@cc.hut.fi wrote:
> I'll have to focus on a school project (coincidentally C++ coding) for
> about a month now, so I don't have that much time for active developing
> until December. Let's keep contact anyway.
>
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:
2/unconfirmed
3/unconfirmed
4/unconfirmed
5/unconfirmed
6 blocks
7 blocks
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.
Liberty Standard wrote:
> I just lost 6 sets of maturing coins! I had 10 sets of bitcoins
> maturing. The last set was generated at about 0:22. It got to
> 2/unconfirmed before bitcoin got stuck. At 10:10, the bitcoin which was
> generated at 0:22 was still only at 2/unconfirmed. Since you had told me
> that I wasn't going to lose coins, I shutdown and restarted bitcoin. On
> the bright side, it shutdown and started up very smoothly. But
> unfortunately, when the blocks updated, I lost 6 sets of bitcoins. Four
> sets were still unconfirmed, but two sets were confirmed. And there's no
> trace of them now. Perhaps now that you have the 'Show Generated Coins'
> option available, you can put back in failed bitcoin generations. I just
> don't like that those bitcoins just disappeared into thin air. I'm still
> running the Linux build at the moment, but the Wine version is suddenly
> looking much more attractive now that 6 out of the 10 sets of bitcoins I
> generated in the past 24 hours just vanished. I've included my debug.log.
>
>
> On Tue, Nov 10, 2009 at 1:45 AM, Liberty Standard
> <newlibertystandard@gmail.com <mailto:newlibertystandard@gmail.com>> wrote:
>
> The Linux build has generated a decent amount of bitcoins within the
> past 20 hours and I trust what you're telling me about database
> errors, so all signs point toward me running the Linux build from
> now on. The only half annoying thing about the Linux build is that
> my computer's fan has gone from 50% to 100%. :-P I know I can limit
> the CPU, so if it gets on my nerves too much and if I can live with
> less bitcoins being generated, perhaps I'll do that. Or maybe I just
> need to start listening to more music...
>
...
>
> 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.
>
>
>
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.
linux-0.1.6-test2.tar.bz2 12,134,012 bytes
Download:
http://rapidshare.com/files/305231818/linux-0.1.6-test2.tar.bz2.html
Satoshi Nakamoto wrote:
> 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:
> 2/unconfirmed
> 3/unconfirmed
> 4/unconfirmed
> 5/unconfirmed
> 6 blocks
> 7 blocks
>
> 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.
>
> Liberty Standard wrote:
>> I just lost 6 sets of maturing coins! I had 10 sets of bitcoins
>> maturing. The last set was generated at about 0:22. It got to
>> 2/unconfirmed before bitcoin got stuck. At 10:10, the bitcoin which
>> was generated at 0:22 was still only at 2/unconfirmed. Since you had
>> told me that I wasn't going to lose coins, I shutdown and restarted
>> bitcoin. On the bright side, it shutdown and started up very smoothly.
>> But unfortunately, when the blocks updated, I lost 6 sets of bitcoins.
>> Four sets were still unconfirmed, but two sets were confirmed. And
>> there's no trace of them now. Perhaps now that you have the 'Show
>> Generated Coins' option available, you can put back in failed bitcoin
>> generations. I just don't like that those bitcoins just disappeared
>> into thin air. I'm still running the Linux build at the moment, but
>> the Wine version is suddenly looking much more attractive now that 6
>> out of the 10 sets of bitcoins I generated in the past 24 hours just
>> vanished. I've included my debug.log.
>>
>>
>> On Tue, Nov 10, 2009 at 1:45 AM, Liberty Standard
>> <newlibertystandard@gmail.com <mailto:newlibertystandard@gmail.com>>
>> wrote:
>>
>> The Linux build has generated a decent amount of bitcoins within the
>> past 20 hours and I trust what you're telling me about database
>> errors, so all signs point toward me running the Linux build from
>> now on. The only half annoying thing about the Linux build is that
>> my computer's fan has gone from 50% to 100%. :-P I know I can limit
>> the CPU, so if it gets on my nerves too much and if I can live with
>> less bitcoins being generated, perhaps I'll do that. Or maybe I just
>> need to start listening to more music...
>>
> ...
>>
>> 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.
>>
>>
>>
>
>
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.
File linux-0.1.6-test3.tar.bz2 attached in the next message.
Liberty Standard wrote:
> On Wed, Nov 11, 2009 at 8:08 AM, Liberty Standard
> <newlibertystandard@gmail.com <mailto:newlibertystandard@gmail.com>> wrote:
>
> My network connection is direct to my computer. My ISP requires that
> I run VPN to connect to the Internet. I then have a second NIC that
> shares my Internet with other devices. My IP address while using my
> computer is my actual IP address, but the devices connected through
> my second NIC use NAT. When I connect through a virtual machine,
> that also uses NAT. All this requires very little configuration.
> NetworkManager in Ubuntu has an option to share my Internet
> connection through the second NIC and VirtualBox has the option to
> use NAT.
>
> I lost a couple packs of bitcoins again, so that problem is not yet
> fixed. It's a bit more bearable now that I have an idea of what is
> going on. I figure for now I'll just restart bitcoin whenever I see
> a pack of bitcoins starting to mature. I may go back and forth a bit
> between Linux and Wine, but I'll definitely test every new version
> that comes out. At the moment I'm still running the Linux build.
>
>
>
> On Wed, Nov 11, 2009 at 7:49 AM, Satoshi Nakamoto <satoshin@gmx.com
> <mailto:satoshin@gmx.com>> wrote:
>
> Thanks. The log didn't stop on anything special, just simple
> message passing. Chances are it's UI related. Most of the
> initial bugs were all UI.
>
> What brand/model of firewall do you have? It's possible for
> BitTorrent to overwhelm the number of connections some models
> can handle. Most are underpowered and flaky under load.
>
> NewLibertyStandard wrote:
>
> I have been getting your attachments just fine. I just
> thought I'd spare Martti the large attachment.
>
> I am not able to reproduce the bug. I don't know whether the
> paste, the blocks finishing, a combination of the two or
> something else entirely caused the fault.
>
> ...
>
> But after they started
> downloading, I took a look a look at my BitTorrent
> client, and
> sure enough, I had forgotten about a torrent and my
> upload was
> quite high, at the limit I had set for it.
>
>
>
>
>
test 5:
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)
File attached in the next e-mail
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Sat, 14 Nov
2009 05:46:22 +0000 Subject: Zetaboards forum
I created a forum on Zetaboards, InvisionFree's new site that they're
migrating to.
http://s1.zetaboards.com/Bitcoin/index/
I made an admin account you can use to upgrade your own account to admin:
u: admin
pw: B98VzUUA
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.
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Sun, 15 Nov
2009 15:40:29 +0000 Subject: Linux update
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.
************************
EXCEPTION: 11DbException
Db::open: Bad file descriptor
bitcoin in ThreadMessageHandler()
************************
EXCEPTION: 11DbException
Db::close: Bad file descriptor
bitcoin in ThreadMessageHandler()
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.
mmalmi@cc.hut.fi wrote:
> The program terminated a few times with the same error in debug.log from
> Db::close. Db.log has:
>
> close: Bad file descriptor
> blkindex.dat: Bad file descriptor
>
> I'm running a 64-bit Ubuntu distribution.
>
>> The only problem now is the DB exceptions he's getting.
>> ************************
>> EXCEPTION: 11DbException
>> Db::open: Bad file descriptor
>> bitcoin in ThreadMessageHandler()
>> ************************
>> EXCEPTION: 11DbException
>> Db::close: Bad file descriptor
>> bitcoin in ThreadMessageHandler()
>>
>> 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.
>
The program terminated a few times with the same error in debug.log
close: Bad file descriptor
blkindex.dat: Bad file descriptor
I'm running a 64-bit Ubuntu distribution.
> The only problem now is the DB exceptions he's getting.
> ************************
> EXCEPTION: 11DbException
> Db::open: Bad file descriptor
> bitcoin in ThreadMessageHandler()
> ************************
> EXCEPTION: 11DbException
> Db::close: Bad file descriptor
> bitcoin in ThreadMessageHandler()
>
> 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.
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
mmalmi@cc.hut.fi wrote:
> Perhaps the real name is better.
>
> Another name question: I've been thinking of a name for the exchange
> service, and I came up with Bitcoin X (bitcoinx.com) and Bitcoin Shop
> (bitcoinshop.com). Which one do you find better?
>
>> 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.
>>
>> mmalmi@cc.hut.fi wrote:
>>> The program terminated a few times with the same error in debug.log
>>> from Db::close. Db.log has:
>>>
>>> close: Bad file descriptor
>>> blkindex.dat: Bad file descriptor
>>>
>>> I'm running a 64-bit Ubuntu distribution.
>>>
>>>> The only problem now is the DB exceptions he's getting.
>>>> ************************
>>>> EXCEPTION: 11DbException
>>>> Db::open: Bad file descriptor
>>>> bitcoin in ThreadMessageHandler()
>>>> ************************
>>>> EXCEPTION: 11DbException
>>>> Db::close: Bad file descriptor
>>>> bitcoin in ThreadMessageHandler()
>>>>
>>>> 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.
>>>
>
>
>
Perhaps the real name is better.
Another name question: I've been thinking of a name for the exchange
service, and I came up with Bitcoin X (bitcoinx.com) and Bitcoin Shop
(bitcoinshop.com). Which one do you find better?
> 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.
>
> mmalmi@cc.hut.fi wrote:
>> The program terminated a few times with the same error in debug.log
>> from Db::close. Db.log has:
>>
>> close: Bad file descriptor
>> blkindex.dat: Bad file descriptor
>>
>> I'm running a 64-bit Ubuntu distribution.
>>
>>> The only problem now is the DB exceptions he's getting.
>>> ************************
>>> EXCEPTION: 11DbException
>>> Db::open: Bad file descriptor
>>> bitcoin in ThreadMessageHandler()
>>> ************************
>>> EXCEPTION: 11DbException
>>> Db::close: Bad file descriptor
>>> bitcoin in ThreadMessageHandler()
>>>
>>> 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.
>>
From: Satoshi Nakamoto satoshin@gmx.comTo: Liberty Standard newlibertystandard@gmail.comDate:
Mon, 16 Nov 2009 06:20:52 +0000 Subject: Re:
Db::open/Db::close “Bad file descriptor” exception
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?
Liberty Standard wrote:
> I moved the data directory back to my SSD card and started bitcoin test
> 6. It encountered a segmentation fault today with Db::open in the log. I
> had changed the settings to only use one processor/core while I watched
> a 720p mkv movie. I noticed the segmentation fault after the film had ended.
>
> On Sun, Nov 15, 2009 at 12:45 AM, Satoshi Nakamoto <satoshin@gmx.com
> <mailto:satoshin@gmx.com>> wrote:
>
> Here's one where I linked Berkeley DB a different way. It's worth a
> try. Otherwise identical to test5.
>
> (Keep the datadir on the hard drive at least until you get it to
> fail the same way there. That has a fair chance of success.)
>
>
I installed a TikiWiki on my VPS at 174.143.149.98. SSL is currently
enabled with a self-signed certificate. Admin password is the same as
in the Bitweaver. How about using this as the site platform? Maybe we
can make bitcoin.org or at least bitcoin.sf.net point there?
mmalmi@cc.hut.fi wrote:
> I installed a TikiWiki on my VPS at 174.143.149.98. SSL is currently
> enabled with a self-signed certificate. Admin password is the same as in
> the Bitweaver. How about using this as the site platform? Maybe we can
> make bitcoin.org or at least bitcoin.sf.net point there?
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
mmalmi@cc.hut.fi wrote:
>> 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
>
> I think the biggest advantage is having a single site so you don't need
> a separate account for the wiki and the forum, and the functionalities
> are also nicely integrated with the main site itself. Also being ad-free
> is a plus.
>
>> The forum feature is about as weak as bitweaver. We need a full blown
>> forum software for that.
>
> How about Drupal's forum functionality? Address:
> https://174.143.149.98/drupal/. The CMS in general looks better and
> simpler than TikiWiki. If the forum's not good enough, then we can of
> course use a specialized forum software like phpBB.
>
>> 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?
>
> Otherwise fine, but the ads and the lack of SSL are a minus.
>
> 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
I think the biggest advantage is having a single site so you don't
need a separate account for the wiki and the forum, and the
functionalities are also nicely integrated with the main site itself.
Also being ad-free is a plus.
> The forum feature is about as weak as bitweaver. We need a full blown
> forum software for that.
How about Drupal's forum functionality? Address:
https://174.143.149.98/drupal/. The CMS in general looks better and
simpler than TikiWiki. If the forum's not good enough, then we can of
course use a specialized forum software like phpBB.
> 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?
Otherwise fine, but the ads and the lack of SSL are a minus.
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.
mmalmi@cc.hut.fi wrote:
> How about Drupal's forum functionality? Address:
> https://174.143.149.98/drupal/. The CMS in general looks better and
> simpler than TikiWiki. If the forum's not good enough, then we can of
> course use a specialized forum software like phpBB.
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.
I installed both phpBB3 and Simple Machines Forum, which are kind of
the market leaders among the open source forums. SMF's interface looks
better on the first look, especially the admin panel. What do you
think, shall we go with SMF or phpBB3?
Here's the logs in case they're still useful.
> 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?
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.
Liberty Standard wrote:
> I started with a fresh data directory with test7. Blocks started to
> download much faster. It only took about 15 seconds where it took a few
> minutes previously with the Linux build. It crashed once while it was
> downloading blocks with the following message in the terminal.
>
> ../include/wx/thrimpl.cpp(50): assert "m_internal" failed in TryLock():
> wxMutex::TryLock(): not initialized [in child thread]
> Trace/breakpoint trap
>
> I've included my log file, but I forgot to back it up before restarting
> bitcoin, so I'm not sure at what point in the log file the crash occurred.
>
> Fortunately I haven't encountered the segmentation fault yet. The
> frequency of segmentation faults in the previous builds varied quite a
> bit, so I'll keep running it and let you know if i run into any problems.
>
>
>
> On Tue, Nov 17, 2009 at 5:41 AM, Satoshi Nakamoto <satoshin@gmx.com
> <mailto:satoshin@gmx.com>> wrote:
>
> 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.
>
>
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)
mmalmi@cc.hut.fi wrote:
> Here's the logs in case they're still useful.
>
>> 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?
>
That's great, this is going to fun! I'll research what people say about
the two.
mmalmi@cc.hut.fi wrote:
> I installed both phpBB3 and Simple Machines Forum, which are kind of
> the market leaders among the open source forums. SMF's interface looks
> better on the first look, especially the admin panel. What do you
> think, shall we go with SMF or phpBB3?
>
>
I think it was test version 5, not completely sure though. I'm running
the Linux version on a laptop which I move between different locations
and use the hibernate-feature instead of powering down.
> 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)
>
> mmalmi@cc.hut.fi wrote:
>> Here's the logs in case they're still useful.
>>
>>> 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?
>>
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Fri, 20 Nov
2009 05:14:56 +0000 Subject: SMF forum, need a mod
installed
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->Packages->Browse Packages and click on
Apply Mod, it offers to do it automatically if you enter an ftp login.
Someone says you might also have to
mkdir /var/www/bitcoin/smf/packages/temp
The error in the error log is:
failed to open stream: Permission denied
File: /var/www/bitcoin/smf/Sources/Subs-Package.php
(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.
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Fri, 20 Nov 2009 09:05:34 +0200
Subject: Re: SMF forum, need a mod installed
I don't have the time to configure it today, but I made a temporary
account "maintenance" with password "6648ku5HeK" and full permissions
to /var/www/bitcoin. You can access it via ssh or sftp at port 30000.
It's okay to go live. Are you setting up a redirect or a dns entry? In
case of dns entry I could set up an Apache vhost so that the forum
address would be http://forum.bitcoin.org/.
Great that the Linux build works now. It's exciting to see how things
will start rolling with the new release and the forum. Not too long
until I can set up my own exchange and start promoting the currency to
(web) business people.
NewLibertyStandard should perhaps change his pricing to the market
price (i.e. what people are willing to buy and sell for) so that he
doesn't run out of coins.
> 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->Packages->Browse Packages and
> click on Apply Mod, it offers to do it automatically if you enter an
> ftp login.
>
> Someone says you might also have to
> mkdir /var/www/bitcoin/smf/packages/temp
>
> The error in the error log is:
> failed to open stream: Permission denied
> File: /var/www/bitcoin/smf/Sources/Subs-Package.php
> (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.
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Fri, 20 Nov 2009 09:17:00 +0200
Subject: Re: SMF forum, need a mod installed
Oh yes, one more thing. I haven't configured the server's sendmail
yet, so the php mail functionality doesn't work, but it's not needed
yet anyway.
> I don't have the time to configure it today, but I made a temporary
> account "maintenance" with password "6648ku5HeK" and full permissions
> to /var/www/bitcoin. You can access it via ssh or sftp at port 30000.
>
> It's okay to go live. Are you setting up a redirect or a dns entry? In
> case of dns entry I could set up an Apache vhost so that the forum
> address would be http://forum.bitcoin.org/.
>
> Great that the Linux build works now. It's exciting to see how things
> will start rolling with the new release and the forum. Not too long
> until I can set up my own exchange and start promoting the currency to
> (web) business people.
>
> NewLibertyStandard should perhaps change his pricing to the market
> price (i.e. what people are willing to buy and sell for) so that he
> doesn't run out of coins.
>
>> 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->Packages->Browse Packages and
>> click on Apply Mod, it offers to do it automatically if you enter an
>> ftp login.
>>
>> Someone says you might also have to
>> mkdir /var/www/bitcoin/smf/packages/temp
>>
>> The error in the error log is:
>> failed to open stream: Permission denied
>> File: /var/www/bitcoin/smf/Sources/Subs-Package.php
>> (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.
From: Satoshi Nakamoto satoshin@gmx.comTo: mmalmi@cc.hut.fiDate: Fri, 20 Nov
2009 22:09:41 +0000 Subject: Re: SMF forum, need a mod
installed
> It's okay to go live. Are you setting up a redirect or a dns entry? In
> case of dns entry I could set up an Apache vhost so that the forum
> address would be http://forum.bitcoin.org/.
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.
> Great that the Linux build works now. It's exciting to see how things
> will start rolling with the new release and the forum. Not too long
> until I can set up my own exchange and start promoting the currency to
> (web) business people.
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.
> NewLibertyStandard should perhaps change his pricing to the market price
> (i.e. what people are willing to buy and sell for) so that he doesn't
> run out of coins.
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.
From: Satoshi Nakamoto satoshin@gmx.comTo: mmalmi@cc.hut.fiDate: Sat, 21 Nov
2009 07:02:20 +0000 Subject: Re: SMF forum, need a mod
installed
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".
mmalmi@cc.hut.fi wrote:
> I don't have the time to configure it today, but I made a temporary
> account "" with password "" and full permissions to
> /var/www/bitcoin. You can access it via ssh or sftp at port 30000.
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Sat, 21 Nov 2009 12:50:00 +0200
Subject: Re: SMF forum, need a mod installed
I've done a Joomla site for a customer, and I must say I like Drupal
better, mostly for the admin interface which is easier to use and
integrated into the main site.
Images aren't loading properly over https, I'll check it out when I can.
It's easier to just change the bitcoin.org DNS entry,
forum.bitcoin.org is not necessary.
We could see if we can get a free SSL certificate somewhere, like
http://www.startssl.com/?app=1, so the users wouldn't get a security
warning from a self-signed certificate. However I don't know if they
give certificates for anonymously registered domains.
> 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".
>
> mmalmi@cc.hut.fi wrote:
>> I don't have the time to configure it today, but I made a temporary
>> account "" with password "" and full permissions to
>> /var/www/bitcoin. You can access it via ssh or sftp at port 30000.
From: Satoshi Nakamoto satoshin@gmx.comTo: mmalmi@cc.hut.fiDate: Sat, 21 Nov
2009 21:46:52 +0000 Subject: Re: SMF forum, need a mod
installed
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.
mmalmi@cc.hut.fi wrote:
> I've done a Joomla site for a customer, and I must say I like Drupal
> better, mostly for the admin interface which is easier to use and
> integrated into the main site.
>
> Images aren't loading properly over https, I'll check it out when I can.
>
> It's easier to just change the bitcoin.org DNS entry, forum.bitcoin.org
> is not necessary.
>
> We could see if we can get a free SSL certificate somewhere, like
> http://www.startssl.com/?app=1, so the users wouldn't get a security
> warning from a self-signed certificate. However I don't know if they
> give certificates for anonymously registered domains.
>
>> 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".
>>
>> mmalmi@cc.hut.fi wrote:
>>> I don't have the time to configure it today, but I made a temporary
>>> account "" with password "" and full permissions to
>>> /var/www/bitcoin. You can access it via ssh or sftp at port 30000.
>
>
>
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Sun, 22 Nov
2009 19:47:56 +0000 Subject: SEO friendly site
transition
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.
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Sun, 22 Nov 2009 22:22:57 +0200
Subject: Re: SEO friendly site transition
That's ok.
I'll be afk 23.-25.11.
> 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.
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Mon, 23 Nov
2009 05:48:19 +0000 Subject: Access permissions
required to fix Drupal
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:
/etc/apache2/sites-available/default
/etc/apache2/sites-available/default-ssl
/etc/apache2/httpd.conf
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.
In /etc/apache2/sites-available/default
change the 2nd instance of "AllowOverride None"
to "AllowOverride All"
and in /etc/apache2/sites-available/default-ssl
change the 2nd instance of "AllowOverride AuthConfig"
to "AllowOverride All"
replace
/etc/apache2/httpd.conf
with
/home/maintenance/httpd.conf
This probably requires Apache to be restarted after.
(apache2ctl graceful)
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Mon, 23 Nov 2009 08:44:35 +0200
Subject: Re: Access permissions required to fix
Drupal
Done. I granted you access to all the files.
> 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:
> /etc/apache2/sites-available/default
> /etc/apache2/sites-available/default-ssl
> /etc/apache2/httpd.conf
>
> 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.
>
> In /etc/apache2/sites-available/default
> change the 2nd instance of "AllowOverride None"
> to "AllowOverride All"
>
> and in /etc/apache2/sites-available/default-ssl
> change the 2nd instance of "AllowOverride AuthConfig"
> to "AllowOverride All"
>
> replace
> /etc/apache2/httpd.conf
> with
> /home/maintenance/httpd.conf
>
> This probably requires Apache to be restarted after.
> (apache2ctl graceful)
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Thu, 26 Nov
2009 00:26:33 +0000 Subject: bitcoin.org DNS change
went through
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->Forum URL
themes and layout->attempt to reset all themes
there's a path in smileys and message icons
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Thu, 26 Nov
2009 17:45:42 +0000 Subject: Bitweaver menu editor
broken
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:
http://www.bitcoin.org/smf/
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Fri, 27 Nov 2009 02:46:50 +0200
Subject: Re: Bitweaver menu editor broken
Fixed. I changed it directly in the database.
> 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:
> http://www.bitcoin.org/smf/
I just watched the Google Wave introduction video at wave.google.com.
It's the Google's open source proposal for a replacement for the
decades old e-mail protocol, and it looked quite cool. A "wave" is a
communication and collaboration unit that can be read and edited by
multiple users in real time and easily shared to new users, unlike
e-mail threads. It combines the functionality of instant messaging,
wikis, conventional e-mail and social networking, and supports
integration with external applications.
If you want invites, you can give me the e-mail addresses where you
want them to. If you already have Wave addresses, please give me them
as well. It would be great to see how the system works in practice.
The current site layout looks nice and simple. The logo just should be
changed. If we want to go live quickly, we can just replace it with
the site title and make a better logo later.
If we need help with site administration or contacts to professional
web graphic artists, we can ask Dave. He does Drupal stuff for work.
It would be also great if you can get the Sourceforge logo from the SF
project admin and add it to the site footer.
> The current site layout looks nice and simple. The logo just should be
> changed. If we want to go live quickly, we can just replace it with the
> site title and make a better logo later.
>
> If we need help with site administration or contacts to professional
> web graphic artists, we can ask Dave. He does Drupal stuff for work.
I autogenerated the new logo at http://cooltext.com/, it's a good
quick solution. You can try a wide variety of different logo styles
there if you have the patience for the slow user interface.
> It would be also great if you can get the Sourceforge logo from the SF
> project admin and add it to the site footer.
>
>> The current site layout looks nice and simple. The logo just should be
>> changed. If we want to go live quickly, we can just replace it with the
>> site title and make a better logo later.
>>
>> If we need help with site administration or contacts to professional
>> web graphic artists, we can ask Dave. He does Drupal stuff for work.
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.
mmalmi@cc.hut.fi wrote:
> I autogenerated the new logo at http://cooltext.com/, it's a good quick
> solution. You can try a wide variety of different logo styles there if
> you have the patience for the slow user interface.
>
>> It would be also great if you can get the Sourceforge logo from the SF
>> project admin and add it to the site footer.
>>
>>> The current site layout looks nice and simple. The logo just should be
>>> changed. If we want to go live quickly, we can just replace it with the
>>> site title and make a better logo later.
>>>
>>> If we need help with site administration or contacts to professional
>>> web graphic artists, we can ask Dave. He does Drupal stuff for work.
>
>
>
The text logo looks quite good actually, except on Windows when the
font antialiasing doesn't work. I turned it into a png.
I just made a 10,000bc transaction from one account to another, but it
ended up sending 10,000.20bc. Any idea why that could be?
> 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.
>
> mmalmi@cc.hut.fi wrote:
>> I autogenerated the new logo at http://cooltext.com/, it's a good
>> quick solution. You can try a wide variety of different logo styles
>> there if you have the patience for the slow user interface.
>>
>>> It would be also great if you can get the Sourceforge logo from the SF
>>> project admin and add it to the site footer.
>>>
>>>> The current site layout looks nice and simple. The logo just should be
>>>> changed. If we want to go live quickly, we can just replace it with the
>>>> site title and make a better logo later.
>>>>
>>>> If we need help with site administration or contacts to professional
>>>> web graphic artists, we can ask Dave. He does Drupal stuff for work.
>>
>>
>>
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.
mmalmi@cc.hut.fi wrote:
> The text logo looks quite good actually, except on Windows when the font
> antialiasing doesn't work. I turned it into a png.
>
> I just made a 10,000bc transaction from one account to another, but it
> ended up sending 10,000.20bc. Any idea why that could be?
>
>> 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.
>>
>> mmalmi@cc.hut.fi wrote:
>>> I autogenerated the new logo at http://cooltext.com/, it's a good
>>> quick solution. You can try a wide variety of different logo styles
>>> there if you have the patience for the slow user interface.
>>>
>>>> It would be also great if you can get the Sourceforge logo from the SF
>>>> project admin and add it to the site footer.
>>>>
>>>>> The current site layout looks nice and simple. The logo just should be
>>>>> changed. If we want to go live quickly, we can just replace it with
>>>>> the
>>>>> site title and make a better logo later.
>>>>>
>>>>> If we need help with site administration or contacts to professional
>>>>> web graphic artists, we can ask Dave. He does Drupal stuff for work.
>>>
>>>
>>>
>
>
>
> 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.
Firefox on XP doesn't, and IE also doesn't produce as good quality as
I have on Linux. Screenshots from browsershots.org attached.
> 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.
Is there no transaction fee then, if you send the same amount in
multiple small packages?
> 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.
Sounds fine.
> Then we wouldn't have to explain the 10,000.20bc transaction, but may
> still have to explain who the transaction fee goes to.
Where should it go btw? Here it went to the receiver along with all
the other coins. Transaction screenshot attached.
> mmalmi@cc.hut.fi wrote:
>> The text logo looks quite good actually, except on Windows when the
>> font antialiasing doesn't work. I turned it into a png.
>>
>> I just made a 10,000bc transaction from one account to another, but
>> it ended up sending 10,000.20bc. Any idea why that could be?
>>
>>> 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.
>>>
>>> mmalmi@cc.hut.fi wrote:
>>>> I autogenerated the new logo at http://cooltext.com/, it's a good
>>>> quick solution. You can try a wide variety of different logo
>>>> styles there if you have the patience for the slow user interface.
>>>>
>>>>> It would be also great if you can get the Sourceforge logo from the SF
>>>>> project admin and add it to the site footer.
>>>>>
>>>>>> The current site layout looks nice and simple. The logo just should be
>>>>>> changed. If we want to go live quickly, we can just replace it with the
>>>>>> site title and make a better logo later.
>>>>>>
>>>>>> If we need help with site administration or contacts to professional
>>>>>> web graphic artists, we can ask Dave. He does Drupal stuff for work.
>>>>
>>>>
>>>>
>>
>>
>>
mmalmi@cc.hut.fi wrote:
>> 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.
>
> Firefox on XP doesn't, and IE also doesn't produce as good quality as I
> have on Linux. Screenshots from browsershots.org attached.
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 <span> tags and junk in the browser title but
that's fine for testing.
I added some instruction text on the homepage below the screenshots.
> Is there no transaction fee then, if you send the same amount in
> multiple small packages?
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.
> Where should it go btw? Here it went to the receiver along with all the
> other coins. Transaction screenshot attached.
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.
---
The available logos and the correct HTML to use for the Bitcoin project are:
Logo 1 (Dimensions: 80 x 15; Background: Black)
HTML Code: <a href="http://sourceforge.net/projects/bitcoin"><img
src="http://sflogo.sourceforge.net/sflogo.php?group_id=244765&type=8"
width="80" height="15" alt="Get Bitcoin at SourceForge.net. Fast, secure
and Free Open Source software downloads" /></a>
Logo 2 (Dimensions: 80 x 15; Background: Silver)
HTML Code: <a href="http://sourceforge.net/projects/bitcoin"><img
src="http://sflogo.sourceforge.net/sflogo.php?group_id=244765&type=9"
width="80" height="15" alt="Get Bitcoin at SourceForge.net. Fast, secure
and Free Open Source software downloads" /></a>
Logo 3 (Dimensions: 80 x 15; Background: White)
HTML Code: <a href="http://sourceforge.net/projects/bitcoin"><img
src="http://sflogo.sourceforge.net/sflogo.php?group_id=244765&type=10"
width="80" height="15" alt="Get Bitcoin at SourceForge.net. Fast, secure
and Free Open Source software downloads" /></a>
Logo 4 (Dimensions: 120 x 30; Background: Black)
HTML Code: <a href="http://sourceforge.net/projects/bitcoin"><img
src="http://sflogo.sourceforge.net/sflogo.php?group_id=244765&type=11"
width="120" height="30" alt="Get Bitcoin at SourceForge.net. Fast,
secure and Free Open Source software downloads" /></a>
Logo 5 (Dimensions: 120 x 30; Background: Silver)
HTML Code: <a href="http://sourceforge.net/projects/bitcoin"><img
src="http://sflogo.sourceforge.net/sflogo.php?group_id=244765&type=12"
width="120" height="30" alt="Get Bitcoin at SourceForge.net. Fast,
secure and Free Open Source software downloads" /></a>
Logo 6 (Dimensions: 120 x 30; Background: White)
HTML Code: <a href="http://sourceforge.net/projects/bitcoin"><img
src="http://sflogo.sourceforge.net/sflogo.php?group_id=244765&type=13"
width="120" height="30" alt="Get Bitcoin at SourceForge.net. Fast,
secure and Free Open Source software downloads" /></a>
Logo 7 (Dimensions: 150 x 40; Background: Black)
HTML Code: <a href="http://sourceforge.net/projects/bitcoin"><img
src="http://sflogo.sourceforge.net/sflogo.php?group_id=244765&type=14"
width="150" height="40" alt="Get Bitcoin at SourceForge.net. Fast,
secure and Free Open Source software downloads" /></a>
Logo 8 (Dimensions: 150 x 40; Background: Silver)
HTML Code: <a href="http://sourceforge.net/projects/bitcoin"><img
src="http://sflogo.sourceforge.net/sflogo.php?group_id=244765&type=15"
width="150" height="40" alt="Get Bitcoin at SourceForge.net. Fast,
secure and Free Open Source software downloads" /></a>
Logo 9 (Dimensions: 150 x 40; Background: White)
HTML Code: <a href="http://sourceforge.net/projects/bitcoin"><img
src="http://sflogo.sourceforge.net/sflogo.php?group_id=244765&type=16"
width="150" height="40" alt="Get Bitcoin at SourceForge.net. Fast,
secure and Free Open Source software downloads" /></a>
mmalmi@cc.hut.fi wrote:
> It would be also great if you can get the Sourceforge logo from the SF
> project admin and add it to the site footer.
>
>> The current site layout looks nice and simple. The logo just should be
>> changed. If we want to go live quickly, we can just replace it with the
>> site title and make a better logo later.
>>
>> If we need help with site administration or contacts to professional
>> web graphic artists, we can ask Dave. He does Drupal stuff for work.
>
>
>
I made a copy of the logo onto the local server, so we can still use
it for graphics. It's not disallowed by the SF trademark policy.
> 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.
>
> mmalmi@cc.hut.fi wrote:
>> It would be also great if you can get the Sourceforge logo from the
>> SF project admin and add it to the site footer.
>>
>>> The current site layout looks nice and simple. The logo just should be
>>> changed. If we want to go live quickly, we can just replace it with the
>>> site title and make a better logo later.
>>>
>>> If we need help with site administration or contacts to professional
>>> web graphic artists, we can ask Dave. He does Drupal stuff for work.
>>
>>
>>
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Tue, 08 Dec
2009 05:43:33 +0000 Subject: Drupal site online
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.
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Tue, 08 Dec 2009 12:50:20 +0200
Subject: Re: Drupal site online
Good job. I redirected bitcoin.sourceforge.net there.
> 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.
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Fri, 11 Dec
2009 03:30:10 +0000 Subject: custom3 theme
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.
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Sun, 13 Dec 2009 22:12:38 +0200
Subject: Re: Version 0.2 almost ready to release
> It's almost time to release version 0.2. If you have a minute, could
> you try this release candidate (attached)? If there aren't any
> problems and I don't think of anything I missed, this could be released
> in a day or two.
No problems so far. Seems fine.
> I zipped the setup exe because I doubt the e-mail servers will allow
> exe attachments. I'm not sure it'll allow zip either, but pretty sure
> the tar.gz one will get through.
>
> Attachments:
> 3,092,916 bitcoin-0.2.0-setup.zip
> 2,402,522 bitcoin-0.2.0-linux.tar.gz
> 3,061,059 bitcoin-0.2.0-win32.zip
Both got through here.
> Found something I felt I had to fix with the initial block download.
> Do you mind testing an initial block download again?
The first time I tried it on Windows, the initial download took a few
minutes to start, even though it got many connections quickly. I tried
again twice, and didn't have the same problem again. I don't know
whether it's related to your latest update or not.
On Ubuntu it worked fine.
> Hope this isn't in the middle of your final exams right now.
Well actually it is, but it's not too bad. Time is a matter of arrangement.
mmalmi@cc.hut.fi wrote:
> The first time I tried it on Windows, the initial download took a few
> minutes to start, even though it got many connections quickly. I tried
> again twice, and didn't have the same problem again. I don't know
> whether it's related to your latest update or not.
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?
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Wed, 16 Dec
2009 16:54:46 +0000 Subject: Planned release
announcement text
Here's the planned release announcement text. Probably releasing shortly.
Bitcoin version 0.2 is here!
Download links:
Windows Setup Program
Windows Zip File
Linux (tested on Ubuntu)
New features
Martti Malmi
- Minimize to system tray option
- Autostart on boot option so you can keep it running in the
background automatically
- New options dialog layout for future expansion
- Setup program for Windows
- Linux version
Satoshi Nakamoto
- 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 Martti Malmi (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.
Satoshi Nakamoto
>> The first time I tried it on Windows, the initial download took a
>> few minutes to start, even though it got many connections quickly.
>> I tried again twice, and didn't have the same problem again. I
>> don't know whether it's related to your latest update or not.
>
> Most of the fixes are on the sender's side, so if you were downloading
> from a 0.1.5 node, some problems are still there. It'll get better as
> the network upgrades to 0.2.
>
> How long did the initial download take?
About 1,5h.
Bitcoin 0.2 is here!
Download (Windows, and now Linux version available)
http://sourceforge.net/projects/bitcoin/files/
New Features
Martti Malmi
- Minimize to system tray option
- Autostart on boot option so you can keep it running in the
background automatically
- New options dialog layout for future expansion
- Setup program for Windows
- Linux version (tested on Ubuntu)
Satoshi Nakamoto
- 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.
Satoshi Nakamoto
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
bitcoin-list mailing list
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list
I have registered the domain name bitcoinexchange.com and will start
coding the service sometime soon as a nice leisure activity. I'm
envisioning a simple Google-like interface with no registration and
only two texts fields on the front page, where you insert the amount
of money you wish to trade, and either your PayPal address to buy
dollars or bitcoin address to buy bitcoins. On the next page you'll
get a new bitcoin address for sending the coins or a check code for
the PayPal transaction text.
PayPal is good for the beginning - it's simple and has no startup
costs, but later on I might accept credit cards also.
Do you still need the maintenance account? It's ok if you do, but
change the password to something else.
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.
mmalmi@cc.hut.fi wrote:
> I have registered the domain name bitcoinexchange.com and will start
> coding the service sometime soon as a nice leisure activity. I'm
> envisioning a simple Google-like interface with no registration and only
> two texts fields on the front page, where you insert the amount of money
> you wish to trade, and either your PayPal address to buy dollars or
> bitcoin address to buy bitcoins. On the next page you'll get a new
> bitcoin address for sending the coins or a check code for the PayPal
> transaction text.
>
> PayPal is good for the beginning - it's simple and has no startup costs,
> but later on I might accept credit cards also.
>
> Do you still need the maintenance account? It's ok if you do, but change
> the password to something else.
>
> 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.
I'd also need at least the command line tools to check if coins have
been received and to send coins. It would require some way to
communicate with the Bitcoin process running in the background. I
don't know how that should be done, maybe with something RPC related.
It would also be great if the background process was non-graphical -
the VPS on the current service level doesn't have enough memory to run
the X Windowing environment, unless I come up with some ways to free
memory.
> Are you going to manually review and enter orders, at least to begin
> with? I sure would.
Yes, at least to begin with, when the customer sells bc's and receives
dollars. I wouldn't give a script the access to my dollar reserves so
lightly. The other way around (customer's dollars -> bitcoins) it
doesn't feel that insecure, and it's certainly nicer for the customer
to receive his bitcoins immediately.
> mmalmi@cc.hut.fi wrote:
>> I have registered the domain name bitcoinexchange.com and will
>> start coding the service sometime soon as a nice leisure activity.
>> I'm envisioning a simple Google-like interface with no registration
>> and only two texts fields on the front page, where you insert the
>> amount of money you wish to trade, and either your PayPal address
>> to buy dollars or bitcoin address to buy bitcoins. On the next page
>> you'll get a new bitcoin address for sending the coins or a check
>> code for the PayPal transaction text.
>>
>> PayPal is good for the beginning - it's simple and has no startup
>> costs, but later on I might accept credit cards also.
>>
>> Do you still need the maintenance account? It's ok if you do, but
>> change the password to something else.
>>
mmalmi@cc.hut.fi wrote:
> I'd also need at least the command line tools to check if coins have
> been received and to send coins. It would require some way to
> communicate with the Bitcoin process running in the background. I don't
> know how that should be done, maybe with something RPC related.
>
> It would also be great if the background process was non-graphical - the
> VPS on the current service level doesn't have enough memory to run the X
> Windowing environment, unless I come up with some ways to free memory.
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.
> How much memory do you have to work with?
The VPS has 320MB RAM, 50MB of which is currently free. There's also
500MB swap space.
> Bitcoin necessarily takes a
> fair bit of memory; about 75MB on Windows. Is that a problem?
Sure about that? Windows task manager shows about 13MB memory usage here.
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.
mmalmi@cc.hut.fi wrote:
>> How much memory do you have to work with?
> The VPS has 320MB RAM, 50MB of which is currently free. There's also
> 500MB swap space.
>
>> Bitcoin necessarily takes a
>> fair bit of memory; about 75MB on Windows. Is that a problem?
>
> Sure about that? Windows task manager shows about 13MB memory usage here.
>
I have a prototype of the bitcoinexchange.com service up now (auth:
bitcoin/bit). It's running on the Python-powered Django web
application framework, which is a pleasure to work with, compared to
php.
I'll have to do some studying for a few days now, after which I can
return to work with the exchange service. Among other things I'll fix
the pricing so that the price of Bitcoins grows towards infinity when
my supply of them gets closer to zero. That way I can find the market
rate and stay at the point where supply meets demand. I'm not yet
completely sure what the parameters of the hyperbolic pricing curve
should be, so that's something to think about.
Have you decided upon the inter-process calling method of the Bitcoin
API yet? An easy solution would be the socket interface provided by
wxWidgets: http://docs.wxwidgets.org/trunk/overview_ipc.html. The
Bitcoin program running a wxServer could be then accessed by calling
the bitcoin executable from the command line or by coding your own
wxClient app.
Another option would be to just use the plain BSD sockets.
Can you send me a 64-bit Linux binary of Bitcoin if you have one? I
tried compiling on the VPS, but it ran out of memory. Tried the 32-bit
version (with ia32-libs) also, but it didn't find the shared libraries.
Is there any way to find out what the missing shared libraries are? It
would help to know.
It probably needs the gtk libraries, in which case you'll have the same
problem with the 64-bit version. I would like to have a single
executable that can also run on a UI-less system, but I'm not sure how
on linux to link to things but still be able to run and not use them if
the library is not present. Maybe we should statically link the GTK.
Licensewise, it's LGPL, but since it's only used on unix, that would be
OK. (we can't link LGPL stuff on windows because we provide the OpenSSL
DLL, but on linux OpenSSL comes with the OS)
My 64-bit (debug stripped) executable is attached. It includes untested
changes that are not in SVN yet: UI changes and the wallet fSpent flag
resync stuff.
I've been researching options for interprocess calling. I want
something that will be easy for a variety of server side languages to
call, particularly PHP. Cross-platform to windows is a plus.
I'm not sure if I want it to be something that can be accessed across
the network. That would introduce security issues. If it can only be
accessed on the local system, then local security authentication covers
it, and it is incapable of being hacked remotely.
At surface level, not looking into any details yet, the current front
runners are:
D-Bus:
local system only
used by qt, gnome and skype
bindings: c, python, java, c++,
php listed as "in progress"
.net listed as unmaintained
not sure how ready it is on windows
XML-RPC:
widely used, built in libraries on PHP
it's more for web clients to talk to server, transport is http, so
its a security question
Is it possible to open a socket that can only be accessed locally?
mmalmi@cc.hut.fi wrote:
> Have you decided upon the inter-process calling method of the Bitcoin
> API yet? An easy solution would be the socket interface provided by
> wxWidgets: http://docs.wxwidgets.org/trunk/overview_ipc.html. The
> Bitcoin program running a wxServer could be then accessed by calling the
> bitcoin executable from the command line or by coding your own wxClient
> app.
>
> Another option would be to just use the plain BSD sockets.
>
> Can you send me a 64-bit Linux binary of Bitcoin if you have one? I
> tried compiling on the VPS, but it ran out of memory. Tried the 32-bit
> version (with ia32-libs) also, but it didn't find the shared libraries.
>
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Thu, 04 Feb
2010 01:32:50 +0000 Subject: Exchange options
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)
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Thu, 04 Feb
2010 02:20:10 +0000 Subject: Exchange ideas
You could always exchange for Liberty Reserve. It's an online currency
similar to e-Bullion, Pecunix or Webmoney that allows exchanges no
questions asked and with privacy.
LR and the others are hard to buy but easy to cash out. Hard to buy
because exchangers are very cautious about getting ripped off by
reversed payments, so they require more details and holding time.
Cashing out is very easy. LR is non-reversible, so there are oodles of
exchanges eager to turn LR into any kind of payment.
Bitcoin is the reverse, in that it's easy to get Bitcoins just by
generating them. It would be easy for customers to go
bitcoin->LR->cash, bitcoin->LR->gold, bitcoin->LR->paypal or maybe they
just want to save the money, then just bitcoin->LR.
There's also the idea BTC2PSC had to sell paysafecards for bitcoins.
Either online delivery by sending the card number by e-mail, or delivery
of the unopened physical card in the mails. There are many variations
of these cards. In some countries, they're called Gift Cards, and can
be used wherever credit cards are accepted. I think they're used more
by people who don't have the credit history to get a real credit card,
so they buy gift cards themselves to pay for things that require a
credit card.
I must have accidentally typed j instead of z. It's bz2 format. Rename
to .tar.bz2 or just do tar -jxvf
> The package doesn't open, it says "not in gzip format".
>
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Thu, 04 Feb
2010 19:33:26 +0000 Subject: UTF-8 to ANSI hack in
CAboutDialog
What was the reason for this change?
#if !wxUSE_UNICODE
...
if (str.Find('Â') != wxNOT_FOUND)
str.Remove(str.Find('Â'), 1);
to:
if (str.Find('�') != wxNOT_FOUND)
str.Remove(str.Find('�'), 1);
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.
> Is there any way to find out what the missing shared libraries are? It
> would help to know.
This is what "ldd bitcoin" says:
linux-gate.so.1 => (0xf778c000)
libcrypto.so.0.9.8 => /usr/lib32/i686/cmov/libcrypto.so.0.9.8
(0xf762a000)
libgtk-x11-2.0.so.0 => not found
libgthread-2.0.so.0 => not found
libSM.so.6 => /usr/lib32/libSM.so.6 (0xf7621000)
libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7533000)
libm.so.6 => /lib32/libm.so.6 (0xf750f000)
libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf7502000)
libc.so.6 => /lib32/libc.so.6 (0xf73b0000)
libdl.so.2 => /lib32/libdl.so.2 (0xf73ac000)
libgdk-x11-2.0.so.0 => not found
libXinerama.so.1 => /usr/lib32/libXinerama.so.1 (0xf73a8000)
libgdk_pixbuf-2.0.so.0 => not found
libX11.so.6 => /usr/lib32/libX11.so.6 (0xf72b9000)
libpango-1.0.so.0 => not found
libgobject-2.0.so.0 => not found
libglib-2.0.so.0 => not found
libpthread.so.0 => /lib32/libpthread.so.0 (0xf72a1000)
libpng12.so.0 => /usr/lib32/libpng12.so.0 (0xf727e000)
libz.so.1 => /usr/lib32/libz.so.1 (0xf7269000)
libICE.so.6 => /usr/lib32/libICE.so.6 (0xf7251000)
/lib/ld-linux.so.2 (0xf778d000)
libXext.so.6 => /usr/lib32/libXext.so.6 (0xf7243000)
libxcb-xlib.so.0 => /usr/lib32/libxcb-xlib.so.0 (0xf7241000)
libxcb.so.1 => /usr/lib32/libxcb.so.1 (0xf7229000)
libXau.so.6 => /usr/lib32/libXau.so.6 (0xf7226000)
libXdmcp.so.6 => /usr/lib32/libXdmcp.so.6 (0xf7220000)
Notfounds seem to be gtk-libraries indeed. I have those files in my
/usr/lib folder, but maybe they're ignored because they're 64bit, or
maybe only /usr/lib32 is searched. I haven't tested on other 64bit
machines.
> My 64-bit (debug stripped) executable is attached. It includes
> untested changes that are not in SVN yet: UI changes and the wallet
> fSpent flag resync stuff.
The package doesn't open, it says "not in gzip format".
> Is it possible to open a socket that can only be accessed locally?
Yes, you can use IPC sockets ("Unix domain sockets") which are local
only. That's done in the wx-api by using a filename in place of a port
number. I committed an example of how the wxServer-Client
communication is used, you can revert if you want to. Now there's the
-blockamount command line option which asks the running instance for
the block chain length.
I think this command line method could already be used from PHP, but
it might be lighter if php itself could call the socket server
directly. The wx's IPC overview mentions wxSocketEvent, wxSocketBase,
wxSocketClient and wxSocketServer as being "Classes for the low-level
TCP/IP API", which might be easier to use from php than what I used
now (wxServer, wxClient, wxConnection). I'll look more into it.
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.
>> Is it possible to open a socket that can only be accessed locally?
>
> Yes, you can use IPC sockets ("Unix domain sockets") which are local
> only. That's done in the wx-api by using a filename in place of a port
> number. I committed an example of how the wxServer-Client communication
> is used, you can revert if you want to. Now there's the -blockamount
> command line option which asks the running instance for the block chain
> length.
>
> I think this command line method could already be used from PHP, but it
> might be lighter if php itself could call the socket server directly.
> The wx's IPC overview mentions wxSocketEvent, wxSocketBase,
> wxSocketClient and wxSocketServer as being "Classes for the low-level
> TCP/IP API", which might be easier to use from php than what I used now
> (wxServer, wxClient, wxConnection). I'll look more into it.
>
>
>
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Fri, 05 Feb
2010 04:08:54 +0000 Subject: Re: Bitcoin API research
status
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.
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Fri, 05 Feb 2010 09:16:23 +0200
Subject: Re: UTF-8 to ANSI hack in CAboutDialog
I didn't change it knowingly, must have been some encoding problem.
> What was the reason for this change?
>
> #if !wxUSE_UNICODE
> ...
> if (str.Find('Â') != wxNOT_FOUND)
> str.Remove(str.Find('Â'), 1);
> to:
> if (str.Find('�') != wxNOT_FOUND)
> str.Remove(str.Find('�'), 1);
>
> 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.
Liberty Reserve sounds good. I could first make a service that only
accepts LR, and add more options later. The weakness is that buying LR
is an extra step of inconvenience when the customer just wants to get
Bitcoins. But maybe I don't have too much choice here.
> Do you have electronic transfer or paper cheque in your country? (even
> if only within Europe)
Yes, electronic bank transfer is available. During 2010 most European
countries will become a part of SEPA (Single Euro Payments Area),
which means that all payments within Europe are to be considered
domestic. Banks will have to apply the same fees and standards to all
domestic transfers, so they'll probably all be free of charge and
complete in one bank day. For international transfers there's the
SWIFT/IBAN system, which usually costs some extra.
A longer term project for my exchange service would be to see what
kinds of integration options the banks have to offer. Bank transfers
would reach nearly as many customers as credit cards do.
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->LR or anything
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.
mmalmi@cc.hut.fi wrote:
> Liberty Reserve sounds good. I could first make a service that only
> accepts LR, and add more options later. The weakness is that buying LR
> is an extra step of inconvenience when the customer just wants to get
> Bitcoins. But maybe I don't have too much choice here.
>
>> Do you have electronic transfer or paper cheque in your country? (even
>> if only within Europe)
>
> Yes, electronic bank transfer is available. During 2010 most European
> countries will become a part of SEPA (Single Euro Payments Area), which
> means that all payments within Europe are to be considered domestic.
> Banks will have to apply the same fees and standards to all domestic
> transfers, so they'll probably all be free of charge and complete in one
> bank day. For international transfers there's the SWIFT/IBAN system,
> which usually costs some extra.
>
> A longer term project for my exchange service would be to see what kinds
> of integration options the banks have to offer. Bank transfers would
> reach nearly as many customers as credit cards do.
>
From: Satoshi Nakamoto satoshin@gmx.comTo: mmalmi@cc.hut.fiDate: Fri, 05 Feb
2010 18:39:18 +0000 Subject: Re: UTF-8 to ANSI hack in
CAboutDialog
Right, I'll change it to this so it doesn't get broken again:
if (str.Find('\xC2') != wxNOT_FOUND)
str.Remove(str.Find('\xC2'), 1);
mmalmi@cc.hut.fi wrote:
> I didn't change it knowingly, must have been some encoding problem.
>
>> What was the reason for this change?
>>
>> #if !wxUSE_UNICODE
>> ...
>> if (str.Find('Â') != wxNOT_FOUND)
>> str.Remove(str.Find('Â'), 1);
>> to:
>> if (str.Find('�') != wxNOT_FOUND)
>> str.Remove(str.Find('�'), 1);
>>
>> 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.
>
>
>
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Sun, 07 Feb
2010 06:12:04 +0000 Subject: JSON-RPC status
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.
That's great! I'll start familiarizing myself with Liberty Reserve and
its api.
> 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.
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Mon, 08 Feb
2010 15:28:52 +0000 Subject: Translation
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.
Drupal supports multiple languages. I didn't yet figure out how to
make it automatically show the translation at bitcoin.org/zh-hans
though.
> 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 got the translations working correctly, now it should automatically
detect the language from the browser settings. Choosing manually is of
course also possible. I asked the translators to send me their
translations as pm or e-mail. I guess I'll make a Finnish translation
myself at some point. Multiple translations add to the site's
credibility.
Drupal is asking to do a security update. Do we have other customized
files we need to backup than those located in the "sites" directory?
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.
mmalmi@cc.hut.fi wrote:
> I got the translations working correctly, now it should automatically
> detect the language from the browser settings. Choosing manually is of
> course also possible. I asked the translators to send me their
> translations as pm or e-mail. I guess I'll make a Finnish translation
> myself at some point. Multiple translations add to the site's credibility.
>
> Drupal is asking to do a security update. Do we have other customized
> files we need to backup than those located in the "sites" directory?
>
I'm not too worried about that, since I'm not doing anything illegal,
even with my exchange service. If I were, it wouldn't help me that I'm
only offering the service for foreigners. Things may of course be
different under other jurisdictions, but that's how it is in my
country. The law monopoly here is less uncivilized than many others.
> 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:
bitcoin getblockcount
bitcoin getdifficulty
bitcoin getnewaddress somelabel
bitcoin sendtoaddress 1DvqsbZ... 1.00
bitcoin getallpayments 0
bitcoin stop
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.
mmalmi@cc.hut.fi wrote:
> That's great! I'll start familiarizing myself with Liberty Reserve and
> its api.
>
>> 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.
>
>
>
> 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.
Yes, using Python. I didn't test the JSON-RPC yet as I don't have
Bitcoin running on the vps yet. It doesn't work without a window
manager even if GTK libraries are installed. I asked about it at
wxWidgets forum (http://wxforum.shadonet.com/viewtopic.php?t=26954)
but they didn't have much clue. Maybe we'll just need to make two
different binaries.
I'm moving in the direction of making transactions automated only when
the customer buys coins with SMS payment provided by ZayPay. Pecunix
is the only reliable and practical enough e-currency that I'd store my
reserves in, but the exchange fees are quite high (about 5%).
When I'm buying coins, my recommended payment method would be IBAN
transfer. I could also say "contact us if you want to buy/sell with
any other payment option" and handle each order separately. I could
manually accept single orders with even PayPal, as long as I don't
store my money there and the customer pays the fees.
mmalmi@cc.hut.fi wrote:
>> 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.
>
> Yes, using Python. I didn't test the JSON-RPC yet as I don't have
> Bitcoin running on the vps yet. It doesn't work without a window manager
> even if GTK libraries are installed. I asked about it at wxWidgets forum
> (http://wxforum.shadonet.com/viewtopic.php?t=26954) but they didn't have
> much clue. Maybe we'll just need to make two different binaries.
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?
> Don't you have an Ubuntu laptop you can test and compile on so you
> don't have to toy with the vps?
Yes. Tested with Python's JSON-RPC, and seems to work fine! Really
easy to use.
mmalmi@cc.hut.fi wrote:
>> Don't you have an Ubuntu laptop you can test and compile on so you
>> don't have to toy with the vps?
>
> Yes. Tested with Python's JSON-RPC, and seems to work fine! Really easy
> to use.
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.
> mmalmi@cc.hut.fi wrote:
>>> Don't you have an Ubuntu laptop you can test and compile on so you
>>> don't have to toy with the vps?
>>
>> Yes. Tested with Python's JSON-RPC, and seems to work fine! Really
>> easy to use.
>
> 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.
Just downloaded the python-json-rpc
(http://json-rpc.org/wiki/python-json-rpc) from their svn and tested
by talking to the Python interpreter directly. Like this:
pythons = ServiceProxy("http://localhost:8332")
s.getblockcount()
Just a few clues I've found about running the same binary without a GUI:
1) GTK supports running a program without display:
http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check. This
doesn't tell if it's possible in wxWidgets though.
2) wxAppConsole of wx 2.9 might be useful somehow. Just replacing
wxApp with wxAppConsole doesn't work, I'm not sure how it should be
used. It's not very well documented.
3) Another option might be to use IMPLEMENT_APP_NO_MAIN() and make our
own main method.
mmalmi@cc.hut.fi wrote:
> Just a few clues I've found about running the same binary without a GUI:
>
> 1) GTK supports running a program without display:
> http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check.
> This doesn't tell if it's possible in wxWidgets though.
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)
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Tue, 23 Feb
2010 01:41:01 +0000 Subject: Re: Non-GUI option
>> Just a few clues I've found about running the same binary without a GUI:
>>
>> 1) GTK supports running a program without display:
>> http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check.
>> This doesn't tell if it's possible in wxWidgets though.
>
> 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.
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?
> mmalmi@cc.hut.fi wrote:
>> Just a few clues I've found about running the same binary without a GUI:
>>
>> 1) GTK supports running a program without display:
>> http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check.
>> This doesn't tell if it's possible in wxWidgets though.
>
> 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)
That seems good, I don't know of any standards about it.
>>> Just a few clues I've found about running the same binary without a GUI:
>>>
>>> 1) GTK supports running a program without display:
>>> http://library.gnome.org/devel/gtk/2.12/gtk-General.html#gtk-init-check.
>>> This doesn't tell if it's possible in wxWidgets though.
>>
>> 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.
>
> 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?
It was probably apt-get install libgtk2.0-0. You can search for
available packages like this: "apt-cache search libgtk".
I'll give Drupal accounts to the bitcoin.org translators, so they can
keep the translations up to date.
> I'll give Drupal accounts to the bitcoin.org translators, so they can
> keep the translations up to date.
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 tried debugging my build of bitcoind with ddd debugger, but didn't
have much success yet. It always ends up taking all the system's
memory and finally crashes. Could you please send me again the latest
64 bit build of bitcoind, so I can see if the problem is about my build?
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.
in util.cpp, old:
const char* wxGetTranslation(const char* pszEnglish)
{
// Wrapper of wxGetTranslation returning the same const char* type
as was passed in
static CCriticalSection cs;
CRITICAL_BLOCK(cs)
{
// Look in cache
static map<string, char*> mapCache;
map<string, char*>::iterator mi = mapCache.find(pszEnglish);
if (mi != mapCache.end())
return (*mi).second;
// wxWidgets translation
const char* pszTranslated =
wxGetTranslation(wxString(pszEnglish, wxConvUTF8)).utf8_str();
// We don't cache unknown strings because caller might be
passing in a
// dynamic string and we would keep allocating memory for each
variation.
if (strcmp(pszEnglish, pszTranslated) == 0)
return pszEnglish;
// Add to cache, memory doesn't need to be freed. We only
cache because
// we must pass back a pointer to permanently allocated memory.
char* pszCached = new char[strlen(pszTranslated)+1];
strcpy(pszCached, pszTranslated);
mapCache[pszEnglish] = pszCached;
return pszCached;
}
return NULL;
}
new:
const char* wxGetTranslation(const char* pszEnglish)
{
// Wrapper of wxGetTranslation returning the same const char* type
as was passed in
static CCriticalSection cs;
CRITICAL_BLOCK(cs)
{
// Look in cache
static map<string, char*> mapCache;
map<string, char*>::iterator mi = mapCache.find(pszEnglish);
if (mi != mapCache.end())
return (*mi).second;
// wxWidgets translation
wxString strTranslated = wxGetTranslation(wxString(pszEnglish,
wxConvUTF8));
// We don't cache unknown strings because caller might be
passing in a
// dynamic string and we would keep allocating memory for each
variation.
if (strcmp(pszEnglish, strTranslated.utf8_str()) == 0)
return pszEnglish;
// Add to cache, memory doesn't need to be freed. We only
cache because
// we must pass back a pointer to permanently allocated memory.
char* pszCached = new char[strlen(strTranslated.utf8_str())+1];
strcpy(pszCached, strTranslated.utf8_str());
mapCache[pszEnglish] = pszCached;
return pszCached;
}
return NULL;
}
If you still suspect this code, for testing you could change it to:
const char* wxGetTranslation(const char* pszEnglish)
{
return pszEnglish;
}
mmalmi@cc.hut.fi wrote:
> I tried debugging my build of bitcoind with ddd debugger, but didn't
> have much success yet. It always ends up taking all the system's memory
> and finally crashes. Could you please send me again the latest 64 bit
> build of bitcoind, so I can see if the problem is about my build?
>
Could you send me the debug.log?
mmalmi@cc.hut.fi wrote:
> I tried debugging my build of bitcoind with ddd debugger, but didn't
> have much success yet. It always ends up taking all the system's memory
> and finally crashes. Could you please send me again the latest 64 bit
> build of bitcoind, so I can see if the problem is about my build?
>
Here goes. I forgot to mention the crash error message:
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc
> Could you send me the debug.log?
>
> mmalmi@cc.hut.fi wrote:
>> I tried debugging my build of bitcoind with ddd debugger, but
>> didn't have much success yet. It always ends up taking all the
>> system's memory and finally crashes. Could you please send me again
>> the latest 64 bit build of bitcoind, so I can see if the problem
>> is about my build?
>>
This was from the compilation you sent, the same problem occurred with it.
> Here goes. I forgot to mention the crash error message:
>
> terminate called after throwing an instance of 'std::bad_alloc'
> what(): std::bad_alloc
>
>> Could you send me the debug.log?
>>
>> mmalmi@cc.hut.fi wrote:
>>> I tried debugging my build of bitcoind with ddd debugger, but
>>> didn't have much success yet. It always ends up taking all the
>>> system's memory and finally crashes. Could you please send me
>>> again the latest 64 bit build of bitcoind, so I can see if the
>>> problem is about my build?
>>>
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.
net.cpp, under // Start threads
CreateThread(ThreadIRCSeed, NULL)
CreateThread(ThreadSocketHandler, NULL, true)
CreateThread(ThreadOpenConnections, NULL)
CreateThread(ThreadMessageHandler, NULL)
init.cpp:
CreateThread(ThreadRPCServer, NULL);
mmalmi@cc.hut.fi wrote:
> Here goes. I forgot to mention the crash error message:
>
> terminate called after throwing an instance of 'std::bad_alloc'
> what(): std::bad_alloc
>
>> Could you send me the debug.log?
>>
>> mmalmi@cc.hut.fi wrote:
>>> I tried debugging my build of bitcoind with ddd debugger, but didn't
>>> have much success yet. It always ends up taking all the system's
>>> memory and finally crashes. Could you please send me again the
>>> latest 64 bit build of bitcoind, so I can see if the problem is
>>> about my build?
>>>
>
>
>
I get the error regardless of the getinfo. Commenting out
ThreadIRCSeed fixed the problem.
> 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.
>
> net.cpp, under // Start threads
> CreateThread(ThreadIRCSeed, NULL)
> CreateThread(ThreadSocketHandler, NULL, true)
> CreateThread(ThreadOpenConnections, NULL)
> CreateThread(ThreadMessageHandler, NULL)
>
> init.cpp:
> CreateThread(ThreadRPCServer, NULL);
>
> mmalmi@cc.hut.fi wrote:
>> Here goes. I forgot to mention the crash error message:
>>
>> terminate called after throwing an instance of 'std::bad_alloc'
>> what(): std::bad_alloc
>>
>>> Could you send me the debug.log?
>>>
>>> mmalmi@cc.hut.fi wrote:
>>>> I tried debugging my build of bitcoind with ddd debugger, but
>>>> didn't have much success yet. It always ends up taking all the
>>>> system's memory and finally crashes. Could you please send me
>>>> again the latest 64 bit build of bitcoind, so I can see if the
>>>> problem is about my build?
>>>>
>>
>>
>>
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
gdb --args bitcoin [switches]
b ThreadIRCSeed
run
step
or u to step over and up out of routines.
mmalmi@cc.hut.fi wrote:
> I get the error regardless of the getinfo. Commenting out ThreadIRCSeed
> fixed the problem.
>
>> 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.
>>
>> net.cpp, under // Start threads
>> CreateThread(ThreadIRCSeed, NULL)
>> CreateThread(ThreadSocketHandler, NULL, true)
>> CreateThread(ThreadOpenConnections, NULL)
>> CreateThread(ThreadMessageHandler, NULL)
>>
>> init.cpp:
>> CreateThread(ThreadRPCServer, NULL);
>>
>> mmalmi@cc.hut.fi wrote:
>>> Here goes. I forgot to mention the crash error message:
>>>
>>> terminate called after throwing an instance of 'std::bad_alloc'
>>> what(): std::bad_alloc
>>>
>>>> Could you send me the debug.log?
>>>>
>>>> mmalmi@cc.hut.fi wrote:
>>>>> I tried debugging my build of bitcoind with ddd debugger, but
>>>>> didn't have much success yet. It always ends up taking all the
>>>>> system's memory and finally crashes. Could you please send me
>>>>> again the latest 64 bit build of bitcoind, so I can see if the
>>>>> problem is about my build?
>>>>>
>>>
>>>
>>>
>
>
>
debug.log attached
> 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
> gdb --args bitcoin [switches]
> b ThreadIRCSeed
> run
> step
> or u to step over and up out of routines.
>
> mmalmi@cc.hut.fi wrote:
>> I get the error regardless of the getinfo. Commenting out
>> ThreadIRCSeed fixed the problem.
>>
>>> 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.
>>>
>>> net.cpp, under // Start threads
>>> CreateThread(ThreadIRCSeed, NULL)
>>> CreateThread(ThreadSocketHandler, NULL, true)
>>> CreateThread(ThreadOpenConnections, NULL)
>>> CreateThread(ThreadMessageHandler, NULL)
>>>
>>> init.cpp:
>>> CreateThread(ThreadRPCServer, NULL);
>>>
>>> mmalmi@cc.hut.fi wrote:
>>>> Here goes. I forgot to mention the crash error message:
>>>>
>>>> terminate called after throwing an instance of 'std::bad_alloc'
>>>> what(): std::bad_alloc
>>>>
>>>>> Could you send me the debug.log?
>>>>>
>>>>> mmalmi@cc.hut.fi wrote:
>>>>>> I tried debugging my build of bitcoind with ddd debugger, but
>>>>>> didn't have much success yet. It always ends up taking all the
>>>>>> system's memory and finally crashes. Could you please send
>>>>>> me again the latest 64 bit build of bitcoind, so I can see
>>>>>> if the problem is about my build?
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
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.
mmalmi@cc.hut.fi wrote:
> debug.log attached
>
>> 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
>> gdb --args bitcoin [switches]
>> b ThreadIRCSeed
>> run
>> step
>> or u to step over and up out of routines.
>>
>> mmalmi@cc.hut.fi wrote:
>>> I get the error regardless of the getinfo. Commenting out
>>> ThreadIRCSeed fixed the problem.
>>>
>>>> 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.
>>>>
>>>> net.cpp, under // Start threads
>>>> CreateThread(ThreadIRCSeed, NULL)
>>>> CreateThread(ThreadSocketHandler, NULL, true)
>>>> CreateThread(ThreadOpenConnections, NULL)
>>>> CreateThread(ThreadMessageHandler, NULL)
>>>>
>>>> init.cpp:
>>>> CreateThread(ThreadRPCServer, NULL);
>>>>
>>>> mmalmi@cc.hut.fi wrote:
>>>>> Here goes. I forgot to mention the crash error message:
>>>>>
>>>>> terminate called after throwing an instance of 'std::bad_alloc'
>>>>> what(): std::bad_alloc
>>>>>
>>>>>> Could you send me the debug.log?
>>>>>>
>>>>>> mmalmi@cc.hut.fi wrote:
>>>>>>> I tried debugging my build of bitcoind with ddd debugger, but
>>>>>>> didn't have much success yet. It always ends up taking all the
>>>>>>> system's memory and finally crashes. Could you please send
>>>>>>> me again the latest 64 bit build of bitcoind, so I can see if
>>>>>>> the problem is about my build?
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
Re: Introduction
Jon Matonis correspondence (Satoshi Nakamoto) — March 04, 2010 — source: jon-matonis.html
From: Satoshi Nakamoto <[email redacted]>
Subject: Re: Introduction
To: “Jon Matonis” <[email redacted]>
Date: Thursday, March 4, 2010, 9:55 PM
Nice blog. That’s the first I’ve seen that focuses on this subject. I wish there was something like that when I originally researched this three years ago, there was scant to nothing back then. I think I’ll be a regular reader.
Bitcoin would be right up your alley. Its advantage is that it’s P2P. There isn’t a central mint or company running it. As long as there are users, it survives.
I’m sure you’ve already found the FAQ and Forum at bitcoin.org.
The logo is here:
http://www.bitcoin.o….php?topic=64.0
Was there anything particular you were interested in?
Here's the debug.log. I stopped bitcoind before it took up all the memory.
> 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.
>
> mmalmi@cc.hut.fi wrote:
>> debug.log attached
>>
>>> 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
>>> gdb --args bitcoin [switches]
>>> b ThreadIRCSeed
>>> run
>>> step
>>> or u to step over and up out of routines.
>>>
>>> mmalmi@cc.hut.fi wrote:
>>>> I get the error regardless of the getinfo. Commenting out
>>>> ThreadIRCSeed fixed the problem.
>>>>
>>>>> 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.
>>>>>
>>>>> net.cpp, under // Start threads
>>>>> CreateThread(ThreadIRCSeed, NULL)
>>>>> CreateThread(ThreadSocketHandler, NULL, true)
>>>>> CreateThread(ThreadOpenConnections, NULL)
>>>>> CreateThread(ThreadMessageHandler, NULL)
>>>>>
>>>>> init.cpp:
>>>>> CreateThread(ThreadRPCServer, NULL);
>>>>>
>>>>> mmalmi@cc.hut.fi wrote:
>>>>>> Here goes. I forgot to mention the crash error message:
>>>>>>
>>>>>> terminate called after throwing an instance of 'std::bad_alloc'
>>>>>> what(): std::bad_alloc
>>>>>>
>>>>>>> Could you send me the debug.log?
>>>>>>>
>>>>>>> mmalmi@cc.hut.fi wrote:
>>>>>>>> I tried debugging my build of bitcoind with ddd debugger, but
>>>>>>>> didn't have much success yet. It always ends up taking
>>>>>>>> all the system's memory and finally crashes. Could you
>>>>>>>> please send me again the latest 64 bit build of bitcoind,
>>>>>>>> so I can see if the problem is about my build?
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
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".
old:
void ParseString(const string& str, char c, vector<string>& v)
{
unsigned int i1 = 0;
unsigned int i2;
do
{
i2 = str.find(c, i1);
v.push_back(str.substr(i1, i2-i1));
i1 = i2+1;
}
while (i2 != str.npos);
}
new:
void ParseString(const string& str, char c, vector<string>& v)
{
size_type i1 = 0;
size_type i2;
do
{
i2 = str.find(c, i1);
v.push_back(str.substr(i1, i2-i1));
i1 = i2+1;
}
while (i2 != str.npos);
}
mmalmi@cc.hut.fi wrote:
> Here's another test run debug.log I got when debugging with gdb. The
> program started eating memory after the debug line "irc 8" and within a
> few seconds crashed with "terminate called after throwing an instance of
> 'std::bad_alloc'".
>
>> 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.
>>
>> mmalmi@cc.hut.fi wrote:
>>> debug.log attached
>>>
>>>> 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
>>>> gdb --args bitcoin [switches]
>>>> b ThreadIRCSeed
>>>> run
>>>> step
>>>> or u to step over and up out of routines.
>>>>
>>>> mmalmi@cc.hut.fi wrote:
>>>>> I get the error regardless of the getinfo. Commenting out
>>>>> ThreadIRCSeed fixed the problem.
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> net.cpp, under // Start threads
>>>>>> CreateThread(ThreadIRCSeed, NULL)
>>>>>> CreateThread(ThreadSocketHandler, NULL, true)
>>>>>> CreateThread(ThreadOpenConnections, NULL)
>>>>>> CreateThread(ThreadMessageHandler, NULL)
>>>>>>
>>>>>> init.cpp:
>>>>>> CreateThread(ThreadRPCServer, NULL);
>>>>>>
>>>>>> mmalmi@cc.hut.fi wrote:
>>>>>>> Here goes. I forgot to mention the crash error message:
>>>>>>>
>>>>>>> terminate called after throwing an instance of 'std::bad_alloc'
>>>>>>> what(): std::bad_alloc
>>>>>>>
>>>>>>>> Could you send me the debug.log?
>>>>>>>>
>>>>>>>> mmalmi@cc.hut.fi wrote:
>>>>>>>>> I tried debugging my build of bitcoind with ddd debugger, but
>>>>>>>>> didn't have much success yet. It always ends up taking all
>>>>>>>>> the system's memory and finally crashes. Could you please
>>>>>>>>> send me again the latest 64 bit build of bitcoind, so I can
>>>>>>>>> see if the problem is about my build?
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
Actually, please try this instead, this is more correct:
void ParseString(const string& str, char c, vector<string>& v)
{
string::size_type i1 = 0;
string::size_type i2;
loop
{
i2 = str.find(c, i1);
if (i2 == str.npos)
{
v.push_back(str.substr(i1));
return;
}
v.push_back(str.substr(i1, i2-i1));
i1 = i2+1;
}
}
Satoshi Nakamoto wrote:
> 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".
>
> old:
> void ParseString(const string& str, char c, vector<string>& v)
> {
> unsigned int i1 = 0;
> unsigned int i2;
> do
> {
> i2 = str.find(c, i1);
> v.push_back(str.substr(i1, i2-i1));
> i1 = i2+1;
> }
> while (i2 != str.npos);
> }
>
> new:
> void ParseString(const string& str, char c, vector<string>& v)
> {
> size_type i1 = 0;
> size_type i2;
> do
> {
> i2 = str.find(c, i1);
> v.push_back(str.substr(i1, i2-i1));
> i1 = i2+1;
> }
> while (i2 != str.npos);
> }
>
>
> mmalmi@cc.hut.fi wrote:
>> Here's another test run debug.log I got when debugging with gdb. The
>> program started eating memory after the debug line "irc 8" and within
>> a few seconds crashed with "terminate called after throwing an
>> instance of 'std::bad_alloc'".
>>
>>> 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.
>>>
>>> mmalmi@cc.hut.fi wrote:
>>>> debug.log attached
>>>>
>>>>> 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
>>>>> gdb --args bitcoin [switches]
>>>>> b ThreadIRCSeed
>>>>> run
>>>>> step
>>>>> or u to step over and up out of routines.
>>>>>
>>>>> mmalmi@cc.hut.fi wrote:
>>>>>> I get the error regardless of the getinfo. Commenting out
>>>>>> ThreadIRCSeed fixed the problem.
>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> net.cpp, under // Start threads
>>>>>>> CreateThread(ThreadIRCSeed, NULL)
>>>>>>> CreateThread(ThreadSocketHandler, NULL, true)
>>>>>>> CreateThread(ThreadOpenConnections, NULL)
>>>>>>> CreateThread(ThreadMessageHandler, NULL)
>>>>>>>
>>>>>>> init.cpp:
>>>>>>> CreateThread(ThreadRPCServer, NULL);
>>>>>>>
>>>>>>> mmalmi@cc.hut.fi wrote:
>>>>>>>> Here goes. I forgot to mention the crash error message:
>>>>>>>>
>>>>>>>> terminate called after throwing an instance of 'std::bad_alloc'
>>>>>>>> what(): std::bad_alloc
>>>>>>>>
>>>>>>>>> Could you send me the debug.log?
>>>>>>>>>
>>>>>>>>> mmalmi@cc.hut.fi wrote:
>>>>>>>>>> I tried debugging my build of bitcoind with ddd debugger, but
>>>>>>>>>> didn't have much success yet. It always ends up taking
>>>>>>>>>> all the system's memory and finally crashes. Could you
>>>>>>>>>> please send me again the latest 64 bit build of bitcoind,
>>>>>>>>>> so I can see if the problem is about my build?
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
>
>
I confirmed that ParseString has this problem, and uploaded the fixed
util.cpp to SVN.
string::npos == -1
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.
mmalmi@cc.hut.fi wrote:
> Here's another test run debug.log I got when debugging with gdb. The
> program started eating memory after the debug line "irc 8" and within a
> few seconds crashed with "terminate called after throwing an instance of
> 'std::bad_alloc'".
>
>> 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.
>>
>> mmalmi@cc.hut.fi wrote:
>>> debug.log attached
>>>
>>>> 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
>>>> gdb --args bitcoin [switches]
>>>> b ThreadIRCSeed
>>>> run
>>>> step
>>>> or u to step over and up out of routines.
>>>>
>>>> mmalmi@cc.hut.fi wrote:
>>>>> I get the error regardless of the getinfo. Commenting out
>>>>> ThreadIRCSeed fixed the problem.
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> net.cpp, under // Start threads
>>>>>> CreateThread(ThreadIRCSeed, NULL)
>>>>>> CreateThread(ThreadSocketHandler, NULL, true)
>>>>>> CreateThread(ThreadOpenConnections, NULL)
>>>>>> CreateThread(ThreadMessageHandler, NULL)
>>>>>>
>>>>>> init.cpp:
>>>>>> CreateThread(ThreadRPCServer, NULL);
>>>>>>
>>>>>> mmalmi@cc.hut.fi wrote:
>>>>>>> Here goes. I forgot to mention the crash error message:
>>>>>>>
>>>>>>> terminate called after throwing an instance of 'std::bad_alloc'
>>>>>>> what(): std::bad_alloc
>>>>>>>
>>>>>>>> Could you send me the debug.log?
>>>>>>>>
>>>>>>>> mmalmi@cc.hut.fi wrote:
>>>>>>>>> I tried debugging my build of bitcoind with ddd debugger, but
>>>>>>>>> didn't have much success yet. It always ends up taking all
>>>>>>>>> the system's memory and finally crashes. Could you please
>>>>>>>>> send me again the latest 64 bit build of bitcoind, so I can
>>>>>>>>> see if the problem is about my build?
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>
>
>
Here's another test run debug.log I got when debugging with gdb. The
program started eating memory after the debug line "irc 8" and within
a few seconds crashed with "terminate called after throwing an
instance of 'std::bad_alloc'".
> 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.
>
> mmalmi@cc.hut.fi wrote:
>> debug.log attached
>>
>>> 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
>>> gdb --args bitcoin [switches]
>>> b ThreadIRCSeed
>>> run
>>> step
>>> or u to step over and up out of routines.
>>>
>>> mmalmi@cc.hut.fi wrote:
>>>> I get the error regardless of the getinfo. Commenting out
>>>> ThreadIRCSeed fixed the problem.
>>>>
>>>>> 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.
>>>>>
>>>>> net.cpp, under // Start threads
>>>>> CreateThread(ThreadIRCSeed, NULL)
>>>>> CreateThread(ThreadSocketHandler, NULL, true)
>>>>> CreateThread(ThreadOpenConnections, NULL)
>>>>> CreateThread(ThreadMessageHandler, NULL)
>>>>>
>>>>> init.cpp:
>>>>> CreateThread(ThreadRPCServer, NULL);
>>>>>
>>>>> mmalmi@cc.hut.fi wrote:
>>>>>> Here goes. I forgot to mention the crash error message:
>>>>>>
>>>>>> terminate called after throwing an instance of 'std::bad_alloc'
>>>>>> what(): std::bad_alloc
>>>>>>
>>>>>>> Could you send me the debug.log?
>>>>>>>
>>>>>>> mmalmi@cc.hut.fi wrote:
>>>>>>>> I tried debugging my build of bitcoind with ddd debugger, but
>>>>>>>> didn't have much success yet. It always ends up taking
>>>>>>>> all the system's memory and finally crashes. Could you
>>>>>>>> please send me again the latest 64 bit build of bitcoind,
>>>>>>>> so I can see if the problem is about my build?
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>>>>
>>
>>
>>
Great! Works fine now.
> Actually, please try this instead, this is more correct:
>
> void ParseString(const string& str, char c, vector<string>& v)
> {
> string::size_type i1 = 0;
> string::size_type i2;
> loop
> {
> i2 = str.find(c, i1);
> if (i2 == str.npos)
> {
> v.push_back(str.substr(i1));
> return;
> }
> v.push_back(str.substr(i1, i2-i1));
> i1 = i2+1;
> }
> }
>
>
>
> Satoshi Nakamoto wrote:
>> 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".
>>
>> old:
>> void ParseString(const string& str, char c, vector<string>& v)
>> {
>> unsigned int i1 = 0;
>> unsigned int i2;
>> do
>> {
>> i2 = str.find(c, i1);
>> v.push_back(str.substr(i1, i2-i1));
>> i1 = i2+1;
>> }
>> while (i2 != str.npos);
>> }
>>
>> new:
>> void ParseString(const string& str, char c, vector<string>& v)
>> {
>> size_type i1 = 0;
>> size_type i2;
>> do
>> {
>> i2 = str.find(c, i1);
>> v.push_back(str.substr(i1, i2-i1));
>> i1 = i2+1;
>> }
>> while (i2 != str.npos);
>> }
>>
>>
>> mmalmi@cc.hut.fi wrote:
>>> Here's another test run debug.log I got when debugging with gdb.
>>> The program started eating memory after the debug line "irc 8" and
>>> within a few seconds crashed with "terminate called after
>>> throwing an instance of 'std::bad_alloc'".
>>>
>>>> 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.
>>>>
>>>> mmalmi@cc.hut.fi wrote:
>>>>> debug.log attached
>>>>>
>>>>>> 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
>>>>>> gdb --args bitcoin [switches]
>>>>>> b ThreadIRCSeed
>>>>>> run
>>>>>> step
>>>>>> or u to step over and up out of routines.
>>>>>>
>>>>>> mmalmi@cc.hut.fi wrote:
>>>>>>> I get the error regardless of the getinfo. Commenting out
>>>>>>> ThreadIRCSeed fixed the problem.
>>>>>>>
>>>>>>>> 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.
>>>>>>>>
>>>>>>>> net.cpp, under // Start threads
>>>>>>>> CreateThread(ThreadIRCSeed, NULL)
>>>>>>>> CreateThread(ThreadSocketHandler, NULL, true)
>>>>>>>> CreateThread(ThreadOpenConnections, NULL)
>>>>>>>> CreateThread(ThreadMessageHandler, NULL)
>>>>>>>>
>>>>>>>> init.cpp:
>>>>>>>> CreateThread(ThreadRPCServer, NULL);
>>>>>>>>
>>>>>>>> mmalmi@cc.hut.fi wrote:
>>>>>>>>> Here goes. I forgot to mention the crash error message:
>>>>>>>>>
>>>>>>>>> terminate called after throwing an instance of 'std::bad_alloc'
>>>>>>>>> what(): std::bad_alloc
>>>>>>>>>
>>>>>>>>>> Could you send me the debug.log?
>>>>>>>>>>
>>>>>>>>>> mmalmi@cc.hut.fi wrote:
>>>>>>>>>>> I tried debugging my build of bitcoind with ddd debugger,
>>>>>>>>>>> but didn't have much success yet. It always ends up
>>>>>>>>>>> taking all the system's memory and finally crashes.
>>>>>>>>>>> Could you please send me again the latest 64 bit build
>>>>>>>>>>> of bitcoind, so I can see if the problem is about my
>>>>>>>>>>> build?
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>>
>>>
>>
>>
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
http://themonetaryfuture.blogspot.com
Yes, I could do that.
> 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
> http://themonetaryfuture.blogspot.com
Hi!
How are you doing? Haven't seen you around in a while.
I've been at full-time work lately, and will be until the end of June,
so I haven't had that much time to work with Bitcoin or my exchange
service. I have a working beta of my service though, and a few weeks
ago made my first transaction: sold 10,000 btc for 20 euros via EU
bank transfer. Maybe I can make it public soon.
I divided the forum into 6 boards, which are Bitcoin Discussion,
Development & Technical Discussion, Technical support, Economics,
Marketplace and Trading Discussion. Hope this is ok?
I also added a page "Trade" on the bitcoin.org site, where
btc-accepting services are listed. It's nice to see that there are
already useful services that accept btc.
The community has been growing nicely. We've had around 10-20 people
and active discussion at #bitcoin-dev lately.
It would be nice to get the daemon-able binaries to SF.net. We have
some skilled programmers in the community now, so maybe we can finish
the JSON API functions if you don't have time to.
Best regards.
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.
mmalmi@cc.hut.fi wrote:
> Hi!
>
> How are you doing? Haven't seen you around in a while.
>
> I've been at full-time work lately, and will be until the end of June,
> so I haven't had that much time to work with Bitcoin or my exchange
> service. I have a working beta of my service though, and a few weeks ago
> made my first transaction: sold 10,000 btc for 20 euros via EU bank
> transfer. Maybe I can make it public soon.
>
> I divided the forum into 6 boards, which are Bitcoin Discussion,
> Development & Technical Discussion, Technical support, Economics,
> Marketplace and Trading Discussion. Hope this is ok?
>
> I also added a page "Trade" on the bitcoin.org site, where btc-accepting
> services are listed. It's nice to see that there are already useful
> services that accept btc.
>
> The community has been growing nicely. We've had around 10-20 people and
> active discussion at #bitcoin-dev lately.
>
> It would be nice to get the daemon-able binaries to SF.net. We have some
> skilled programmers in the community now, so maybe we can finish the
> JSON API functions if you don't have time to.
>
> Best regards.
>
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Tue, 22 Jun
2010 18:36:22 +0100 Subject: 0.3.0 rc1 quickie download
link
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?
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Tue, 22 Jun 2010 21:51:21 +0300
Subject: Re: 0.3.0 rc1 quickie download link
> 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.
Ok, I'll monitor it. Bandwidth hasn't been a problem so far - it's
been about 2 GB (0.5 dollars) per month at most. Other costs are about
15$ a month.
> 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?
That would be nice, I can do it. Sending cash in the mail may have its
risks, but maybe it's still the best anonymous option. We can also ask
for donations in BTC on the forum.
>> 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?
>
> That would be nice, I can do it. Sending cash in the mail may have its
> risks, but maybe it's still the best anonymous option. We can also ask
> for donations in BTC on the forum.
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.
You can give this address:
Martti Malmi
Visakoivunkuja 15 F 42
02130 Espoo
Finland
>>> 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?
>>
>> That would be nice, I can do it. Sending cash in the mail may have
>> its risks, but maybe it's still the best anonymous option. We can
>> also ask for donations in BTC on the forum.
>
> 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.
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Tue, 06 Jul
2010 19:03:50 +0100 Subject: 0.3.0 released
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.
What's new:
- Command line and JSON-RPC control
- Includes a daemon version without GUI
- Tabs for sent and received transactions
- 20% faster hashing
- Hashmeter performance display
- Mac OS X version (thanks to Laszlo)
- German, Dutch and Italian translations (thanks to DataWraith, Xunie
and Joozero)
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Tue, 06 Jul
2010 19:40:11 +0100 Subject: Re: 0.3.0 released
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."
Satoshi Nakamoto wrote:
> 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.
>
> What's new:
> - Command line and JSON-RPC control
> - Includes a daemon version without GUI
> - Tabs for sent and received transactions
> - 20% faster hashing
> - Hashmeter performance display
> - Mac OS X version (thanks to Laszlo)
> - German, Dutch and Italian translations (thanks to DataWraith, Xunie
> and Joozero)
>
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.
What's new:
- Command line and JSON-RPC control
- Includes a daemon version without GUI
- Transaction filter tabs
- 20% faster hashing
- Hashmeter performance display
- Mac OS X version (thanks to Laszlo)
- German, Dutch and Italian translations (thanks to DataWraith, Xunie
and Joozero)
Get it at www.bitcoin.org, and read the forum to find out more.
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_______________________________________________
bitcoin-list mailing list
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list
Ok, that sounds reasonable.
> 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 see the interior pages of the old sourceforge wiki are still up,
though the homepage forwards.
-------- Original Message --------
Subject: Re: bitcoin!!!!
Date: Wed, 14 Jul 2010 10:56:21 -0400
From: Sam <samm@sammaloney.com>
To: Satoshi Nakamoto <satoshin@gmx.com>
References: <201004111508.52168.samm@sammaloney.com>
<201007111859.29171.samm@sammaloney.com> <4C3DCD97.8030003@gmx.com>
It was an old FAQ on sourceforge that had been linked from slashdot (on a
highly visible comment). people were going there because bitcoin.org was
down
for a while.
http://bitcoin.sourceforge.net/wiki/index.php?page=FAQ
Probably not an issue anymore, but might be a good idea to delete or update
that wiki page.
> I don't see any 0.1.5 download links on the FAQ. Do you mean
> bitcoin.org/faq? Is it on one of the other languages? Or maybe someone
> else fixed it already.
>
> > Anyways, I write to you now to let you know you must update the FAQ
> > immediately. It points to 0.15 of bitcoin for download. You must update
> > it to 0.30, as it is slashdotted!
>
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)
Fwd: Please update the bitcoin FAQ so new member can have the right info
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Thu, 15 Jul
2010 18:43:55 +0100 Subject: Fwd: Please update the
bitcoin FAQ so new member can have the right info
-------- Original Message --------
Subject: Please update the bitcoin FAQ so new member can have the right
info
Date: Mon, 12 Jul 2010 14:13:20 -0700
From: [REDACTED-NAME] <[REDACTED-EMAIL]>
To: satoshin@gmx.com
Hi,
In the FAQ of bitcoin.org <http://bitcoin.org> the backing up of the
wallet had old instructions, right? Should it just be to back up
wallat.dat instead of the entire folder??? See below.
"How do I backup my wallet?
Your data is stored in the directory ''%appdata%\Bitcoin'', which is
typically:
Windows XP:
C:\Documents and Settings\username\Application Data\Bitcoin
Windows Vista:
C:\Users\username\AppData\Roaming\Bitcoin
It’s recommended that you stop Bitcoin before backing it up to make sure
the backup will be correct."
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Thu, 15 Jul
2010 21:00:12 +0100 Subject: bitcoin.org server
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)
Yes, we could give accounts to trusted translators. I haven't found a
way to give them edit permissions to only one page, but they can be
forced to create a new revision with every page change they make, and
not be allowed to delete revisions. Xunie would be the first on the
list I'd give an account. :)
> 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)
Relocated the old site to /oldsite, now there's only the redirection.
> I see the interior pages of the old sourceforge wiki are still up,
> though the homepage forwards.
>
>
> -------- Original Message --------
> Subject: Re: bitcoin!!!!
> Date: Wed, 14 Jul 2010 10:56:21 -0400
> From: Sam <samm@sammaloney.com>
> To: Satoshi Nakamoto <satoshin@gmx.com>
> References: <201004111508.52168.samm@sammaloney.com>
> <201007111859.29171.samm@sammaloney.com> <4C3DCD97.8030003@gmx.com>
>
> It was an old FAQ on sourceforge that had been linked from slashdot (on a
> highly visible comment). people were going there because bitcoin.org was down
> for a while.
>
> http://bitcoin.sourceforge.net/wiki/index.php?page=FAQ
>
> Probably not an issue anymore, but might be a good idea to delete or update
> that wiki page.
>
>> I don't see any 0.1.5 download links on the FAQ. Do you mean
>> bitcoin.org/faq? Is it on one of the other languages? Or maybe someone
>> else fixed it already.
>>
>>> Anyways, I write to you now to let you know you must update the FAQ
>>> immediately. It points to 0.15 of bitcoin for download. You must update
>>> it to 0.30, as it is slashdotted!
>>
Rackspace has very good support, good backend, good connections and
nicely scaling cloud based virtual servers. I got this offer from
Thufir:
-----
Hi Sirius,
Check out www.citrusdesignstudio.com. You will see through the portfolio that
I am a real business with many clients.
That is my business that I provide managed hosting through.
I also do unmanaged VPSes.
Normally I would charge $15/mo for 512MB.
I will do it for $10/mo for you.
To see my pricing, go to www.linnode.com. I match everything they have except
their great panel -- you have to email or call my people.
I provide VPS services normally for 3/4ths the posted cost on linnode.com.
(Rackspace is even more expensive.)
I will do it for 1/2 of linnode's price for you.
It scales linerally just like linnodes, so for 2048 MB of memory, I would
charge $40, etc.
Later!
-----
That would be worth considering, if they have good datacenters and
connections. $10 / month is about $20 less than what Rackspace costs.
On the other hand, Rackspace prices are no problem if the donation is
to arrive.
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?
mmalmi@cc.hut.fi wrote:
> Rackspace has very good support, good backend, good connections and
> nicely scaling cloud based virtual servers. I got this offer from Thufir:
>
> -----
> Hi Sirius,
>
> Check out www.citrusdesignstudio.com. You will see through the portfolio
> that
> I am a real business with many clients.
>
> That is my business that I provide managed hosting through.
> I also do unmanaged VPSes.
>
> Normally I would charge $15/mo for 512MB.
> I will do it for $10/mo for you.
>
> To see my pricing, go to www.linnode.com. I match everything they have
> except
> their great panel -- you have to email or call my people.
>
> I provide VPS services normally for 3/4ths the posted cost on linnode.com.
> (Rackspace is even more expensive.)
>
> I will do it for 1/2 of linnode's price for you.
>
> It scales linerally just like linnodes, so for 2048 MB of memory, I would
> charge $40, etc.
>
> Later!
> -----
>
> That would be worth considering, if they have good datacenters and
> connections. $10 / month is about $20 less than what Rackspace costs. On
> the other hand, Rackspace prices are no problem if the donation is to
> arrive.
>
http://www.bitcoin.org/smf/index.php?topic=393.msg3785#msg3785
AndrewBuck:
...
EDIT: The wiki doesn't seem to be sending the registration e-mail so I
can log in to edit, is there some problem with the server or something?
-Buck
Ok, I won't switch it. Donations in Bitcoin are helpful and can be
sent to 14EXchS9j3AAfim6mL4jtw6VWMosSUiG5U.
> 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?
>
> mmalmi@cc.hut.fi wrote:
>> Rackspace has very good support, good backend, good connections and
>> nicely scaling cloud based virtual servers. I got this offer from
>> Thufir:
>>
>> -----
>> Hi Sirius,
>>
>> Check out www.citrusdesignstudio.com. You will see through the
>> portfolio that
>> I am a real business with many clients.
>>
>> That is my business that I provide managed hosting through.
>> I also do unmanaged VPSes.
>>
>> Normally I would charge $15/mo for 512MB.
>> I will do it for $10/mo for you.
>>
>> To see my pricing, go to www.linnode.com. I match everything they
>> have except
>> their great panel -- you have to email or call my people.
>>
>> I provide VPS services normally for 3/4ths the posted cost on linnode.com.
>> (Rackspace is even more expensive.)
>>
>> I will do it for 1/2 of linnode's price for you.
>>
>> It scales linerally just like linnodes, so for 2048 MB of memory, I would
>> charge $40, etc.
>>
>> Later!
>> -----
>>
>> That would be worth considering, if they have good datacenters and
>> connections. $10 / month is about $20 less than what Rackspace
>> costs. On the other hand, Rackspace prices are no problem if the
>> donation is to arrive.
>>
mmalmi@cc.hut.fi wrote:
> Good news: I received the donation of $3600. At least the hosting costs
> are no problem anymore.
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:
-$60 rackspace monthly
$2540 balance
> What do you think of the idea to offer rewards of $100-200 to the first
> 5-10 established companies that start accepting Bitcoin? We'd also
> assign them a dedicated support person to help with integration. I have
> companies like prq.se, ipredator.se, relakks.com or perfect-privacy.com
> in mind. We could also make the offer public.
$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.
Good news: I received the donation of $3600. At least the hosting
costs are no problem anymore.
What do you think of the idea to offer rewards of $100-200 to the
first 5-10 established companies that start accepting Bitcoin? We'd
also assign them a dedicated support person to help with integration.
I have companies like prq.se, ipredator.se, relakks.com or
perfect-privacy.com in mind. We could also make the offer public.
> Spend what you need on hosting. Email me a simple accounting when you
> take out money for expenses, like:
> -$60 rackspace monthly
> $2540 balance
Ok.
>> What do you think of the idea to offer rewards of $100-200 to the
>> first 5-10 established companies that start accepting Bitcoin? We'd
>> also assign them a dedicated support person to help with
>> integration. I have companies like prq.se, ipredator.se,
>> relakks.com or perfect-privacy.com in mind. We could also make the
>> offer public.
>
> $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.
Alright, I'll add $1000 dollars to the exchange reserves. That way I
can offer more stable pricing.
A week ago somebody bought coins with 1000 €. That was probably meant
as a donation to some extent, since 1000 € would have bought him a lot
more coins at bitcoinmarket.com than at my service.
>> I think we should allocate $1000 at this point to your exchange.
>
> Alright, I'll add $1000 dollars to the exchange reserves. That way I can
> offer more stable pricing.
>
> A week ago somebody bought coins with 1000 €. That was probably meant as
> a donation to some extent, since 1000 € would have bought him a lot more
> coins at bitcoinmarket.com than at my service.
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?
> Interesting, so how is the balance between purchases of coins and cash going?
About +1000€ (plus the $1000) and -40000 BTC since when I started. I
should have set the initial BTC price higher, it was only 1€ / 1000
BTC in the beginning.
> Btw, are you able to use my builds of bitcoind on your host, or do you
> have to build it yourself?
I had to build it myself. It had the same problem that has been
reported on the forums: /usr/lib/libstdc++.so.6: version
`GLIBCXX_3.4.11' not found.
> A week ago somebody bought coins with 1000 €. That was probably meant as
> a donation to some extent, since 1000 € would have bought him a lot more
> coins at bitcoinmarket.com than at my service.
They probably couldn't have gotten that large of a trade on
bitcoinmarket.com.
Re: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11'
>> Btw, are you able to use my builds of bitcoind on your host, or do you
>> have to build it yourself?
>
> I had to build it myself. It had the same problem that has been reported
> on the forums: /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found.
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.
Forum e-mail notifications and PBL blacklist and wiki registration
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Thu, 29 Jul
2010 03:18:56 +0100 Subject: Forum e-mail notifications
and PBL blacklist and wiki registration
http://www.bitcoin.org/smf/index.php?topic=338.0
> of e-mail blackhole list or at least the ISP that hosts the e-mail server for registration is on one of those lists.
>
> "Looks like bitcoin.org is listed on the PBL."
> http://www.spamhaus.org/pbl/query/PBL340779
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->settings->registration of new members to "Member
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.
[bitcoin-list] Alert: upgrade to bitcoin 0.3.6
bitcoin-list Mailing List (Satoshi Nakamoto) — July 30, 2010 — source: sni-emails.json#email-60
Please upgrade to 0.3.6 ASAP to get an important bugfix.
See the bitcoin.org homepage for download links.
------------------------------------------------------------------------------
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
_______________________________________________
bitcoin-list mailing list
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Mon, 02 Aug
2010 21:56:06 +0100 Subject: [Fwd: no activation
mail]
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.
-------- Original Message --------
Subject: no activation mail
Date: Mon, 02 Aug 2010 22:30:35 +0200
From: [REDACTED-NAME] <[REDACTED-EMAIL]>
To: satoshin@gmx.com
Hey Satoshin,
I tried to register me at the bitcoinforum, but I didn't get an activation
mail.
Tried the resend activation code option a few times, changed the
mailadress from my telenet to my gmail and back, but no luck. Looked at my
spam folder but it's not there. So I guess something went wrong, could you
activate my account?
My username is Skull88.
Thanks in advance,
[REDACTED-NAME]
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Mon, 02 Aug
2010 22:08:22 +0100 Subject: Disabled some
notifications
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.
[Fwd: Forum e-mail notifications and PBL blacklist and wiki registration]
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Mon, 02 Aug
2010 22:09:20 +0100 Subject: [Fwd: Forum e-mail
notifications and PBL blacklist and wiki registration]
Here's the info about PBL again.
-------- Original Message --------
Subject: Forum e-mail notifications and PBL blacklist and wiki registration
Date: Thu, 29 Jul 2010 03:18:56 +0100
From: Satoshi Nakamoto <satoshin@gmx.com>
To: Martti Malmi <mmalmi@cc.hut.fi>
http://www.bitcoin.org/smf/index.php?topic=338.0
> of e-mail blackhole list or at least the ISP that hosts the e-mail server for registration is on one of those lists.
>
> "Looks like bitcoin.org is listed on the PBL."
> http://www.spamhaus.org/pbl/query/PBL340779
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->settings->registration of new members to "Member
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.
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Wed, 04 Aug 2010 00:37:13 +0300
Subject: Re: [Fwd: no activation mail]
The logs don't tell very much, they just confirm that many servers
reject the emails sent by our server. I can't think of anything other
than pm notifications that could have caused the spam listing. I'll
check if I can disable the notifications from the code.
We can allow registrations without email confirmation. It's no problem
when we're already on the spam list and no problem after the
notifications are disabled.
> 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.
>
>
>
> -------- Original Message --------
> Subject: no activation mail
> Date: Mon, 02 Aug 2010 22:30:35 +0200
> From: [REDACTED-NAME] <[REDACTED-EMAIL]>
> To: satoshin@gmx.com
>
> Hey Satoshin,
>
> I tried to register me at the bitcoinforum, but I didn't get an activation
> mail.
> Tried the resend activation code option a few times, changed the
> mailadress from my telenet to my gmail and back, but no luck. Looked at my
> spam folder but it's not there. So I guess something went wrong, could you
> activate my account?
>
> My username is Skull88.
>
> Thanks in advance,
> [REDACTED-NAME]
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Thu, 05 Aug 2010 20:03:11 +0300
Subject: Re: [Fwd: no activation mail]
I edited the forum code, it shouldn't send notifications anymore.
> 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.
>
>
>
> -------- Original Message --------
> Subject: no activation mail
> Date: Mon, 02 Aug 2010 22:30:35 +0200
> From: [REDACTED-NAME] <[REDACTED-EMAIL]>
> To: satoshin@gmx.com
>
> Hey Satoshin,
>
> I tried to register me at the bitcoinforum, but I didn't get an activation
> mail.
> Tried the resend activation code option a few times, changed the
> mailadress from my telenet to my gmail and back, but no luck. Looked at my
> spam folder but it's not there. So I guess something went wrong, could you
> activate my account?
>
> My username is Skull88.
>
> Thanks in advance,
> [REDACTED-NAME]
Re: [Fwd: Forum e-mail notifications and PBL blacklist and wiki registration]
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Tue, 10 Aug 2010 04:28:38 +0300
Subject: Re: [Fwd: Forum e-mail notifications and PBL
blacklist and wiki registration]
I sent a removal request to PBL.
The FAQ says: "The first thing to know is: THE PBL IS NOT A BLACKLIST.
You are not listed for spamming or for anything you have done. The PBL
is simply a list of all of the world's dynamic IP space, i.e: IP
ranges normally assigned to ISP broadband customers (DSL, DHCP, PPP,
cable, dialup). It is perfectly normal for dynamic IP addresses to be
listed on the PBL. In fact all dynamic IP addresses in the world
should be on the PBL. Even static IPs which do not send mail should be
listed in the PBL." So we didn't even need to allow spam to be on the
list.
> Here's the info about PBL again.
>
>
> -------- Original Message --------
> Subject: Forum e-mail notifications and PBL blacklist and wiki registration
> Date: Thu, 29 Jul 2010 03:18:56 +0100
> From: Satoshi Nakamoto <satoshin@gmx.com>
> To: Martti Malmi <mmalmi@cc.hut.fi>
>
> http://www.bitcoin.org/smf/index.php?topic=338.0
>
>> of e-mail blackhole list or at least the ISP that hosts the e-mail
>> server for registration is on one of those lists.
>>
>> "Looks like bitcoin.org is listed on the PBL."
>> http://www.spamhaus.org/pbl/query/PBL340779
>
> 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->settings->registration of new members to "Member
> 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.
I deposited the donation to a bank as euros. The donation was actually
not $3600 but 3500$. I miscalculated it as it was packed in (18 + 17)
* $100 instead of (18 + 18) * $100.
$3500 made 2608.28€.
-750€ to back up BitcoinExchange.com
-28.92€ for the hosting in July
1829€ balance
Re: [Fwd: Forum e-mail notifications and PBL blacklist and wiki registration]
From: Satoshi Nakamoto satoshin@gmx.comTo: mmalmi@cc.hut.fiDate: Wed, 11 Aug
2010 02:54:27 +0100 Subject: Re: [Fwd: Forum e-mail
notifications and PBL blacklist and wiki registration]
Are PM notifications still disabled? (All we really need is disable the
forum's access to the mail server)
> Does it work correctly now? I had made some forum code changes to
> disable PM email notification, but just reverted most of them as
> unnecessary.
mmalmi@cc.hut.fi wrote:
> I sent a removal request to PBL.
>
> The FAQ says: "The first thing to know is: THE PBL IS NOT A BLACKLIST.
> You are not listed for spamming or for anything you have done. The PBL
> is simply a list of all of the world's dynamic IP space, i.e: IP ranges
> normally assigned to ISP broadband customers (DSL, DHCP, PPP, cable,
> dialup). It is perfectly normal for dynamic IP addresses to be listed on
> the PBL. In fact all dynamic IP addresses in the world should be on the
> PBL. Even static IPs which do not send mail should be listed in the
> PBL." So we didn't even need to allow spam to be on the list.
>
>> Here's the info about PBL again.
>>
>>
>> -------- Original Message --------
>> Subject: Forum e-mail notifications and PBL blacklist and wiki
>> registration
>> Date: Thu, 29 Jul 2010 03:18:56 +0100
>> From: Satoshi Nakamoto <satoshin@gmx.com>
>> To: Martti Malmi <mmalmi@cc.hut.fi>
>>
>> http://www.bitcoin.org/smf/index.php?topic=338.0
>>
>>> of e-mail blackhole list or at least the ISP that hosts the e-mail
>>> server for registration is on one of those lists.
>>>
>>> "Looks like bitcoin.org is listed on the PBL."
>>> http://www.spamhaus.org/pbl/query/PBL340779
>>
>> 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->settings->registration of new members to "Member
>> 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.
>
>
>
Re: [Fwd: Forum e-mail notifications and PBL blacklist and wiki registration]
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Wed, 11 Aug 2010 06:42:32 +0300
Subject: Re: [Fwd: Forum e-mail notifications and PBL
blacklist and wiki registration]
Yes, they're still disabled. Disabling the access to the mail server
would be easy, but we probably want to keep the password recovery by
email.
> Are PM notifications still disabled? (All we really need is disable
> the forum's access to the mail server)
>
>> Does it work correctly now? I had made some forum code changes to
>> disable PM email notification, but just reverted most of them as
>> unnecessary.
>
> mmalmi@cc.hut.fi wrote:
>> I sent a removal request to PBL.
>>
>> The FAQ says: "The first thing to know is: THE PBL IS NOT A
>> BLACKLIST. You are not listed for spamming or for anything you have
>> done. The PBL is simply a list of all of the world's dynamic IP
>> space, i.e: IP ranges normally assigned to ISP broadband customers
>> (DSL, DHCP, PPP, cable, dialup). It is perfectly normal for dynamic
>> IP addresses to be listed on the PBL. In fact all dynamic IP
>> addresses in the world should be on the PBL. Even static IPs which
>> do not send mail should be listed in the PBL." So we didn't even
>> need to allow spam to be on the list.
>>
>>> Here's the info about PBL again.
>>>
>>>
>>> -------- Original Message --------
>>> Subject: Forum e-mail notifications and PBL blacklist and wiki registration
>>> Date: Thu, 29 Jul 2010 03:18:56 +0100
>>> From: Satoshi Nakamoto <satoshin@gmx.com>
>>> To: Martti Malmi <mmalmi@cc.hut.fi>
>>>
>>> http://www.bitcoin.org/smf/index.php?topic=338.0
>>>
>>>> of e-mail blackhole list or at least the ISP that hosts the
>>>> e-mail server for registration is on one of those lists.
>>>>
>>>> "Looks like bitcoin.org is listed on the PBL."
>>>> http://www.spamhaus.org/pbl/query/PBL340779
>>>
>>> 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->settings->registration of new members to "Member
>>> 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.
>>
>>
>>
Re: [Fwd: Forum e-mail notifications and PBL blacklist and wiki registration]
From: Satoshi Nakamoto satoshin@gmx.comTo: mmalmi@cc.hut.fiDate: Wed, 11 Aug
2010 21:00:13 +0100 Subject: Re: [Fwd: Forum e-mail
notifications and PBL blacklist and wiki registration]
Right, forgot about that.
Hopefully theymos was right that the PBL is the source of the problem.
mmalmi@cc.hut.fi wrote:
> Yes, they're still disabled. Disabling the access to the mail server
> would be easy, but we probably want to keep the password recovery by email.
>
>> Are PM notifications still disabled? (All we really need is disable
>> the forum's access to the mail server)
>>
>>> Does it work correctly now? I had made some forum code changes to
>>> disable PM email notification, but just reverted most of them as
>>> unnecessary.
>>
>> mmalmi@cc.hut.fi wrote:
>>> I sent a removal request to PBL.
>>>
>>> The FAQ says: "The first thing to know is: THE PBL IS NOT A
>>> BLACKLIST. You are not listed for spamming or for anything you have
>>> done. The PBL is simply a list of all of the world's dynamic IP
>>> space, i.e: IP ranges normally assigned to ISP broadband customers
>>> (DSL, DHCP, PPP, cable, dialup). It is perfectly normal for dynamic
>>> IP addresses to be listed on the PBL. In fact all dynamic IP
>>> addresses in the world should be on the PBL. Even static IPs which
>>> do not send mail should be listed in the PBL." So we didn't even
>>> need to allow spam to be on the list.
>>>
>>>> Here's the info about PBL again.
>>>>
>>>>
>>>> -------- Original Message --------
>>>> Subject: Forum e-mail notifications and PBL blacklist and wiki
>>>> registration
>>>> Date: Thu, 29 Jul 2010 03:18:56 +0100
>>>> From: Satoshi Nakamoto <satoshin@gmx.com>
>>>> To: Martti Malmi <mmalmi@cc.hut.fi>
>>>>
>>>> http://www.bitcoin.org/smf/index.php?topic=338.0
>>>>
>>>>> of e-mail blackhole list or at least the ISP that hosts the
>>>>> e-mail server for registration is on one of those lists.
>>>>>
>>>>> "Looks like bitcoin.org is listed on the PBL."
>>>>> http://www.spamhaus.org/pbl/query/PBL340779
>>>>
>>>> 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->settings->registration of new members to
>>>> "Member
>>>> 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.
>>>
>>>
>>>
>
>
>
[bitcoin-list] ALERT - we are investigating a problem
bitcoin-list Mailing List (Satoshi Nakamoto) — August 15, 2010 — source: sni-emails.json#email-61
*** WARNING *** We are investigating a problem. DO NOT TRUST ANY
TRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638)
until the issue is resolved.
[bitcoin-list] ALERT - we are investigating a problem
*** WARNING *** We are investigating a problem. DO NOT TRUST ANY
TRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638)
until the issue is resolved.
------------------------------------------------------------------------------
This SF.net email is sponsored by
Make an app they can't live without
Enter the BlackBerry Developer Challenge
http://p.sf.net/sfu/RIM-dev2dev
_______________________________________________
bitcoin-list mailing list
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Fri, 27 Aug
2010 03:36:43 +0100 Subject: [Fwd: SweepMines now
accept bitcoins]
-------- Original Message --------
Subject: SweepMines now accept bitcoins
Date: Tue, 24 Aug 2010 19:50:47 +0600
From: [REDACTED-NAME] <[REDACTED-EMAIL]>
To: satoshin@gmx.com
Dear BitCoin.
http://apps.facebook.com/sweepmines/ now accepts BitCoins.
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.
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Sun, 03 Oct
2010 21:27:29 +0100 Subject: SMF php code
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?
Sorry, I didn't notice your custom code when updating. Re-integration
is a good idea if it's not too much work. I've removed hundreds of
spam accounts by making a search for old accounts that have a webpage
url and 0 posts.
> 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:
Register.php
PersonalMessage.php
ManageRegistration.php
Subs.php
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.
mmalmi@cc.hut.fi wrote:
> Sorry, I didn't notice your custom code when updating. Re-integration is
> a good idea if it's not too much work. I've removed hundreds of spam
> accounts by making a search for old accounts that have a webpage url and
> 0 posts.
>
>> 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?
>
>
>
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Wed, 01 Dec
2010 00:58:37 +0000 Subject: [Fwd: Bitcoin.org is
down]
-------- Original Message --------
Subject: Bitcoin.org is down
Date: Tue, 30 Nov 2010 18:27:02 -0600
From: theymos <theymos@mm.st>
To: satoshin@gmx.com
Bitcoin.org has been down for several hours.
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Thu, 02 Dec
2010 22:00:56 +0000 Subject: What was the bitcoin.org
outage?
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?
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Fri, 03 Dec 2010 12:08:53 +0200
Subject: Re: What was the bitcoin.org outage?
> 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.
I don't know what it was. It started working again when I rebooted it.
Someone suggested it might have been the heavy load from a Reddit post
about Bitcoin. Inspecting the logs would be useful, but I don't have
much time now.
> 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?
I told him to go ahead. I don't do automatic backups atm. We should
have more server admins soon when I get bitcoinexchange.com to another
server. I could give the root password to you and somebody else. Xunie
has volunteered, but we might find somebody even more professional outage was due to heavy load, he could help us move to lighttpd or
optimize resources otherwise. Should we make a recruitment thread on
the forum?
From: Satoshi Nakamoto satoshin@gmx.comTo: mmalmi@cc.hut.fiDate: Fri, 03 Dec
2010 19:58:40 +0000 Subject: Re: What was the
bitcoin.org outage?
> I told him to go ahead. I don't do automatic backups atm. We should have
> more server admins soon when I get bitcoinexchange.com to another
> server. I could give the root password to you and somebody else. Xunie
> has volunteered, but we might find somebody even more professional from
> the forum and keep the number of admins at the minimum. If the outage
> was due to heavy load, he could help us move to lighttpd or optimize
> resources otherwise. Should we make a recruitment thread on the forum?
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)
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Mon, 06 Dec 2010 13:33:01 +0200
Subject: Re: What was the bitcoin.org outage?
I'm ready to send you the password. Can you send me your PGP key so I
don't have to send it in plaintext?
> It should be Gavin. I trust him, he's responsible, professional, and
> technically much more linux capable than me.
Ok, I'll ask him.
From: Satoshi Nakamoto satoshin@gmx.comTo: mmalmi@cc.hut.fiDate: Mon, 06 Dec
2010 16:08:56 +0000 Subject: Re: What was the
bitcoin.org outage?
mmalmi@cc.hut.fi wrote:
> I'm ready to send you the password. Can you send me your PGP key so I
> don't have to send it in plaintext?
>
>> It should be Gavin. I trust him, he's responsible, professional, and
>> technically much more linux capable than me.
>
> Ok, I'll ask him.
Thanks, did you finish moving bitcoinexchange to another server?
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.7 (MingW32)
mQGiBEkJ+qcRBADKDTcZlYDRtP1Q7/ShuzBJzUh9hoVVowogf2W07U6G9BqKW24r
piOxYmErjMFfvNtozNk+33cd/sq3gi05O1IMmZzg2rbF4ne5t3iplXnNuzNh+j+6
VxxA16GPhBRprvnng8r9GYALLUpo9Xk17KE429YYKFgVvtTPtEGUlpO1EwCg7FmW
dBbRp4mn5GfxQNT1hzp9WgkD/3pZ0cB5m4enzfylOHXmRfJKBMF02ZDnsY1GqeHv
/LjkhCusTp2qz4thLycYOFKGmAddpVnMsE/TYZLgpsxjrJsrEPNSdoXk3IgEStow
mXjTfr9xNOrB20Qk0ZOO1mipOWMgse4PmIu02X24OapWtyhdHsX3oBLcwDdke8aE
gAh8A/sHlK7fL1Bi8rFzx6hb+2yIlD/fazMBVZUe0r2uo7ldqEz5+GeEiBFignd5
HHhqjJw8rUJkfeZBoTKYlDKo7XDrTRxfyzNuZZPxBLTj+keY8WgYhQ5MWsSC2MX7
FZHaJddYa0pzUmFZmQh0ydulVUQnLKzRSunsjGOnmxiWBZwb6bQjU2F0b3NoaSBO
YWthbW90byA8c2F0b3NoaW5AZ214LmNvbT6IYAQTEQIAIAUCSQn6pwIbAwYLCQgH
AwIEFQIIAwQWAgMBAh4BAheAAAoJEBjAnoZeyUihXGMAnjiWJ0fvmSgSM3o6Tu3q
RME9GN7QAKCGrFw9SUD0e9/YDcqhX1aPMrYue7kCDQRJCfqnEAgA9OTCjLa6Sj7t
dZcQxNufsDSCSB+yznIGzFGXXpJk7GgKmX3H9Zl4E6zJTQGXL2GAV4klkSfNtvgs
SGJKqCnebuZVwutyq1vXRNVFPQFvLVVo2jJCBHWjb03fmXmavIUtRCHoc8xgVJMQ
LrwvS943GgsqSbdoKZWdTnfnEq+UaGo+Qfv66NpT3Yl0CXUiNBITZOJcJdjHDTBO
XRqomX2WSguv+btYdhQGGQiaEx73XMftXNCxbOpqwsODQns7xTcl2ENru9BNIQME
I7L9FYBQUiKHm1k6RrBy1as8XElS2jEos7GAmlfF1wShFUX+NF1VOPdbN3ZdFoWq
sUjKk+QbrwADBQgA9DiD4+uuRhwk2B1TmtrXnwwhcdkE7ZbLHjxBfCsLPAZiPh8c
ICfV3S418i4H1YCz2ItcnC8KAPoS6mipyS28AU1B7zJYPODBn8E7aPSPzHJfudMK
MqiCHljVJrE23xsKTC0sIhhSKcr2G+6ARoG5lwuoqJqEyDrblVQQFpVxBNPHSTqu
O5PoLXQc7PKgC5SyQuZbEALEkItl2SL2yBRRGOlVJLnvZ6eaovkAlgsbGdlieOr0
UwWuJCwzZuBDruMYAfyQBvYfXZun3Zm84rW7Jclp18mXITwGCVHg/P5n7QMbBfZQ
A25ymkuj636Nqh+c4zRnSINfyrDcID7AcqEb6IhJBBgRAgAJBQJJCfqnAhsMAAoJ
EBjAnoZeyUihPrcAniVWl5M44RuGctJe+IMNX4eVkC08AJ9v7cXsp5uDdQNo8q3R
8RHwN4Gk8w==
=3FTe
-----END PGP PUBLIC KEY BLOCK-----
It's also at
http://www.bitcoin.org/Satoshi_Nakamoto.asc
From: mmalmi@cc.hut.fiTo: Satoshi Nakamoto
satoshin@gmx.comDate: Tue, 07 Dec 2010 04:37:38 +0200
Subject: Re: What was the bitcoin.org outage?
Attached is the root password encrypted.
> Thanks, did you finish moving bitcoinexchange to another server?
I moved all the files, database and bitcoind, but still some work
needed to get it running. The old site is down atm anyway, so feel
free to reboot if needed.
From: Satoshi Nakamoto satoshin@gmx.comTo: Martti Malmi mmalmi@cc.hut.fiDate: Tue, 07 Dec
2010 15:38:28 +0000 Subject: Project Developers
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.
Ok. You can include the e-mail address.
> 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
http://www.bitcoin.org/smf/index.php?topic=1886.0).
- getaccountaddress
- sendfrom
- move
- getbalance
- listtransactions
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.18/
------------------------------------------------------------------------------
This SF Dev2Dev email is sponsored by:
WikiLeaks The End of the Free Internet
http://p.sf.net/sfu/therealnews-com
_______________________________________________
bitcoin-list mailing list
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list
Bitcoin.org was down again today for some time. It responded to ping
but not ssh or http. I rebooted it and found out it was an out of
memory error and mysqld got killed. It was the same error last time,
but with apache getting killed. I couldn't think of anything better,
so I resized the server from 512MB to 1024MB of memory.
This is a minor release to add some DoS protection.
Changes:
- Added some DoS limits, though it's still far from DoS resistant.
- Removed "safe mode" alerts.
http://www.bitcoin.org/smf/index.php?topic=2228.0
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/
------------------------------------------------------------------------------
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages,
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev
_______________________________________________
bitcoin-list mailing list
bitcoin-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-list
[bitcoin-list] Bitcoin 0.3.19 is released
bitcoin-list Mailing List (Satoshi Nakamoto) — December 13, 2010 — source: sni-emails.json#email-63
This is a minor release to add some DoS protection.
Changes:
- Added some DoS limits, though it's still far from DoS resistant.
- Removed "safe mode" alerts.
http://www.bitcoin.org/smf/index.php?topic=2228.0
Download:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/
ShadowOfHarbringer described a way of mirroring the bitcoin.org
website and forum here:
http://www.bitcoin.org/smf/index.php?topic=2026.msg30043#msg30043
Should we go by it and trust the database along with its password
hashes to some reliable community members who have servers? Another
option is to encrypt the backups with pgp and store them in multiple
places.
Gavin Andresen wrote:
> On Mon, Dec 20, 2010 at 10:55 AM, <mmalmi@cc.hut.fi> wrote:
>> ShadowOfHarbringer described a way of mirroring the bitcoin.org website and
>> forum here:
>> http://www.bitcoin.org/smf/index.php?topic=2026.msg30043#msg30043
>>
>> Should we go by it and trust the database along with its password hashes to
>> some reliable community members who have servers?
>
> That seems like asking for trouble, and I think it would violate the
> implicit trust of everybody who's registered for the forums.
I agree, don't let the database out of your hands. There's private PM
in there, e-mail addresses, passwords.
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
>> Another option is to
>> > encrypt the backups with pgp and store them in multiple places.
>
> That seems wiser. Daily backups copied ... somewhere ... seems like
> the right thing to do. If they're reasonably small (less than a
> gigabyte), I'd be happy to pay for Amazon S3 storage/bandwidth for
> them.
+1
Even with encryption, a trusted storage place is better.
Ok. I'll start backing up to another server I'm using. I'll send you
the SSH key when I've set it up, so you can start backing up to any
server you want. The backup file size is about 50 MB atm.
Here's my pgp key btw: http://www.bitcoin.org/mmalmi.asc
> Gavin Andresen wrote:
>> On Mon, Dec 20, 2010 at 10:55 AM, <mmalmi@cc.hut.fi> wrote:
>>> ShadowOfHarbringer described a way of mirroring the bitcoin.org website and
>>> forum here:
>>> http://www.bitcoin.org/smf/index.php?topic=2026.msg30043#msg30043
>>>
>>> Should we go by it and trust the database along with its password hashes to
>>> some reliable community members who have servers?
>>
>> That seems like asking for trouble, and I think it would violate the
>> implicit trust of everybody who's registered for the forums.
>
> I agree, don't let the database out of your hands. There's private PM
> in there, e-mail addresses, passwords.
>
> 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
>
>
>>> Another option is to
>>>> encrypt the backups with pgp and store them in multiple places.
>>
>> That seems wiser. Daily backups copied ... somewhere ... seems like
>> the right thing to do. If they're reasonably small (less than a
>> gigabyte), I'd be happy to pay for Amazon S3 storage/bandwidth for
>> them.
>
> +1
>
> Even with encryption, a trusted storage place is better.
You can fetch the backup with:
wget --no-check-certificate
https://backup:[REDACTED-PASSWORD]@www.bitcoin.org/backup/bitcoinsite.tar.bz2.gpg
It's updated every day 11:00 GMT.
From: Mike Hearn Date: Mon, Dec 27,
2010 at 8:21 PM To: Satoshi Nakamoto satoshin@gmx.comThread: More BitCoin
questions
Happy Christmas Satoshi, assuming you celebrate it wherever you are in
the world :-)
I have been working on a Java implementation of the simplified payment
verification, with an eye to building a client that runs on Android
phones. So I've been thinking a lot about storage requirements and the
scalability of BitCoin, which led to some questions that the paper did
not answer (maybe there could be a new version of the paper at some
point, as I think aspects of it are now out of date).
Specifically, BitCoin has a variety of magic numbers and neither the
code nor the paper explain where they came from. For example, the fact
that inflation ceases when 21 million coins have been issued. This
number must have been arrived at somehow, but I can't see how.
Another is the 10 minute block target. I understand this was chosen to
allow transactions to propagate through the network. However existing
large P2P networks like BGP can propagate new data worldwide in <1
minute.
The final number I'm interested in is the 500kb limit on block sizes.
According to Wikipedia, Visa alone processed 62 billion transactions
in 2009. Dividing through we get an average of 2000 transactions per
second, so peak rate is probably around double that at 4000
transactions/sec. With a ten minute block target, at peak a block
might need to contain 2.4 million transactions, which just won't fit
into 500kb. Is this 500kb a temporary limitation that will be slowly
removed over time from the official client or something more
fundamental?
More BitCoin questions — reply 2
Mike Hearn correspondence (Satoshi Nakamoto) — December 29, 2010 — source: hearn-thread3.html#msg-2
From: Satoshi Nakamoto Date: Wed,
Dec 29, 2010 at 10:42 PM To: Mike Hearn mike@plan99.netThread: More BitCoin
questions
I have been working on a Java implementation of the simplified payment
verification, with an eye to building a client that runs on Android
phones. So I've been thinking a lot about storage requirements and the
scalability of BitCoin, which led to some questions that the paper did
not answer (maybe there could be a new version of the paper at some
point, as I think aspects of it are now out of date).
The simplified payment verification in the paper imagined you would receive transactions directly, as with sending to IP address which nobody uses, or a node would index all transactions by public key and you could download them like downloading mail from a mail server.
Instead, I think client-only nodes should receive full blocks so they can scan them for their own transactions. They don't need to store them or index them. For the initial download, they only need to download headers, since there couldn't be any payments before the first time the program was run (a header download command was added in 0.3.18). From then on, they download full blocks (but only store the headers).
Code for client-only mode is mostly implemented. There's a feature branch on github with it, also I'm attaching the patch to this message.
Here's some more about it:
"Here's my client-mode implementation so far. Client-only mode only records block headers and doesn't use the tx index. It can't generate, but it can still send and receive transactions. It's not fully finished for use by end-users, but it doesn't matter because it's a complete no-op if fClient is not enabled. At this point it's mainly documentation showing the cut-lines for client-only re-implementers.
With fClient=true, I've only tested the header-only initial download.
A little background. CBlockIndex contains all the information of the block header, so to operate with headers only, I just maintain the CBlockIndex structure as usual. The nFile/nBlockPos are null, since the full block is not recorded on disk.
The code to gracefully switch between client-mode on/off without deleting blk*.dat in between is not implemented yet. It would mostly be a matter of having non-client LoadBlockIndex ignore block index entries with null block pos. That would make it re-download those as full blocks. Switching back to client-mode is no problem, it doesn't mind if the full blocks are there.
If the initial block download becomes too long, we'll want client mode as an option so new users can get running quickly. With graceful switch-off of client mode, they can later turn off client mode and have it download the full blocks if they want to start generating. They should rather just use a getwork miner to join a pool instead.
Client-only re-implementations would not need to implement EvalScript at all, or at most just implement the five ops used by the standard transaction templates."
Specifically, BitCoin has a variety of magic numbers and neither the
code nor the paper explain where they came from. For example, the fact
that inflation ceases when 21 million coins have been issued. This
number must have been arrived at somehow, but I can't see how.
Educated guess, and the maths work out to round numbers. I wanted something that would be not too low if it was very popular and not too high if it wasn't.
Another is the 10 minute block target. I understand this was chosen to
allow transactions to propagate through the network. However existing
large P2P networks like BGP can propagate new data worldwide in <1
minute.
If propagation is 1 minute, then 10 minutes was a good guess. Then nodes are only losing 10% of their work (1 minute/10 minutes). If the CPU time wasted by latency was a more significant share, there may be weaknesses I haven't thought of. An attacker would not be affected by latency, since he's chaining his own blocks, so he would have an advantage. The chain would temporarily fork more often due to latency.
The final number I'm interested in is the 500kb limit on block sizes.
According to Wikipedia, Visa alone processed 62 billion transactions
in 2009. Dividing through we get an average of 2000 transactions per
second, so peak rate is probably around double that at 4000
transactions/sec. With a ten minute block target, at peak a block
might need to contain 2.4 million transactions, which just won't fit
into 500kb. Is this 500kb a temporary limitation that will be slowly
removed over time from the official client or something more
fundamental?
A higher limit can be phased in once we have actual use closer to the limit and make sure it's working OK.
Eventually when we have client-only implementations, the block chain size won't matter much. Until then, while all users still have to download the entire block chain to start, it's nice if we can keep it down to a reasonable size.
With very high transaction volume, network nodes would consolidate and there would be more pooled mining and GPU farms, and users would run client-only. With dev work on optimising and parallelising, it can keep scaling up.
Whatever the current capacity of the software is, it automatically grows at the rate of Moore's Law, about 60% per year.
diff -u old\db.cpp new\db.cpp
--- old\db.cpp Sat Dec 18 18:35:59 2010
+++ new\db.cpp Sun Dec 19 20:53:59 2010
@@ -464,29 +464,32 @@
ReadBestInvalidWork(
bnBestInvalidWork);
// Verify blocks in the best chain
- CBlockIndex* pindexFork = NULL;
- for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
+ if (!fClient)
{
- if (pindex->nHeight < nBestHeight-2500 && !mapArgs.count("-checkblocks")
)
- break;
- CBlock block;
- if (!block.ReadFromDisk(pindex))
- return error("LoadBlockIndex() : block.ReadFromDisk failed");
- if (!block.CheckBlock())
+ CBlockIndex* pindexFork = NULL;
+ for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
{
- printf("LoadBlockIndex() : *** found bad block at %d, hash=%s\n", pindex->nHeight, pindex->GetBlockHash().
ToString().c_str());
- pindexFork = pindex->pprev;
+ if (pindex->nHeight < nBestHeight-2500 && !mapArgs.count("-checkblocks")
)
+ break;
+ CBlock block;
+ if (!block.ReadFromDisk(pindex))
+ return error("LoadBlockIndex() : block.ReadFromDisk failed");
+ if (!block.CheckBlock())
+ {
+ printf("LoadBlockIndex() : *** found bad block at %d, hash=%s\n", pindex->nHeight, pindex->GetBlockHash().
ToString().c_str());
+ pindexFork = pindex->pprev;
+ }
+ }
+ if (pindexFork)
+ {
+ // Reorg back to the fork
+ printf("LoadBlockIndex() : *** moving best chain pointer back to block %d\n", pindexFork->nHeight);
+ CBlock block;
+ if (!block.ReadFromDisk(
pindexFork))
+ return error("LoadBlockIndex() : block.ReadFromDisk failed");
+ CTxDB txdb;
+ block.SetBestChain(txdb, pindexFork);
}
- }
- if (pindexFork)
- {
- // Reorg back to the fork
- printf("LoadBlockIndex() : *** moving best chain pointer back to block %d\n", pindexFork->nHeight);
- CBlock block;
- if (!block.ReadFromDisk(
pindexFork))
- return error("LoadBlockIndex() : block.ReadFromDisk failed");
- CTxDB txdb;
- block.SetBestChain(txdb, pindexFork);
}
return true;
diff -u old\main.cpp new\main.cpp
--- old\main.cpp Sat Dec 18 18:35:59 2010
+++ new\main.cpp Sun Dec 19 20:53:59 2010
@@ -637,6 +637,9 @@
if (!IsStandard())
return error("AcceptToMemoryPool() : nonstandard transaction type");
+ if (fClient)
+ return true;
+
// Do we already have it?
uint256 hash = GetHash();
CRITICAL_BLOCK(cs_
mapTransactions)
@@ -1308,23 +1311,26 @@
if (!CheckBlock())
return false;
- //// issue here: it doesn't know the version
- unsigned int nTxPos = pindex->nBlockPos + ::GetSerializeSize(CBlock(), SER_DISK) - 1 + GetSizeOfCompactSize(vtx.size(
));
-
- map<uint256, CTxIndex> mapUnused;
- int64 nFees = 0;
- foreach(CTransaction& tx, vtx)
+ if (!fClient)
{
- CDiskTxPos posThisTx(pindex->nFile, pindex->nBlockPos, nTxPos);
- nTxPos += ::GetSerializeSize(tx, SER_DISK);
+ //// issue here: it doesn't know the version
+ unsigned int nTxPos = pindex->nBlockPos + ::GetSerializeSize(CBlock(), SER_DISK) - 1 + GetSizeOfCompactSize(vtx.size(
));
+
+ map<uint256, CTxIndex> mapUnused;
+ int64 nFees = 0;
+ foreach(CTransaction& tx, vtx)
+ {
+ CDiskTxPos posThisTx(pindex->nFile, pindex->nBlockPos, nTxPos);
+ nTxPos += ::GetSerializeSize(tx, SER_DISK);
- if (!tx.ConnectInputs(txdb, mapUnused, posThisTx, pindex, nFees, true, false))
+ if (!tx.ConnectInputs(txdb, mapUnused, posThisTx, pindex, nFees, true, false))
+ return false;
+ }
+
+ if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees))
return false;
}
- if (vtx[0].GetValueOut() > GetBlockValue(pindex->nHeight, nFees))
- return false;
-
// Update block index on disk without changing it in memory.
// The memory index structure will be changed after the db commits.
if (pindex->pprev)
@@ -1378,7 +1384,7 @@
foreach(CBlockIndex* pindex, vDisconnect)
{
CBlock block;
- if (!block.ReadFromDisk(pindex))
+ if (!block.ReadFromDisk(pindex, !fClient))
return error("Reorganize() : ReadFromDisk for disconnect failed");
if (!block.DisconnectBlock(txdb, pindex))
return error("Reorganize() : DisconnectBlock failed");
@@ -1395,7 +1401,7 @@
{
CBlockIndex* pindex = vConnect[i];
CBlock block;
- if (!block.ReadFromDisk(pindex))
+ if (!block.ReadFromDisk(pindex, !fClient))
return error("Reorganize() : ReadFromDisk for connect failed");
if (!block.ConnectBlock(txdb, pindex))
{
@@ -1526,7 +1532,7 @@
txdb.Close();
- if (pindexNew == pindexBest)
+ if (!fClient && pindexNew == pindexBest)
{
// Notify UI to display prev block's coinbase if it was ours
static uint256 hashPrevBestCoinBase;
@@ -1547,10 +1553,6 @@
// These are checks that are independent of context
// that can be verified before saving an orphan block.
- // Size limits
- if (vtx.empty() || vtx.size() > MAX_BLOCK_SIZE || ::GetSerializeSize(*this, SER_NETWORK) > MAX_BLOCK_SIZE)
- return error("CheckBlock() : size limits failed");
-
// Check proof of work matches claimed amount
if (!CheckProofOfWork(GetHash(), nBits))
return error("CheckBlock() : proof of work failed");
@@ -1559,6 +1561,13 @@
if (GetBlockTime() > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
+ if (fClient && vtx.empty())
+ return true;
+
+ // Size limits
+ if (vtx.empty() || vtx.size() > MAX_BLOCK_SIZE || ::GetSerializeSize(*this, SER_NETWORK) > MAX_BLOCK_SIZE)
+ return error("CheckBlock() : size limits failed");
+
// First transaction must be coinbase, the rest must not be
if (vtx.empty() || !vtx[0].IsCoinBase())
return error("CheckBlock() : first tx is not coinbase");
@@ -1623,13 +1632,14 @@
return error("AcceptBlock() : out of disk space");
unsigned int nFile = -1;
unsigned int nBlockPos = 0;
- if (!WriteToDisk(nFile, nBlockPos))
- return error("AcceptBlock() : WriteToDisk failed");
+ if (!fClient)
+ if (!WriteToDisk(nFile, nBlockPos))
+ return error("AcceptBlock() : WriteToDisk failed");
if (!AddToBlockIndex(nFile, nBlockPos))
return error("AcceptBlock() : AddToBlockIndex failed");
// Relay inventory, but don't relay old inventory during initial block download
- if (hashBestChain == hash)
+ if (!fClient && hashBestChain == hash)
CRITICAL_BLOCK(cs_vNodes)
foreach(CNode* pnode, vNodes)
if (nBestHeight > (pnode->nStartingHeight != -1 ? pnode->nStartingHeight - 2000 : 55000))
@@ -2405,6 +2415,8 @@
{
if (fShutdown)
return true;
+ if (fClient && inv.type == MSG_TX)
+ continue;
pfrom->AddInventoryKnown(inv);
bool fAlreadyHave = AlreadyHave(txdb, inv);
@@ -2441,6 +2453,9 @@
if (inv.type == MSG_BLOCK)
{
+ if (fClient)
+ return true;
+
// Send block from disk
map<uint256, CBlockIndex*>::iterator mi = mapBlockIndex.find(inv.hash);
if (mi != mapBlockIndex.end())
@@ -2486,6 +2501,8 @@
else if (strCommand == "getblocks")
{
+ if (fClient)
+ return true;
CBlockLocator locator;
uint256 hashStop;
vRecv >> locator >> hashStop;
@@ -2556,6 +2573,8 @@
else if (strCommand == "tx")
{
+ if (fClient)
+ return true;
vector<uint256> vWorkQueue;
CDataStream vMsg(vRecv);
CTransaction tx;
@@ -2620,6 +2639,33 @@
if (ProcessBlock(pfrom, &block))
mapAlreadyAskedFor.erase(inv);
+ }
+
+
+ else if (strCommand == "headers")
+ {
+ if (!fClient)
+ return true;
+ vector<CBlock> vHeaders;
+ vRecv >> vHeaders;
+
+ uint256 hashBestBefore = hashBestChain;
+ foreach(CBlock& block, vHeaders)
+ {
+ block.vtx.clear();
+
+ printf("received header %s\n", block.GetHash().ToString().
substr(0,20).c_str());
+
+ CInv inv(MSG_BLOCK, block.GetHash());
+ pfrom->AddInventoryKnown(inv);
+
+ if (ProcessBlock(pfrom, &block))
+ mapAlreadyAskedFor.erase(inv);
+ }
+
+ // Request next batch
+ if (hashBestChain != hashBestBefore)
+ pfrom->PushGetBlocks(
pindexBest, uint256(0));
}
diff -u old\main.h new\main.h
--- old\main.h Sat Dec 18 18:35:59 2010
+++ new\main.h Sun Dec 19 20:53:59 2010
@@ -619,6 +619,8 @@
bool ReadFromDisk(CDiskTxPos pos, FILE** pfileRet=NULL)
{
+ assert(!fClient);
+
CAutoFile filein = OpenBlockFile(pos.nFile, 0, pfileRet ? "rb+" : "rb");
if (!filein)
return error("CTransaction::
ReadFromDisk() : OpenBlockFile failed");
@@ -1174,6 +1176,7 @@
bool ReadFromDisk(unsigned int nFile, unsigned int nBlockPos, bool fReadTransactions=true)
{
+ assert(!fClient);
SetNull();
// Open history file to read
@@ -1231,7 +1234,7 @@
//
-// The block chain is a tree shaped structure starting with the
+// The block index is a tree shaped structure starting with the
// genesis block at the root, with each block potentially having multiple
// candidates to be the next block. pprev and pnext link a path through the
// main/longest chain. A blockindex may have multiple pprev pointing back
diff -u old\net.cpp new\net.cpp
--- old\net.cpp Wed Dec 15 22:33:09 2010
+++ new\net.cpp Sun Dec 19 21:51:27 2010
@@ -51,7 +51,15 @@
pindexLastGetBlocksBegin = pindexBegin;
hashLastGetBlocksEnd = hashEnd;
- PushMessage("getblocks", CBlockLocator(pindexBegin), hashEnd);
+ /// Client todo: After the initial block header download, start using getblocks
+ /// here instead of getheaders. For blocks generated after the first time the
+ /// program was run, we need to download full blocks to watch for received
+ /// transactions in them. We're able to download headers only for blocks
+ /// generated before we ever ran because they can't contain txes for us.
+ if (::fClient)
+ PushMessage("getheaders", CBlockLocator(pindexBegin), hashEnd);
+ else
+ PushMessage("getblocks", CBlockLocator(pindexBegin), hashEnd);
}
From: Mike Hearn Date: Thu, Dec 30,
2010 at 12:27 AM To: Satoshi Nakamoto satoshin@gmx.comThread: More BitCoin
questions
Thanks for the info.
I reached the same conclusions about client only nodes and this is
what I've been implementing. I'm nearly there ..... I have block chain
download, parsing and verification of the blocks/transactions done,
with creation of spend transactions almost done.
v1 will basically do as you propose, with the possible optimization of
storing only the blocks needed to form the block locator (with the
exponential thinning). As Android provides local storage that is
private to the app, you don't need to store the entire block chain to
be able to accept new blocks ... just enough to ensure you can always
stay on the longest chain.
By the way, your code is easy to read and has been an invaluable
reference. So thanks for that.
In v2 I'm thinking of showing transactions before they are integrated
into the block chain by running secure/locked down relay nodes that
send messages to the phones when a transaction is accepted into the
memory pool. Android provides a secure, low power back channel to
every phone. Messages are stored server side if the device is offline
and apps are automatically started on the phone to handle incoming
messages.
So as long as the relay nodes are unhacked, this system should give
enough trust that low value transactions can be shown in the UI
immediately. It introduces some centralization/single points of
failure, but if the relay mechanism dies or is hacked, the damage only
lasts for 10 minutes until the new blocks are downloaded.
> Client-only re-implementations would not need to implement EvalScript at
> all, or at most just implement the five ops used by the standard transaction
> templates."
Indeed, there's no point in client-only implementations implementing
EvalScript because they can't verify transactions aren't being double
spent without storing and indexing the entire block chain. My code
parses the scripts and then relies on them having a standard
structure, but doesn't actually run them.
> Educated guess, and the maths work out to round numbers. I wanted something
> that would be not too low if it was very popular and not too high if it
> wasn't.
It'd be interesting to see the working for this. In some sense the
number of coins is arbitrary as the nanocoin representation means the
issuance is so huge it's practically infinite.
> A higher limit can be phased in once we have actual use closer to the limit
> and make sure it's working OK.
It'd be worth implementing some kind of more robust auto update
mechanism, or a schedule for the phase in of this, if only because
when people evaluate "is BitCoin worth my time and effort" a solid
plan for scaling up is good to have written down.
I'm not worried about the physical capabilities of the hardware, but
more protocol ossification as the app is reimplemented and nodes which
don't auto-update themselves increase in number. Client only
reimplementations pose no problems of course, but other systems like
SMTP have proven impossible to globally upgrade despite having
extension mechanisms built in .... just too many implementations and
too many installations.
Gavin Andresen wrote:
> I'd be happy to talk to Rainey;
Great
> Satoshi, I assume you don't want to
> deal with press/PR/interviews ?
True
> We could decline to talk to the press-- Satoshi, I know you've
> expressed concern about bitcoin growing too big too fast, and being
> unable to keep up with traffic/attacks/feature requests/etc. But I
> don't think ignoring the press will make them go away; they'll just
> talk to somebody else. I think it is better to give a realistic
> impression of bitcoin (it is cutting-edge, beta software that is still
> being developed, it is not poised to replace PayPal or the Euro
> anytime soon, etc) rather than let somebody over-enthusiastic become
> "the unofficial bitcoin spokesperson."
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.
More BitCoin questions — reply 4
Mike Hearn correspondence (Satoshi Nakamoto) — January 07, 2011 — source: hearn-thread3.html#msg-4
From: Satoshi Nakamoto Date: Fri,
Jan 7, 2011 at 1:00 PM To: Mike Hearn mike@plan99.netThread: More BitCoin
questions
I reached the same conclusions about client only nodes and this is
what I've been implementing. I'm nearly there ..... I have block chain
download, parsing and verification of the blocks/transactions done,
with creation of spend transactions almost done.
That's great! The first client-only implementation will really start to move things to the next step. Is it going to be open source, or Google proprietary?
From: Mike Hearn Date: Fri, Jan 7,
2011 at 1:24 PM To: Satoshi Nakamoto satoshin@gmx.comThread: More BitCoin
questions
> That's great! The first client-only implementation will really start to
> move things to the next step. Is it going to be open source, or Google
> proprietary?
Open source. It has to be - I am developing it as a personal project
in my spare time and Googles policy is that this is only allowed if
you open source the results. But I would have done that anyway.
I managed to spend my first coins on the testnet with my app a few
days ago, hopefully will get another chance to make progress this
weekend. Probably will have something to show publically sometime in
Feb, touch wood.
More BitCoin questions — reply 6
Mike Hearn correspondence (Satoshi Nakamoto) — January 10, 2011 — source: hearn-thread3.html#msg-6
From: Satoshi Nakamoto Date: Mon,
Jan 10, 2011 at 4:34 PM To: Mike Hearn mike@plan99.netThread: More BitCoin
questions
Open source.
Perfect. Once your code shows how to simplify it down, other authors can follow your lead. Client is a less daunting challenge than full implementation. If it's within reach of more developers, they'll come up with more polished UI and other things I didn't think of. I expect the original software will become the industrial old thing used by GPU farms and pool servers.
BTW, later a good feature for a client version is to keep your private keys encrypted and you give your password each time you send.
I managed to spend my first coins on the testnet with my app a few
days ago, hopefully will get another chance to make progress this
weekend. Probably will have something to show publically sometime in
Feb, touch wood.
Great, keep me updated.
I wanted something
that would be not too low if it was very popular and not too high if it
wasn't.
It'd be interesting to see the working for this. In some sense the
number of coins is arbitrary as the nanocoin representation means the
issuance is so huge it's practically infinite.
It works out to an even 10 minutes per block:
21000000 / (50 BTC * 24hrs * 365days * 4years * 2) = 5.99 blocks/hour
I fudged it to 364.58333 days/year. The halving of 50 BTC to 25 BTC is after 210000 blocks or around 3.9954 years, which is approximate anyway based on the retargeting mechanism's best effort.
I thought about 100 BTC and 42 million, but 42 million seemed high.
I wanted typical amounts to be in a familiar range. If you're tossing around 100000 units, it doesn't feel scarce. The brain is better able to work with numbers from 0.01 to 1000.
If it gets really big, the decimal can move two places and cents become the new coins.
From: Mike Hearn Date: Mon, Jan 10,
2011 at 4:48 PM To: Satoshi Nakamoto satoshin@gmx.comThread: More BitCoin
questions
Ah, of course, that makes sense.
By the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum:
http://www.bitcoin.org/smf/
index.php?topic=2699.0
Hal (i presume this is Hal Finney) seems to think the curve is at higher risk of attack than random curves. I guess you chose secp256k1 for the mentioned performance improvement?
[Quoted text hidden]
More BitCoin questions — reply 8
Mike Hearn correspondence (Satoshi Nakamoto) — January 10, 2011 — source: hearn-thread3.html#msg-8
From: Satoshi Nakamoto Date: Mon,
Jan 10, 2011 at 8:47 PM To: Mike Hearn mike@plan99.netThread: More BitCoin
questions
By the way, if you didn't see it already, there's a discussion on the security of secp256k1 on the forum:
http://www.bitcoin.org/smf/ind
ex.php?topic=2699.0
Hal (i presume this is Hal Finney)
Yes, it's him. He was supportive on the Cryptography list and ran one of the first nodes.
seems to think the curve is at higher risk of attack than random curves. I guess you chose secp256k1 for the mentioned performance improvement?
I must admit, this project was 2 years of development before release, and I could only spend so much time on each of the many issues. I found guidance on the recommended size for SHA and RSA, but nothing on ECDSA which was relatively new. I took the recommended key size for RSA and converted to equivalent key size for ECDSA, but then increased it so the whole app could be said to be 256-bit security. I didn't find anything to recommend a curve type so I just... picked one. Hopefully there is enough key size to make up for any deficiency.
At the time, I was concerned whether the bandwidth and storage sizes would be practical even with ECDSA. RSA's huge keys were out of the question. Storage and bandwidth seemed tighter back then. I felt the size was either only just becoming practical, or would be soon. When I presented it, I was surprised nobody else was concerned about size, though I was also surprised how many issues they argued, and more surprised that every single one was something I had thought of and solved.
As it turns out, ECDSA verification time may be the greater bottleneck. (In my tests, OpenSSL was taking 3.5ms per ECDSA verify, or about 285 verifies per second) Client versions bypass the problem.
As things have evolved, the number of people who need to run full nodes is less than I originally imagined. The network would be fine with a small number of nodes if processing load becomes heavy.
Martti,Thank you for the pdf. It looks great. I do not see a date on it. When was it written?Mr. Mark Herpel of Digital Gold Currency Magazine brought Bitcoin to my attention for inclusion in my thesis. The thesis working title is: Digital Currency Systems: Emerging B2B e-Commerce Alternative During Monetary Crisis in the United States. I discuss the five types of systems per Mr. Herpels suggestion.Appreciate it and hope to talk soon.C.[REDACTED-NAME], CeM, PMP: PMI certified[REDACTED-LOCATION][REDACTED-PHONE]--- On Mon, 1/24/11, mmalmi@cc.hut.fi <mmalmi@cc.hut.fi> wrote:From: mmalmi@cc.hut.fi <mmalmi@cc.hut.fi>Subject: Re:To: "[REDACTED-NAME]"
<[REDACTED-EMAIL]>Date: Monday, January 24, 2011, 1:22 AMHi [REDACTED-NAME],Thanks for your interest in Bitcoin, feel free to cite. There's also Satoshi Nakamoto's paper available at http://www.bitcoin.org/bitcoin.pdf if you want something with a more formal touch. Please let us know when your thesis is finished!-Martti> Martti Malmi> Currently I am a full time student at-> [REDACTED-URL]> Aspen University, in Denver, CO, [REDACTED-PHONE].> Masters of Science in Technology and Innovation.> > I am writing my Thesis under the subject heading, digital currency systems. May I cite your site in my Thesis?> > Thank you.> [REDACTED-NAME]> [REDACTED-NAME], CeM,
PMP: PMI certified> [REDACTED-LOCATION]> [REDACTED-PHONE]> > >
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.
mmalmi@cc.hut.fi wrote:
> Can you comment on this?
>
> ----- Forwarded message from [REDACTED-EMAIL] -----
> Date: Mon, 24 Jan 2011 00:32:48 -0800 (PST)
> From: "[REDACTED-NAME]" <[REDACTED-EMAIL]>
> Reply-To: "[REDACTED-NAME]" <[REDACTED-EMAIL]>
> Subject: Re:
> To: mmalmi@cc.hut.fi
>
> Martti,
> Thank you for the pdf. It looks great. I do not see a date on it. When
> was it written?
>
> Mr. Mark Herpel of Digital Gold Currency Magazine brought Bitcoin to my
> attention for inclusion in my thesis. The thesis working title is:
> Digital Currency Systems: Emerging B2B e-Commerce Alternative During
> Monetary Crisis in the United States. I discuss the five types of
> systems per Mr. Herpels suggestion.
>
> Appreciate it and hope to talk soon.
>
> C.
>
> [REDACTED-NAME], CeM, PMP: PMI certified
> [REDACTED-LOCATION]
> [REDACTED-PHONE]
>
> --- On Mon, 1/24/11, mmalmi@cc.hut.fi <mmalmi@cc.hut.fi> wrote:
>
> From: mmalmi@cc.hut.fi <mmalmi@cc.hut.fi>
> Subject: Re:
> To: "[REDACTED-NAME]" <[REDACTED-EMAIL]>
> Date: Monday, January 24, 2011, 1:22 AM
>
> Hi [REDACTED-NAME],
>
> Thanks for your interest in Bitcoin, feel free to cite. There's also
> Satoshi Nakamoto's paper available at http://www.bitcoin.org/bitcoin.pdf
> if you want something with a more formal touch. Please let us know when
> your thesis is finished!
>
>
> -Martti
>
>> Martti Malmi
>> Currently I am a full time student at-
>> [REDACTED-URL]
>> Aspen University, in Denver, CO, [REDACTED-PHONE].
>> Masters of Science in Technology and Innovation.
>>
>> I am writing my Thesis under the subject heading, digital currency
>> systems. May I cite your site in my Thesis?
>>
>> Thank you.
>> [REDACTED-NAME]
>> [REDACTED-NAME], CeM, PMP: PMI certified
>> [REDACTED-LOCATION]
>> [REDACTED-PHONE]
>>
>>
>>
>
>
>
>
>
+1781.28
-22.63 October hosting
-28.70 November hosting
-30.36 December hosting
-48.35 January hosting (server upscaled to 1024MB RAM)
+0.78 Annual interest on deposit
-------
+1652.02
Since I'm no longer maintaining bitcoinexchange.com, I'm returning the
750€ to the project budget. I'll do this when I get a payment from the
SMS gateway provider.
Looks like an excellent opportunity to reach an important audience
that doesn't follow Slashdot or Reddit. I'd recommend this job for
Gavin or Bruce Wagner. Or maybe there can be two attendees. S3052 from
the forum also seemed potentially competent.
Gavin, would you be interested in organizing this?
> Hello,
>
> I am writing you on behalf of the EPCA Conference because we are
> interested to learn more about Bitcoin. Possibly Bitcoin is an
> interesting topic for the upcoming conference 4-6 April in Amsterdam.
>
> At this top rated conference we deal with the key strategic
> developments in the 'transaction industry' so not limited to
> payments. The event is truly 'professional for professional', so
> every presentation is screened on quality and relevance (no sales
> pitches). See also:
> www.epcaconference.com<http://www.epcaconference.com> .
>
> Since we discuss the most relevant topics in the industry, I would
> like to investigate whether the Bitcoin paradigm is interesting for
> the attendees. This should give the attendees (bankers and other
> financial professionals) a lot of inspiration for their own
> business. At the same time it is a good opportunity to position
> Bitcoin within the international audience, to gain unique strategic
> insights and to network within the European professional scene.
>
> Can we have contact this week to elaborate this further? Thank you
> in advance,
>
> Look forward hearing from you,
>
> Kind regards,
> [REDACTED-NAME]
> EPCA Conference Chaiman
>
>
>
> [REDACTED-NAME] | Innopay
> [REDACTED-EMAIL]<mailto:[REDACTED-EMAIL]>
> [REDACTED-PHONE]
>
> 'Imagine - Create - Innovate: Unlocking the Payments Potential'
> 10th international EPCA conference
> 4-6 April 2011, Amsterdam
> www.epcaconference.com<http://www.epcaconference.com/>
>
> Triport III 7th floor
> Westelijke Randweg 43
> 1118 CR SCHIPHOL AIRPORT
> The Netherlands
>
>
Hello,
Thanks for contacting and sorry for the late response. EPCA seems very
interesting for the Bitcoin project, a good opportunity for
networking. I'll find somebody who can work with you on this. In the
meantime please ask me for any questions.
Best regards,
Martti Malmi
Bitcoin project developer
> Hello,
>
> I am writing you on behalf of the EPCA Conference because we are
> interested to learn more about Bitcoin. Possibly Bitcoin is an
> interesting topic for the upcoming conference 4-6 April in Amsterdam.
>
> At this top rated conference we deal with the key strategic
> developments in the 'transaction industry' so not limited to
> payments. The event is truly 'professional for professional', so
> every presentation is screened on quality and relevance (no sales
> pitches). See also:
> www.epcaconference.com<http://www.epcaconference.com> .
>
> Since we discuss the most relevant topics in the industry, I would
> like to investigate whether the Bitcoin paradigm is interesting for
> the attendees. This should give the attendees (bankers and other
> financial professionals) a lot of inspiration for their own
> business. At the same time it is a good opportunity to position
> Bitcoin within the international audience, to gain unique strategic
> insights and to network within the European professional scene.
>
> Can we have contact this week to elaborate this further? Thank you
> in advance,
>
> Look forward hearing from you,
>
> Kind regards,
> [REDACTED-NAME]
> EPCA Conference Chaiman
>
>
>
> [REDACTED-NAME] | Innopay
> [REDACTED-EMAIL]<mailto:[REDACTED-EMAIL]>
> [REDACTED-PHONE]
>
> 'Imagine - Create - Innovate: Unlocking the Payments Potential'
> 10th international EPCA conference
> 4-6 April 2011, Amsterdam
> www.epcaconference.com<http://www.epcaconference.com/>
>
> Triport III 7th floor
> Westelijke Randweg 43
> 1118 CR SCHIPHOL AIRPORT
> The Netherlands
>
>
> I have not sent a message to the sourceforge bitcoin-list mailing list
> because I don't think I have permission; Satoshi, can you give me
> permission, encrypt the mailman password with my public key and send
> it to me, or just post the announcement?
Martti should give you the Drupal admin password.
Any subscriber can post to bitcoin-list. Here's the admin password in
case you need it later.
Gavin:
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0
hQIOAxfAPINgyySWEAf9GHyuMqxkhoBe96hbHoFPIR4ORpMS/v2mpCT70UmgTt46
GVO5MeEOFE4JUqltYUaAE2u7e7+BbyNFeNk4o0kwJIWUXbRoBHj59vx+yzmeRLd9
YxTWxZA2zOVcYcYoDkiYAatwlQWQefzwYFcCnBSSsY1F9XLHMtLqNadhftOregoE
5Prhjk4ScAEOAmJ2CfYvWLD6FPAe4s6nXzP656oQghMgUivYoowHAjGUSvd8f1Qb
fkV0isGIYCpHCOSZDZpysPCm63ibEeiuylvkT7Ayj2HoonqypFdv05mtyS7Jtq6a
s06UqjLSyICoGJVk4x5HZhusgmbqViLvb6gM+iadbQf/U9KEKA5KyF0JvjYlx97k
Bm7WpBIxKnP6Migl/Otol85EYt9rWN0lozLGw5Ko1JTZzXv3RrTsJafUYnDyAvtR
20JExoG84LatTeFiTqVWHiWZbYG2ECJHTO6jOmITvNvq/OgCID4hQvjvNQiXghae
qzolzmZVEwDGAybWJoSvAsXjDWbAyHt9WJztHPgVRxgTBrnhoLAX0FwKGTCr7L/t
emVEUqgEf3WqmljD+cCXSNVloQxGmPvaSsbITIZvX/emwq4MAC+SuRmJLJp6kSmu
UhkxZMipvYHfyBPXoonAM7oYXNIaFQryS66UlEziSUevvU8TXiZMeUyyiMirOBXC
itKhAedpc7NQYG+/KohTS0U9QfdygBfE2o6M96tRKFdMmbQz3Gyq0BaBpp98+ve+
VOVp90mYv9zq43G7tHnZektEjGzplHj0HzWhfbiy2dBrDGhkByYN4G6kX0JvU4ZX
/ixmbOf5qZPqcgmz7fYDxKnkUQVumoEIfNXrUlAPcI2Ql9TnY0NIg9ZIVOGeT4lE
80kYloQVdCdnrJ7yLWexO0W1kSs=
=S7eV
-----END PGP MESSAGE-----
Martti:
-----BEGIN PGP MESSAGE-----
Version: GnuPG v1.4.7 (MingW32) - WinPT 1.2.0
hQEMA+kEt/4bukJEAQgAlt5/Ks5pZPeusK0yefyMn7BqIVcOVHDaXbnf4dLKqq5J
6bKyMlkyYjhm1itZabi+IaV9k+1r7Wo50qOqfZNCSmG63hX3asXWd7QxThj4KDxr
fvuUfiduf2AyZcB4r/baw1hsdC3VGxQutU0ookuJqfvCIse77clS2WimKJ5hrh5G
KVdGApk3TxbILknalIs3mUw81sL0nvbO/aNrHiiNj44YU3Ehf5CieEJInHeYGTsJ
AABLZcH6B7nymA8D4nrAAnDcjcSE8+iWMOtzI2duCHKtA+LVJOsg8n/zHqK9SZNF
w+Xud7mBi/ZvnFGwCZh7cqJ/jZhNLLTQHiLr8M+i7dKhAekFho8aarOV9V4Cp2hT
a8bQdbgwsednyjCzaq+C8xU+aYJcAV95qK6QG2hlT8xpDU2KHBHWIjDmPKlzgvKb
8/dQo5VDvtQkdyvrd9pMJeOUxFKEVW5ph+4LzKjKEWE1kJhzAwbxQMNKkXLzZJIa
hJMNAVHDjnYcuI8EgJT+TjH2Kx+KwHX/OEOFaDXGP7XwMOuVZTVtbXnsJ24SFa1i
m4U=
=0TBL
-----END PGP MESSAGE-----
From: Mike Hearn Date: Mon, Mar 7,
2011 at 2:13 PM To: Satoshi Nakamoto satoshin@gmx.comThread: Open sourced
my Java SPV impl
Hi Satoshi,
I hope you are doing well. I finally got all the lawyers happy enough
to release BitCoinJ under the Google name using the Apache 2 license:
http://www.bitcoin.org/smf/
index.php?topic=4236.0
It's incomplete - notably it doesn't properly handle block chain
splits yet - but the rest is coming. I put a lot of work into
documentation and comments so hopefully it'll open up BitCoin to a new
audience who weren't able to understand/build the current code. Over
the next month or two I'll be finishing off some of the bigger missing
pieces for a full client-mode implementation.
I know you are busy right now but I'm hoping you can find time to
answer a few questions I had.
As part of doing full SPV I'm thinking of adding a getmerklebranch
message to the protocol. This would return a set of {blockhash,
branch} pairs given tx hashes, so allowing verification of a broadcast
transaction before it was incorporated into a block without storing
the full chain. Does that approach sound good to you?
Also, I've been thinking of exploring different transaction types
lately, eg by removing the IsStandard() checks for the testnet. It's
clear you put a lot of thought into transactions beyond simply moving
coins around up front, but unfortunately none of it was in the paper
or documented in the code. Escrow, multi-pay and so on are all
interesting but I was wondering if you could compile a list of ideas
for things we can do with the scripting language at some point.
Finally, the code that allows for transaction replacement has been
disabled but the comment doesn't say why. Is this just to reduce the
attack surface/complexity or is there a deeper reason? I haven't fully
understood why sequence numbers are a property of the tx inputs rather
than the tx itself.
Hope you can find the time/energy to rejoin us soon! I don't know if
you've seen this:
http://bitcoin.sipa.be/speed-
lin.png
but it's exciting times for the network!
thanks!
/mike
Open sourced my Java SPV impl — reply 2
Mike Hearn correspondence (Satoshi Nakamoto) — March 09, 2011 — source: hearn-thread4.html#msg-2
From: Satoshi Nakamoto Date: Wed,
Mar 9, 2011 at 5:15 PM To: Mike Hearn mike@plan99.netThread: Open sourced
my Java SPV impl
I hope you are doing well. I finally got all the lawyers happy enough
to release BitCoinJ under the Google name using the Apache 2 license:
It's incomplete - notably it doesn't properly handle block chain
splits yet - but the rest is coming. I put a lot of work into
documentation and comments so hopefully it'll open up BitCoin to a new
audience who weren't able to understand/build the current code. Over
the next month or two I'll be finishing off some of the bigger missing
pieces for a full client-mode implementation.
That's great news! Much complexity can be left behind in a clean rewrite with only client requirements, and it opens it to Java developers too.
I know you are busy right now but I'm hoping you can find time to
answer a few questions I had.
I'm happy to answer any questions.
As part of doing full SPV I'm thinking of adding a getmerklebranch
message to the protocol. This would return a set of {blockhash,
branch} pairs
That's a CMerkleTx
given tx hashes, so allowing verification of a broadcast
transaction before it was incorporated into a block without storing
the full chain. Does that approach sound good to you?
I don't understand. A merkle branch links a tx back to a block, which only has significance if the block exhibits proof-of-work. Linking back to an as-yet unsolved block proves nothing.
Network nodes are able to verify 0-conf txes because they have the complete tx index, so they can:
1) verify signatures against dependencies.
2) say that they haven't seen another spend yet, because they know about every tx in existence.
Are you talking about CMerkleTxes for the tx's dependencies? That would get part 1), but not part 2).
If you don't know about all txes in existence, I don't know how to do 2). You could only rely on trusting other nodes for that. That trust can be distributed over multiple nodes. Nodes only relay transactions they accept as valid. If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw.
Also, I've been thinking of exploring different transaction types
lately, eg by removing the IsStandard() checks for the testnet.
Very good idea. That should definitely be allowed on -testnet.
It's
clear you put a lot of thought into transactions beyond simply moving
coins around up front, but unfortunately none of it was in the paper
or documented in the code. Escrow, multi-pay and so on are all
interesting but I was wondering if you could compile a list of ideas
for things we can do with the scripting language at some point.
Finally, the code that allows for transaction replacement has been
disabled but the comment doesn't say why. Is this just to reduce the
attack surface/complexity or is there a deeper reason?
Just to reduce surface area. It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime. It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently.
See these threads:
http://www.bitcoin.org/smf/ind
ex.php?topic=1786.msg22119#msg
22119
http://www.bitcoin.org/smf/ind
ex.php?topic=2181.msg28729#msg
28729
I haven't fully
understood why sequence numbers are a property of the tx inputs rather
than the tx itself.
It's for contracts. An unrecorded open transaction can keep being replaced until nLockTime. It may contain payments by multiple parties. Each input owner signs their input. For a new version to be written, each must sign a higher sequence number (see IsNewerThan). By signing, an input owner says "I agree to put my money in, if everyone puts their money in and the outputs are this." There are other options in SignatureHash such as SIGHASH_SINGLE which means "I agree, as long as this one output (i.e. mine) is what I want, I don't care what you do with the other outputs.". If that's written with a high nSequenceNumber, the party can bow out of the negotiation except for that one stipulation, or sign SIGHASH_NONE and bow out completely.
The parties could create a pre-agreed default option by creating a higher nSequenceNumber tx using OP_CHECKMULTISIG that requires a subset of parties to sign to complete the signature. The parties hold this tx in reserve and if need be, pass it around until it has enough signatures.
One use of nLockTime is high frequency trades between a set of parties. They can keep updating a tx by unanimous agreement. The party giving money would be the first to sign the next version. If one party stops agreeing to changes, then the last state will be recorded at nLockTime. If desired, a default transaction can be prepared after each version so n-1 parties can push an unresponsive party out. Intermediate transactions do not need to be broadcast. Only the final outcome gets recorded by the network. Just before nLockTime, the parties and a few witness nodes broadcast the highest sequence tx they saw.
From: Mike Hearn Date: Wed, Mar 9,
2011 at 5:39 PM To: Satoshi Nakamoto satoshin@gmx.comThread: Open sourced
my Java SPV impl
If you don't know about all txes in existence, I don't know how to do 2). You could only rely on trusting other nodes for that. That trust can be distributed over multiple nodes. Nodes only relay transactions they accept as valid. If you receive inv messages for a tx from all the nodes you're connected to, they're attesting that it's valid and the first spend they saw.
Good point. I was talking about verifying the inputs yes, but it is indeed pointless unless you hear about all open transactions as well. So being able to fetch a CMerkleTx is not important.
Just to reduce surface area. It wouldn't help with increasing tx fee. A tx starts being valid at nLockTime. It wouldn't work to have a tx that stops being valid at a certain time; once a tx ever becomes valid, it must stay valid permanently.
See these threads:
http://www.bitcoin.org/smf/
index.php?topic=1786.msg22119#
msg22119
http://www.bitcoin.org/smf/
index.php?topic=2181.msg28729#
msg28729
I see. So right now fees are tricky because you have to decide up front what the fee should be, and if you guess too low, there's no way to correct the transaction and though the network will eventually forget it, your wallet still records that you spent the coins. This has already started happening.
It's for contracts.
Ah ha. A whole unexplored area of the system opens up before my eyes :-) The concept of forming distributed contracts and escrow transactions without needing to trust an intermediary is a concept nearly as novel as BitCoin itself, I think.
I have more questions!
There's an unfinished part of the protocol that deals with setting up publisher/subscriber channels for distributed routing via the network. What was the purpose of this? Was the idea to have a p2p market or did it have some kind of lower level function, like perhaps broadcasting expected tx fees?
There was an interesting discussion of generalizing BitCoin some months ago, but we struggled to fully understand how you planned to achieve it. I think I understood the concept of placing another merkle tree on top of multiple separate chains:
http://www.bitcoin.org/smf/
index.php?topic=3414.msg48171#
msg48171
But I didn't understand your comment about having 200 bytes for backwards compatibility. Also, I guess this is obvious, but to be super clear - in your idea the alternative chains would share exactly the same format and sets of verification rules as BitCoin (the same script language etc), so all miners can verify all blocks even if they are non-financial in nature? And then the point of having separate block chains is simply to manage storage costs and bandwidth for client-mode implementations?
Thanks!
Open sourced my Java SPV impl — reply 4
Mike Hearn correspondence (Satoshi Nakamoto) — March 09, 2011 — source: hearn-thread4.html#msg-4
From: Satoshi Nakamoto Date: Wed,
Mar 9, 2011 at 7:39 PM To: Mike Hearn mike@plan99.netThread: Open sourced
my Java SPV impl
See these threads:
http://www.bitcoin.org/smf/ind
ex.php?topic=1786.msg22119#msg
22119
http://www.bitcoin.org/smf/ind
ex.php?topic=2181.msg28729#msg
28729
I see. So right now fees are tricky because you have to decide up front what the fee should be, and if you guess too low, there's no way to correct the transaction and though the network will eventually forget it, your wallet still records that you spent the coins. This has already started happening.
The network won't forget, and the owner's client will keep rebroadcasting it. The overflow transaction was remembered by the network for several months even as the remaining 0.3.8 nodes diminished.
Priority includes age, so as a transaction waits it ages and will eventually have enough priority.
See one of the links above where I contemplate sending an honest double-spend to increase the fee. It's a lot of work but could be done. I don't think it's worth it right now.
The current system, where nodes make sure to include enough fee for current conditions and the network makes sure all transactions get processed eventually, works well enough. Gavin is fixing the oversight where nodes didn't check the priority of their own transactions when writing them.
Users still worried about processing speed uncertainty should think of it as encouragement to include a fee.
There's an unfinished part of the protocol that deals with setting up publisher/subscriber channels for distributed routing via the network. What was the purpose of this? Was the idea to have a p2p market or did it have some kind of lower level function, like perhaps broadcasting expected tx fees?
I was trying to implement an eBay style marketplace built in to the client. Publish/subscribe would be used for broadcasting product offers and ratings/reviews. Your reviews would be weighted by the blocks you've generated. I rightly abandoned it in favour of JSON-RPC, so other authors could implement it externally. The publish/subscribe "meet in the middle" mechanism was an interesting concept, but nothing remains that uses it.
It was part of writing code to explore the most technically demanding use cases and make sure Bitcoin could support everything that might be needed in the future, given the locked-in nature of the rules once the block chain started.
There was an interesting discussion of generalizing BitCoin some months ago, but we struggled to fully understand how you planned to achieve it. I think I understood the concept of placing another merkle tree on top of multiple separate chains:
http://www.bitcoin.org/smf/in
dex.php?topic=3414.msg48171#ms
g48171
But I didn't understand your comment about having 200 bytes for backwards compatibility. Also, I guess this is obvious, but to be super clear - in your idea the alternative chains would share exactly the same format and sets of verification rules as BitCoin (the same script language etc), so all miners can verify all blocks even if they are non-financial in nature? And then the point of having separate block chains is simply to manage storage costs and bandwidth for client-mode implementations?
No, other chains do not follow Bitcoin's rules. They are completely independent chains. They share nothing except the miners. The other network's definition of proof-of-work is to make a solved (according to their own chain's difficulty) Bitcoin-format block that has a hash of their own block in it. They don't care if the Bitcoin block is valid or used by Bitcoin, but it allows miners to work both chains at once.
Procedure to hash a BitDNS block:
- hash the BitDNS block
- construct a Bitcoin block
- insert the BitDNS hash into the scriptSig of tx 0 in the Bitcoin block
- hash the Bitcoin block
The BitDNS block is valid if that hash is below BitDNS's target.
The BitDNS block needs to have with it about 200 bytes of data needed to reconstruct the Bitcoin block used in the hash:
- the Bitcoin block header
- the merkle branch to tx 0
- tx 0 (btw, tx 0's prev hash is always 0 so leaving that out saves 32 bytes)
Note that it doesn't matter if the fodder "Bitcoin block" was actually valid in the Bitcoin chain, though it could have been. To BitDNS, it's just a bunch of salt necessary to do its convoluted hash calculation. If a miner is only mining for BitDNS and doesn't care about Bitcoin, it would use a blank Bitcoin block of all zeroes (except the nonce).
To further expand the idea for extensibility, consider instead of putting the BitDNS block hash in tx 0, you put the root of a merkle tree that includes BitDNS. This is the merkle tree that is conceptually at the top.
From: Mike Hearn Date: Mon, Apr 18,
2011 at 11:14 PM To: Satoshi Nakamoto satoshin@gmx.comThread: Holding
coins in an unspendable state for a rolling time window
Hello Satoshi,
I hope this mail finds you well. Recently I've been thinking about how
BitCoin can help handle internet abuse and would appreciate your
thoughts.
My "day job" is on the Google abuse team. We make extensive use of
phone verification to control outbound spam from our network. Facebook
and Craigslist do the same. Phone verification works well because
phone numbers are something most people have access to at least one or
two of, but rarely more. Yet it has significant downsides - it's
expensive (for us), flaky, some people don't like the privacy
implications, and some spam is profitable enough that buying lots of
SIM cards is worth it.
It would be ideal if BitCoins could be put up as collateral against an
account. The amount put up would help determine the limits the system
placed on your behavior (eg how much mail you can send), in an
anonymous and private way. But how to implement this?
Burning coins forever is easy, just set the only output to be <pubkey>
OP_FALSE. Now you can sign some server-provided challenge with that
key and prove you did indeed burn those coins. A key would only be
usable with one account so spammers cannot simply put up a huge
collateral and then resell signatures generated with that key. If the
account was found to be abused it'd be terminated like today, and the
coins would be "gone".
But people do come and go from these big networks and the thought of
losing the coins if you quit Google to run your own mail is
unappealing. It would be ideal if coins could be locked up for a
period of time such that they cannot be spent until time X, where X
can be constantly pushed into the future if the owner desires it but
otherwise the coins eventually become spendable again. To verify your
Google account, you would take some amount of coins (say 10) and set
it up so you cannot spend them for 6 months.
The script language has no concept of time. OP_BLOCKNUMBER was ruled
out because re-orgs could potentially invalidate entire chains of
transactions. But is an OP_DAY feasible? I'm thinking of an opcode
that returns the timestamp from the block header, but rounded to the
nearest day to handle the natural clock drift seen in the block chain.
If it could work then a TX that ties up coins until past a certain day
is easy to construct. Updating it so the deadline is constantly moving
is harder. A simple brute force solution is to require the user to put
up 2x the coins such that at the point the first tx is about to expire
and become spendable again, the second tx is created. In this way you
always have at least one tx of sufficiently distant deadline to act as
collateral. But this is inelegant. A better way would be to introduce
a new rule allowing a tx to connect to such an output before the
deadline has passed, as long as the output of that tx is once again a
deadlined output of the same form. However this is less general than
the scripting language so is also somewhat inelegant.
What do you think?
Holding coins in an unspendable state for a rolling time window — reply 2
Mike Hearn correspondence (Satoshi Nakamoto) — April 20, 2011 — source: hearn-thread5.html#msg-2
From: Satoshi Nakamoto Date: Wed,
Apr 20, 2011 at 11:39 AM To: Mike Hearn mike@plan99.netThread: Holding coins
in an unspendable state for a rolling time window
If the script language is not stateless, if it has access to any outside information that changes or varies between nodes, attackers can use it to fork the chain. The only exception is if it is always false before a certain time and permanently true after, which is implemented with nLockTime.
Since Google is trusted, couldn't users pay a token deposit to Google and Google pays them back when they close the account?
To answer your question though, yes it can be done without using trust:
Tx 1 from User pays to a script that requires the signature of both Google and User to spend.
Tx 2 (the contract) spends Tx 1 and pays it to User. nLockTime is the time to release the money.
Steps:
1) Google gives User a pubkey to use in creating Tx 1.
2) User privately creates Tx 1, does not broadcast it yet.
3) User gives the hash of Tx 1 to Google.
4) Google signs its part of Tx 2, with nLockTime set, and gives it to User.
5) User broadcasts Tx 1.
6) User signs his half of Tx 2 and broadcasts it.
With these steps, the user already has Google's signed half of Tx 2 in hand before he broadcasts Tx 1, so he is assured of what bargain he is signing the money to.
This is the general pattern for safely signing contracts. Tx 2 is prepared first so the parties know what they're paying into. Tx 1 is broadcast to lock up the money and assign it to Tx 2. In other words, all parties assign their money to a pool that is controlled by the unanimous agreement of the group, but first the group has already signed agreement for the default action to take with the money, or partially signed multiple available options that a party can complete by adding the last signature.
By mutual agreement, the parties can always write another version of Tx 2 that releases the money immediately.
[Quoted text hidden]
Holding coins in an unspendable state for a rolling time window — reply 3
From: Mike Hearn Date: Wed, Apr 20,
2011 at 1:55 PM To: Satoshi Nakamoto satoshin@gmx.comThread: Holding
coins in an unspendable state for a rolling time window
Thanks, that's helpful. I'm understanding contracts better now.
So the issue with having an OP_TIME/OP_BLOCKNUMBER opcode is not only that the results can change after a re-org (you said that previously), but also that people could use it to produce transactions that cease to be valid entirely after a certain time and cause a fork. Kind of obvious in hindsight.
Since Google is trusted, couldn't users pay a token deposit to Google and Google pays them back when they close the account?
Google and trust is a complicated issue. Lots of people use our services despite having little trust in us. Some people start out trusting us but then read (often sensationalist or wrong) stories in the media that change their minds, and so on. This is one of the problems we have with phone verification ... a few people don't want to give us their phone number.
For this case it'd probably be OK because trust around data privacy is different to trust around obeying contracts. I'm sure nobody would doubt that Google will pay them back - I bet we'd have an even better credit rating than the US Government in that sense :-) But we have quite a high rate of false positives with our verifications and some people would suspect we were accidentally verifying users in order to accumulate big piles of coins with which to earn interest. I've seen much sillier conspiracy theories gain traction.
Besides, avoiding the need to trust big, complex institutions is much more BitCoin-ish. And I correctly suspected there was a way to do it I didn't understand yet so it's a good chance to learn more about BitCoin.
To answer your question though, yes it can be done without using trust
If I wrote a wiki page on how to build contracts with BitCoin, would you mind reviewing it?
I'm thinking it might be a good idea to re-enable transaction replacement soon because as the network grows, it will become harder and harder to upgrade. In one sense this is good as it makes it hard to change the fundamental rules of the system. On the other hand, we risk having a protocol which has many unused features because they aren't widely supported enough. HTTP suffered this fate with many of its verbs as well as features like pipelining.
Did you have any list of tasks for re-activation, some kind of audit or finishing off some code?
I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight? One reason I'm peppering you with questions is I worry that much of BitCoins potential lies in careful use of currently inactive features, but there's little guidance on how to do it. And frankly, I don't think I'm smart enough to figure it all out on my own. Maybe theymos is, he seems to understand it well. But if one day you leave entirely, parts of the protocol might fall into disuse, which would be a shame.
Another is the economics of mining after the transition to a fully fee based system. Right now difficulty is roughly a function of the USD/BTC exchange rate and per-block inflation. When mining reward is set by the market, it might be possible for a "Tragedy of the commons" to occur in which everyone benefits from a high difficulty, but nobody specifically wants to pay fees to get it. Besides, valuing difficulty is quite hard as you never know what the capabilities of attackers are until it's too late. Would it be possible for fees to trend towards zero over time as some miner is always willing to accept cheaper transactions and as miners drop out, the difficulty adjusts so the delays never get too bad to tolerate?
As always thanks for your insights.
Holding coins in an unspendable state for a rolling time window — reply 4
Mike Hearn correspondence (Satoshi Nakamoto) — April 23, 2011 — source: hearn-thread5.html#msg-4
From: Satoshi Nakamoto Date: Sat,
Apr 23, 2011 at 3:40 PM To: Mike Hearn mike@plan99.netThread: Holding coins
in an unspendable state for a rolling time window
I had a few other things on my mind (as always). One is, are you planning on rejoining the community at some point (eg for code reviews), or is your plan to permanently step back from the limelight?
I've moved on to other things. It's in good hands with Gavin and everyone.
I do hope your BitcoinJ continues to be developed into an alternative client. It gives Java devs something to work on, and it's easier with a simpler foundation that doesn't have to do everything. It'll get critical mass when impatient new users can get started using it while the other one is still downloading the block chain.
From: Gavin Andresen Date: Tue, Apr
26, 2011 at 4:29 AM To: Satoshi Nakamoto
On Tue, Apr 26, 2011 at 4:29 AM, Satoshi Nakamoto satoshin@gmx.com wrote:
I wish you wouldn’t keep talking about me as a mysterious shadowy figure,
the press just turns that into a pirate currency angle. Maybe instead make
it about the open source project and give more credit to your dev
contributors; it helps motivate them.
You must’ve read the Forbes article… yeah, I’m not happy with the
‘wacky pirate money’ tone, either.
More credit for the rest of the contributors is a very good idea.
RE: forwarding the key/code: fricking fracking… now I’ve gotta
figure out a couple of people who I can trust to keep them safe…
On a completely different subject: I did something that I hope turns
out to be smart, but might be stupid.
I was contacted by http://www.iqt.org/ – they’re a US-govt-funded
‘strategic investment’ company, and part of what they do is holding an
annual conference on emerging technologies for US intelligence
agencies. This year the theme is “Mobility of Money”.
They asked if I’d be willing to talk about Bitcoin, and I committed to
giving a 50-minute presentation and participating in a panel
discussion.
I hope that by talking directly to “them” and, more importantly,
listening to their questions/concerns, they will think of Bitcoin the
way I do– as a just-plain-better, more efficient,
less-subject-to-political-whims money. Not as an all-powerful
black-market tool that will be used by anarchists to overthrow The
System.
It might be really stupid if it just raises Bitcoin’s visibility on
their radar, but I think it is way too late for that; Bitcoin is
already on their radar.
I plan on posting about this on the forums soon, because “Gavin
secretly visits the CIA” would spin all sorts of conspiracy theories.
“Gavin openly visits the CIA” will create enough conspiracy theories
as it is.
I wish you wouldn’t keep talking about me as a mysterious shadowy
figure, the press just turns that into a pirate currency angle. Maybe
instead make it about the open source project and give more credit to
your dev contributors; it helps motivate them.
I’ve moved on to other things and will probably be unavailable. Here’s
the CAlert key and broadcast code in case you need it. You should
probably give it to at least one or two other people. There are a few
long time users who are always around all the time.
A big attraction to new users is that anyone with a computer can generate some free coins. When there are 5000 users, that incentive may fade, but for now it’s still true.
GPUs would prematurely limit the incentive to only those with high end GPU hardware. It’s inevitable that GPU compute clusters will eventually hog all the generated coins, but I don’t want to hasten that day. If the difficulty gets really high, that increases the value of each coin in a way since the supply becomes more limited. The supply is the same: 50 coins every 10 minutes.
But GPUs are much less evenly distributed, so the generated coins only go towards rewarding 20% of the people for joining the network instead of 100%.
I don’t mean to sound like a socialist, I don’t care if wealth is concentrated, but for now, we get more growth by giving that money to 100% of the people than giving it to 20%. Also, the longer we can delay the GPU arms race, the more mature the OpenCL libraries get, and the more people will have OpenCL compatible video cards. If we see from the difficulty factor that someone is using too much GPU, we can certainly pick this OpenCL stuff up again then. Maybe my effort to maintain GPU innocence is running out of time. It’s worked out so far.
Satoshi
Re: Citation of your b-money page
Wei Dai correspondence — date unknown — source: 2.md
Thanks for letting me know about your paper. I’ll take a look at it
and let you know if I have any comments or questions.
Source file: nakamoto-dai-emails.txt
Re: Bitcoin source files attached
Hal Finney correspondence — date unknown — source: 2.md
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.
⚠️ Pre-publication draft — sent privately to Adam
Back on 3 October 2008, 28 days before the final paper was announced
publicly on 31 October 2008. Released as COPA trial exhibit AB1 in
February 2024.
This is the earliest known version of the Bitcoin whitepaper. Satoshi
sent it to Adam Back (inventor of Hashcash, whose work is cited in the
paper) seeking feedback before making the public announcement. The draft
is largely identical to the final paper but contains minor textual
differences. It was held privately for 16 years until it emerged as a
court exhibit during the COPA v. Craig Wright trial.
Bitcoin: A Peer-to-Peer Electronic Cash System
Whitepaper — October 31, 2008 — source: bitcoin.pdf
A purely peer-to-peer version of electronic cash would allow online
payments to be sent directly from one party to another without going
through a financial institution. Digital signatures provide part of the
solution, but the main benefits are lost if a trusted third party is
still required to prevent double-spending. We propose a solution to the
double-spending problem using a peer-to-peer network. The network
timestamps transactions by hashing them into an ongoing chain of
hash-based proof-of-work, forming a record that cannot be changed
without redoing the proof-of-work. The longest chain not only serves as
proof of the sequence of events witnessed, but proof that it came from
the largest pool of CPU power. As long as a majority of CPU power is
controlled by nodes that are not cooperating to attack the network,
they’ll generate the longest chain and outpace attackers. The network
itself requires minimal structure. Messages are broadcast on a best
effort basis, and nodes can leave and rejoin the network at will,
accepting the longest proof-of-work chain as proof of what happened
while they were gone.
Commerce on the Internet has come to rely almost exclusively on
financial institutions serving as trusted third parties to process
electronic payments. While the system works well enough for most
transactions, it still suffers from the inherent weaknesses of the trust
based model. Completely non-reversible transactions are not really
possible, since financial institutions cannot avoid mediating disputes.
The cost of mediation increases transaction costs, limiting the minimum
practical transaction size and cutting off the possibility for small
casual transactions, and there is a broader cost in the loss of ability
to make non-reversible payments for non-reversible services. With the
possibility of reversal, the need for trust spreads. Merchants must be
wary of their customers, hassling them for more information than they
would otherwise need. A certain percentage of fraud is accepted as
unavoidable. These costs and payment uncertainties can be avoided in
person by using physical currency, but no mechanism exists to make
payments over a communications channel without a trusted party.
What is needed is an electronic payment system based on cryptographic
proof instead of trust, allowing any two willing parties to transact
directly with each other without the need for a trusted third party.
Transactions that are computationally impractical to reverse would
protect sellers from fraud, and routine escrow mechanisms could easily
be implemented to protect buyers. In this paper, we propose a solution
to the double-spending problem using a peer-to-peer distributed
timestamp server to generate computational proof of the chronological
order of transactions. The system is secure as long as honest nodes
collectively control more CPU power than any cooperating group of
attacker nodes.
We define an electronic coin as a chain of digital signatures. Each
owner transfers the coin to the next by digitally signing a hash of the
previous transaction and the public key of the next owner and adding
these to the end of the coin. A payee can verify the signatures to
verify the chain of ownership.
The problem of course is the payee can’t verify that one of the
owners did not double-spend the coin. A common solution is to introduce
a trusted central authority, or mint, that checks every transaction for
double spending. After each transaction, the coin must be returned to
the mint to issue a new coin, and only coins issued directly from the
mint are trusted not to be double-spent. The problem with this solution
is that the fate of the entire money system depends on the company
running the mint, with every transaction having to go through them, just
like a bank.
We need a way for the payee to know that the previous owners did not
sign any earlier transactions. For our purposes, the earliest
transaction is the one that counts, so we don’t care about later
attempts to double-spend. The only way to confirm the absence of a
transaction is to be aware of all transactions. In the mint based model,
the mint was aware of all transactions and decided which arrived first.
To accomplish this without a trusted party, transactions must be
publicly announced[1], and we
need a system for participants to agree on a single history of the order
in which they were received. The payee needs proof that at the time of
each transaction, the majority of nodes agreed it was the first
received.
The solution we propose begins with a timestamp server. A timestamp
server works by taking a hash of a block of items to be timestamped and
widely publishing the hash, such as in a newspaper or Usenet
post[2-5]. The timestamp
proves that the data must have existed at the time, obviously, in order
to get into the hash. Each timestamp includes the previous timestamp in
its hash, forming a chain, with each additional timestamp reinforcing
the ones before it.
To implement a distributed timestamp server on a peer-to-peer basis,
we will need to use a proof-of-work system similar to Adam Back’s
Hashcash[6], rather than
newspaper or Usenet posts. The proof-of-work involves scanning for a
value that when hashed, such as with SHA-256, the hash begins with a
number of zero bits. The average work required is exponential in the
number of zero bits required and can be verified by executing a single
hash.
For our timestamp network, we implement the proof-of-work by
incrementing a nonce in the block until a value is found that gives the
block’s hash the required zero bits. Once the CPU effort has been
expended to make it satisfy the proof-of-work, the block cannot be
changed without redoing the work. As later blocks are chained after it,
the work to change the block would include redoing all the blocks after
it.
The proof-of-work also solves the problem of determining
representation in majority decision making. If the majority were based
on one-IP-address-one-vote, it could be subverted by anyone able to
allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The
majority decision is represented by the longest chain, which has the
greatest proof-of-work effort invested in it. If a majority of CPU power
is controlled by honest nodes, the honest chain will grow the fastest
and outpace any competing chains. To modify a past block, an attacker
would have to redo the proof-of-work of the block and all blocks after
it and then catch up with and surpass the work of the honest nodes. We
will show later that the probability of a slower attacker catching up
diminishes exponentially as subsequent blocks are added.
To compensate for increasing hardware speed and varying interest in
running nodes over time, the proof-of-work difficulty is determined by a
moving average targeting an average number of blocks per hour. If
they’re generated too fast, the difficulty increases.
Each node works on finding a difficult proof-of-work for its
block.
When a node finds a proof-of-work, it broadcasts the block to all
nodes.
Nodes accept the block only if all transactions in it are valid and
not already spent.
Nodes express their acceptance of the block by working on creating
the next block in the chain, using the hash of the accepted block as the
previous hash.
Nodes always consider the longest chain to be the correct one and
will keep working on extending it. If two nodes broadcast different
versions of the next block simultaneously, some nodes may receive one or
the other first. In that case, they work on the first one they received,
but save the other branch in case it becomes longer. The tie will be
broken when the next proof-of-work is found and one branch becomes
longer; the nodes that were working on the other branch will then switch
to the longer one.
New transaction broadcasts do not necessarily need to reach all
nodes. As long as they reach many nodes, they will get into a block
before long. Block broadcasts are also tolerant of dropped messages. If
a node does not receive a block, it will request it when it receives the
next block and realizes it missed one.
By convention, the first transaction in a block is a special
transaction that starts a new coin owned by the creator of the block.
This adds an incentive for nodes to support the network, and provides a
way to initially distribute coins into circulation, since there is no
central authority to issue them. The steady addition of a constant of
amount of new coins is analogous to gold miners expending resources to
add gold to circulation. In our case, it is CPU time and electricity
that is expended.
The incentive can also be funded with transaction fees. If the output
value of a transaction is less than its input value, the difference is a
transaction fee that is added to the incentive value of the block
containing the transaction. Once a predetermined number of coins have
entered circulation, the incentive can transition entirely to
transaction fees and be completely inflation free.
The incentive may help encourage nodes to stay honest. If a greedy
attacker is able to assemble more CPU power than all the honest nodes,
he would have to choose between using it to defraud people by stealing
back his payments, or using it to generate new coins. He ought to find
it more profitable to play by the rules, such rules that favour him with
more new coins than everyone else combined, than to undermine the system
and the validity of his own wealth.
Once the latest transaction in a coin is buried under enough blocks,
the spent transactions before it can be discarded to save disk space. To
facilitate this without breaking the block’s hash, transactions are
hashed in a Merkle Tree
[7][2][5],
with only the root included in the block’s hash. Old blocks can then be
compacted by stubbing off branches of the tree. The interior hashes do
not need to be stored.
A block header with no transactions would be about 80 bytes. If we
suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 =
4.2MB per year. With computer systems typically selling with 2GB of RAM
as of 2008, and Moore’s Law predicting current growth of 1.2GB per year,
storage should not be a problem even if the block headers must be kept
in memory.
It is possible to verify payments without running a full network
node. A user only needs to keep a copy of the block headers of the
longest proof-of-work chain, which he can get by querying network nodes
until he’s convinced he has the longest chain, and obtain the Merkle
branch linking the transaction to the block it’s timestamped in. He
can’t check the transaction for himself, but by linking it to a place in
the chain, he can see that a network node has accepted it, and blocks
added after it further confirm the network has accepted it.
As such, the verification is reliable as long as honest nodes control
the network, but is more vulnerable if the network is overpowered by an
attacker. While network nodes can verify transactions for themselves,
the simplified method can be fooled by an attacker’s fabricated
transactions for as long as the attacker can continue to overpower the
network. One strategy to protect against this would be to accept alerts
from network nodes when they detect an invalid block, prompting the
user’s software to download the full block and alerted transactions to
confirm the inconsistency. Businesses that receive frequent payments
will probably still want to run their own nodes for more independent
security and quicker verification.
Although it would be possible to handle coins individually, it would
be unwieldy to make a separate transaction for every cent in a transfer.
To allow value to be split and combined, transactions contain multiple
inputs and outputs. Normally there will be either a single input from a
larger previous transaction or multiple inputs combining smaller
amounts, and at most two outputs: one for the payment, and one returning
the change, if any, back to the sender.
It should be noted that fan-out, where a transaction depends on
several transactions, and those transactions depend on many more, is not
a problem here. There is never the need to extract a complete standalone
copy of a transaction’s history.
The traditional banking model achieves a level of privacy by limiting
access to information to the parties involved and the trusted third
party. The necessity to announce all transactions publicly precludes
this method, but privacy can still be maintained by breaking the flow of
information in another place: by keeping public keys anonymous. The
public can see that someone is sending an amount to someone else, but
without information linking the transaction to anyone. This is similar
to the level of information released by stock exchanges, where the time
and size of individual trades, the “tape”, is made public, but without
telling who the parties were.
As an additional firewall, a new key pair should be used for each
transaction to keep them from being linked to a common owner. Some
linking is still unavoidable with multi-input transactions, which
necessarily reveal that their inputs were owned by the same owner. The
risk is that if the owner of a key is revealed, linking could reveal
other transactions that belonged to the same owner.
We consider the scenario of an attacker trying to generate an
alternate chain faster than the honest chain. Even if this is
accomplished, it does not throw the system open to arbitrary changes,
such as creating value out of thin air or taking money that never
belonged to the attacker. Nodes are not going to accept an invalid
transaction as payment, and honest nodes will never accept a block
containing them. An attacker can only try to change one of his own
transactions to take back money he recently spent.
The race between the honest chain and an attacker chain can be
characterized as a Binomial Random Walk. The success event is the honest
chain being extended by one block, increasing its lead by +1, and the
failure event is the attacker’s chain being extended by one block,
reducing the gap by -1.
The probability of an attacker catching up from a given deficit is
analogous to a Gambler’s Ruin problem. Suppose a gambler with unlimited
credit starts at a deficit and plays potentially an infinite number of
trials to try to reach breakeven. We can calculate the probability he
ever reaches breakeven, or that an attacker ever catches up with the
honest chain, as follows:[8]
\[
\begin{aligned}
p &= \text{probability an honest node finds the next block} \\
q &= \text{probability the attacker finds the next block} \\
q_z &= \text{probability the attacker will ever catch up from $z$
blocks behind}
\end{aligned}
\]
\[
\large q_z = \begin{Bmatrix}
1 & \text{if}\; p \leq q\newline
(q/p)^z & \text{if}\; p > q
\end{Bmatrix}
\]
Given our assumption that \(p \gt
q\), the probability drops exponentially as the number of blocks
the attacker has to catch up with increases. With the odds against him,
if he doesn’t make a lucky lunge forward early on, his chances become
vanishingly small as he falls further behind.
We now consider how long the recipient of a new transaction needs to
wait before being sufficiently certain the sender can’t change the
transaction. We assume the sender is an attacker who wants to make the
recipient believe he paid him for a while, then switch it to pay back to
himself after some time has passed. The receiver will be alerted when
that happens, but the sender hopes it will be too late.
The receiver generates a new key pair and gives the public key to the
sender shortly before signing. This prevents the sender from preparing a
chain of blocks ahead of time by working on it continuously until he is
lucky enough to get far enough ahead, then executing the transaction at
that moment. Once the transaction is sent, the dishonest sender starts
working in secret on a parallel chain containing an alternate version of
his transaction.
The recipient waits until the transaction has been added to a block
and \(z\) blocks have been linked after
it. He doesn’t know the exact amount of progress the attacker has made,
but assuming the honest blocks took the average expected time per block,
the attacker’s potential progress will be a Poisson distribution with
expected value:
\[
\lambda = z \frac{q}{p}
\]
To get the probability the attacker could still catch up now, we
multiply the Poisson density for each amount of progress he could have
made by the probability he could catch up from that point:
\[
\sum_{k=0}^{\infty} \frac{\lambda^k e^{-\lambda}}{k!} \cdot
\begin{Bmatrix}
(q/p)^{(z-k)} & \text{if}\; k\leq z\newline
1 & \text{if}\; k > z
\end{Bmatrix}
\]
Rearranging to avoid summing the infinite tail of the
distribution…
We have proposed a system for electronic transactions without relying
on trust. We started with the usual framework of coins made from digital
signatures, which provides strong control of ownership, but is
incomplete without a way to prevent double-spending. To solve this, we
proposed a peer-to-peer network using proof-of-work to record a public
history of transactions that quickly becomes computationally impractical
for an attacker to change if honest nodes control a majority of CPU
power. The network is robust in its unstructured simplicity. Nodes work
all at once with little coordination. They do not need to be identified,
since messages are not routed to any particular place and only need to
be delivered on a best effort basis. Nodes can leave and rejoin the
network at will, accepting the proof-of-work chain as proof of what
happened while they were gone. They vote with their CPU power,
expressing their acceptance of valid blocks by working on extending them
and rejecting invalid blocks by refusing to work on them. Any needed
rules and incentives can be enforced with this consensus mechanism.
S. Haber, W.S. Stornetta,
“Secure names for
bit-strings,” In Proceedings of the 4th ACM Conference on
Computer and Communications Security, pages 28-35, April
1997. ↩︎↩︎
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:
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 http://www.bitcoin.org/bitcoin.pdf
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.
Could be. They’re talking about the old Chaumian central mint stuff,
but maybe only because that was the only thing available. Maybe they
would be interested in going in a new direction.
A lot of people automatically dismiss e-currency as a lost cause
because of all the companies that failed since the 1990’s. I hope it’s
obvious it was only the centrally controlled nature of those systems
that doomed them. I think this is the first time we’re trying a
decentralized, non-trust-based system.
Bitcoin open source implementation of P2P currency
P2P Foundation forum — February 18, 2009 — source: sni-forum-posts.json#post-7
It is a global distributed database, with additions to the database
by consent of the majority, based on a set of rules they follow:
Whenever someone finds proof-of-work to generate a block, they
get some new coins
The proof-of-work difficulty is adjusted every two weeks to
target an average of 6 blocks per hour (for the whole network)
The coins given per block is cut in half every 4 years
You could say coins are issued by the majority. They are issued in a
limited, predetermined amount.
As an example, if there are 1000 nodes, and 6 get coins each hour, it
would likely take a week before you get anything.
To Sepp’s question, indeed there is nobody to act as central bank or
federal reserve to adjust the money supply as the population of users
grows. That would have required a trusted party to determine the value,
because I don’t know a way for software to know the real world value of
things. If there was some clever way, or if we wanted to trust someone
to actively manage the money supply to peg it to something, the rules
could have been programmed for that.
In this sense, it’s more typical of a precious metal. Instead of the
supply changing to keep the value the same, the supply is predetermined
and the value changes. As the number of users grows, the value per coin
increases. It has the potential for a positive feedback loop; as users
increase, the value goes up, which could attract more users to take
advantage of the increasing value.
[DISPUTED] Bitcoin open source implementation of P2P currency disputed
P2P Foundation forum (disputed) — March 07, 2014 — source: sni-forum-posts.json#post-14
⚠ DISPUTED AUTHENTICITY. This post was made from
Satoshi’s P2P Foundation account on March 7, 2014 — nearly three years
after Satoshi’s last verified communication (the April 23, 2011 email to
Mike Hearn). The account had been dormant for years and many researchers
believe it was compromised by this point. Authorship by the real Satoshi
Nakamoto is not verified and is widely doubted.
I am not Dorian Nakamoto.
Welcome to the new Bitcoin forum!
Bitcoin Forum post — November 22, 2009 — source: 0005-00028.md
Post by: satoshi on November 22, 2009, 06:04:28 PM
Bitcoin Forum post — November 22, 2009 — source: 0006-00029.md
Post by: satoshi on November 22, 2009, 06:31:44 PM
--------------------
bitcoinbitcoin:
Bitcoin Maturation
Posted:Thu 01 of Oct, 2009 (14:12 UTC)
From the user’s perspective the bitcoin maturation process can be
broken down into 8 stages.
1. The initial network transaction that occurs when you first click
Generate Coins.
2. The time between that initial network transaction and when the
bitcoin entry is ready to appear in the All Transactions list.
3. The change of the bitcoin entry from outside the All Transaction
field to inside it.
4. The time between when the bitcoin appears in the All Transfers
list and when the Description is ready to change to Generated (50.00
matures in x more blocks).
5. The change of the Description to Generated (50.00 matures in x
more blocks).
6. The time between when the Description says Generated (50.00
matures in x more blocks) to when it is ready to change to
Generated.
7 The change of the Description to Generated.
8. The time after the Description has changed to Generated.
Which stages require network connectivity, significant local CPU
usage and or significant remote CPU usage? Do any of these stages have
names?
--------------------
sirius-m:
Re: Bitcoin Maturation
Posted:Thu 22 of Oct, 2009 (02:36 UTC)
As far as I know, there’s no network transaction when you click
Generate Coins - your computer just starts calculating the next
proof-of-work. The CPU usage is 100% when you’re generating coins.
In this example, the network connection is used when you broadcast
the information about the proof-of-work block you’ve created (that which
entitles you to the new coin). Generating coins successfully requires
constant connectivity, so that you can start working on the next block
when someone gets the current block before you.
Bitcoin Forum post — November 22, 2009 — source: 0006-00031.md
Post by: satoshi on November 22, 2009, 06:34:21 PM
It’s important to have network connectivity while you’re trying to
generate a coin (block) and at the moment it is successfully
generated.
During generation (when the status bar says “Generating” and
you’re using CPU to find a proof-of-work), you must constantly keep in
contact with the network to receive the latest block. If your block does
not link to the latest block, it may not be accepted.
When you successfully generate a block, it is immediately
broadcast to the network. Other nodes must receive it and link to it for
it to be accepted as the new latest block.
Think of it as a cooperative effort to make a chain. When you add a
link, you must first find the current end of the chain. If you were to
locate the last link, then go off for an hour and forge your link, come
back and link it to the link that was the end an hour ago, others may
have added several links since then and they’re not going to want to use
your link that now branches off the middle.
After a block is created, the maturation time of 120 blocks is to
make absolutely sure the block is part of the main chain before it can
be spent. Your node isn’t doing anything with the block during that
time, just waiting for other blocks to be added after yours. You don’t
have to be online during that time.
Bitcoin Forum post — November 22, 2009 — source: 0007-00032.md
Post by: satoshi on November 22, 2009, 06:35:15 PM
There will be a proxy setting in version 0.2 so you can connect
through TOR. I’ve done a careful scrub to make sure it doesn’t use DNS
or do anything that would leak your IP while in proxy mode.
Bitcoin Forum post — November 25, 2009 — source: 0008-00033.md
Post by: satoshi on November 25, 2009, 06:15:57 PM
--------------------
bitcoinbitcoin:
How anonymous are bitcoins?
Can nodes on the network tell from which and or to which bitcoin
address coins are being sent? Do blocks contain a history of where
bitcoins have been transfered to and from? Can nodes tell which bitcoin
addresses belong to which IP addresses? Is there a command line option
to enable the sock proxy the first time that bitcoin starts? What
happens if you send bitcoins to an IP address that has multiple clients
connected through network address translation (NAT)?
Bitcoin Forum post — November 25, 2009 — source: 0008-00034.md
Post by: satoshi on November 25, 2009, 06:17:23 PM
> Can nodes on the network tell from which and or to which
bitcoin
> address coins are being sent? Do blocks contain a history of
where
> bitcoins have been transfered to and from?
Bitcoins are sent to and from bitcoin addresses, which are
essentially random numbers with no identifying information.
When you send to an IP address, the transaction is still written to a
bitcoin address. The IP address is only used to connect to the
recipient’s computer to request a fresh bitcoin address, give the
transaction directly to the recipient and get a confirmation.
Blocks contain a history of the bitcoin addresses that a coin has
been transferred to. If the identities of the people using the bitcoin
addresses are not known and each address is used only once, then this
information only reveals that some unknown person transferred some
amount to someone else.
The possibility to be anonymous or pseudonymous relies on you not
revealing any identifying information about yourself in connection with
the bitcoin addresses you use. If you post your bitcoin address on the
web, then you’re associating that address and any transactions with it
with the name you posted under. If you posted under a handle that you
haven’t associated with your real identity, then you’re still
pseudonymous.
For greater privacy, it’s best to use bitcoin addresses only once.
You can change addresses as often as you want using Options->Change
Your Address. Transfers by IP address automatically use a new bitcoin
address each time.
> Can nodes tell which bitcoin addresses belong to which IP
addresses?
No.
> Is there a command line option to enable the sock proxy the
first
> time that bitcoin starts?
In the next release (version 0.2), the command line to run it through
a proxy from the first time is: bitcoin -proxy=127.0.0.1:9050
The problem for TOR is that the IRC server which Bitcoin uses to
initially discover other nodes bans the TOR exit nodes, as all IRC
servers do. If you’ve already connected once before then you’re already
seeded, but for the first time, you’d need to provide the address of a
node as such: bitcoin -proxy=127.0.0.1:9050 -addnode=
If someone running a node with a static IP address that can accept
incoming connections could post their IP to use for -addnode, that would
be great.
> What happens if you send bitcoins to an IP address that has
multiple
> clients connected through network address translation (NAT)?
Whichever one you’ve set your NAT to forward port 8333 to will
receive it. If your router can change the port number when it forwards,
you could allow more than one client to receive. For instance, if port
8334 forwards to a computer’s port 8333, then senders could send to
“x.x.x.x:8334”
If your NAT can’t translate port numbers, there currently isn’t a
command line option to change the incoming port that bitcoin binds to,
but I’ll look into it.
Bitcoin Forum post — November 27, 2009 — source: 0009-00037.md
Post by: satoshi on November 27, 2009, 05:27:09 PM
The Linux version is on its way. Martti’s Linux port was merged into
the main code branch and New Liberty Standard has been testing it. It’ll
be in the next release, version 0.2.
[OLD THREAD] Bitcoin version 0.2 development status
Bitcoin Forum post — November 27, 2009 — source: 0010-00038.md
Post by: satoshi on November 27, 2009, 10:48:39 PM
Last edit: October 09, 2011, 07:33:02 PM by theymos
We’ve been working hard on improvements for the next version release.
Martti (sirius-m) added some nice features to make it more user friendly
and easier to run in the background:
- Minimize to system tray option
- Autostart on boot option so you can keep it running in the
background automatically
- New options dialog layout
- Setup EXE for Windows, in addition to the archive download
I’ve been working on a number of refinements to the networking code
and laying the groundwork for future functionality. Also coming in
version 0.2:
Bitcoin Forum post — December 09, 2009 — source: 0012-00041.md
Post by: satoshi on December 09, 2009, 06:45:10 PM
Last edit: December 09, 2009, 06:58:28 PM by satoshi
Helpful suggestions, thanks.
Quote from: madhatter on December 09, 2009, 05:34:46 AM
- When the bitcoin software establishes a connection with a peer
(client TCP socket) have the client send the handshake string. Right now
you have the server (server TCP socket) send the handshake. My reasons
for this are anonymity of course. It is far too easy for ISPs to
portscan clients and detect they are running this program.<
That’s a good idea. The side accepting the connection just needs to
withhold from sending anything until it receives a valid handshake. Any
portscan would only get a dead connection that doesn’t volunteer to
identify itself.
Quote
- Use some sort of encryption during the handshake (sort of goes with
the statement/request above) to obfuscate what the software is during
DPI (deep packet inspection). I am really thinking about people in
non-free (as in freedom) countries such as China/Iran.
I have thought about eventually SSLing all the connections. I assume
anything short of SSL would be pointless against DPI. Maybe a better
more immediate solution is to connect through TOR, which will be
possible with 0.2.
Quote
- Some sort of an API is needed so that this system can be integrated
with websites to provide instant-on services. A simple https receipt
mechanism would do wonders. Have the client post each incoming payment
to an https url with all of the relevant information and provide status
updates. Also an outbound payment mechanism would be nice. So one could
automate payments (and batch payments) outbound. Status could be
returned via the https receipt interface.<
That’s one of the main things on the agenda after 0.2.
Quote
- Static port/Random port. Have a setting to randomly assign the port
that it runs on. (also be able to set it statically for very restrictive
firewalls).
Yeah, the other stealth stuff would be kinda pointless if it’s always
the same port number.
Quote
- UPnP support. Have the client automatically create the port forward
on upstream routers. Enabled by default. Can be turned off in the
options menu.
I’m looking forward to trying UPnP. Do most P2P clients typically
have UPnP enabled by default?
Quote
- Ability to compile a headless (console only) install for *NIX
systems. Also have the ability to just run as a network service. Perhaps
with a telnet-able port for control (or even a unix socket would be
ok).
I’m still thinking about how best to structure the management
interface. Maybe command line commands to communicate with the
background daemon to query transactions received and initiate sending
transfers. That would be more automation friendly. Or what about an http
interface on some port other than 80 to manage it with a browser?
Bitcoin Forum post — December 10, 2009 — source: 0012-00045.md
Post by: satoshi on December 10, 2009, 07:31:49 PM
Quote from: madhatter2 on December 10, 2009, 02:00:17 PM
Front ends can also be ran on clients with very low cpu power such as
mobile phones.
That’s a good approach for mobile. Programmatic API used by PHP (any
language) to present a web UI covers remote admin, mobile and any other
client that can’t be online all the time with a static IP. It would be
like webmail. It would be easier for new users to get started if they
only need to create an account on a website, not install software.
Quote
The app could be pre-seeded before downloading. Pre-seeding would
also cure the TOR+IRC problem. I know that people will want to run this
system over I2P+TOR.
Yeah, we can phase out IRC when there are enough static nodes to
preprogram a seed list. Once you get seeded, you don’t need IRC.
Quote
Also you could pre-seed the blocks so they won’t have to be
downloaded upon initial run. (Downloading 28,000 blocks on a slower ADSL
takes forever I couldn’t imagine how long it would take when there are
millions of blocks – a lifetime).
There were some issues in 0.1.5 where the initial block download
could get bogged down. 0.2 has code to make sure it goes smoothly. It
ought to take less than an hour, I think. I need to hurry up and get 0.2
out the door.
The blocks increase linearly, it’ll be decades before it’s millions.
In theory, the block download time should top out 8 months from now when
Moore’s Law will be growing faster than the block chain.
Quote
Can you give me CVS access or something? (If not, can I send you
patches?) I’d like to help out.
It’s SVN on sourceforge. PM or e-mail me your sourceforge account and
I’ll give you access.
Quote
I am mostly a Linux/BSD guy and I would like to lend my expertise in
those areas.
That’s great because that’s where I have less expertise. For
instance, I haven’t researched the best way to do the “Start Bitcoin on
system startup” feature on Linux. On Windows, the option adds/removes an
icon in the Startup folder.
Bitcoin Forum post — December 10, 2009 — source: 0013-00046.md
Post by: satoshi on December 10, 2009, 08:49:02 PM
Last edit: December 10, 2009, 09:33:22 PM by satoshi
1-3:
For that level of anonymity you need to connect through TOR, which
will be possible with version 0.2, which is only a few weeks away. I’ll
post TOR instructions at that time.
4:
Version 0.1.5: backup the whole %appdata%directory.
Version 0.2: you can backup just wallet.dat.
5:
Nope. The whole design is all about preventing that from working.
6:
Those coins can never be recovered, and the total circulation is
less. Since the effective circulation is reduced, all the remaining
coins are worth slightly more. It’s the opposite of when a government
prints money and the value of existing money goes down.
7:
It’s currently 29,296 blocks. The circulation is the number of blocks
times 50, so the current circulation is 1,464,800 bc.
If you only have 24k blocks, it must not have finished the initial
block download. Exit bitcoin and start it again. Version 0.2 is
better/faster at the initial block download.
8:
Typically a few hundred right now. It’s easy now but it’ll get harder
as the network grows.
9:
Good question, it’s TCP. The website needs to be updated to say TCP
port 8333.
The port forwarding is so other nodes can connect to you, so it helps
you stay connected because you are able to be connected with more nodes.
You also need it to receive payments by IP address.
10:
No, the other nodes won’t accept that.
Being open source means anyone can independently review the code. If
it was closed source, nobody could verify the security. I think it’s
essential for a program of this nature to be open source.
11:
Slower machines produce fewer coins. It’s proportional to CPU
speed.
12:
There are more coming.
13:
It uses a transactional database called Berkeley DB. It will not lose
data in a system crash. Transactions are written to the database
immediately when they’re received.
14:
For now, you can just multiply the total blocks by 50. The Bitcoin
network has been running for almost a year now. The design and coding
started in 2007.
Bitcoin Forum post — December 11, 2009 — source: 0013-00049.md
Post by: satoshi on December 11, 2009, 05:58:57 PM
That’s true, with the send-to-IP option, you are sending to whoever
answers that IP. Sending to a bitcoin address doesn’t have that
problem.
The plan is to implement an IP + bitcoin address option that would
have the benefits of both. It would still use a different address for
each transaction, but the receiver would sign the one-time-use address
with the given bitcoin address to prove it belongs to the intended
receiver.
Bitcoin Forum post — December 11, 2009 — source: 0012-00050.md
Post by: satoshi on December 11, 2009, 07:27:55 PM
Last edit: December 12, 2009, 03:33:02 PM by satoshi
Right, the SVN has the almost-release-candidate 0.2 source, which can
also be built and run on Linux. It hasn’t been tested on FreeBSD.
Quote from: madhatter2 on December 11, 2009, 04:59:19 AM
If we can get to the point where we have a working backend process
that will run on FreeBSD I can run always-on seeds.
That would be a big help. TOR users wouldn’t have to worry about how
to get seeded, and we wouldn’t depend on IRC.
It can be run in a few simple modes without access to the UI if you
don’t mind a minimized window on the desktop. (0.1.5 doesn’t have -min
so it would be an open window)
To only run a seed:
bitcoin -min -gen=0
You could sort of monitor it by looking at debug.log. To stop it,
kill the process, the database won’t mind.
To generate:
bitcoin -min -gen
To get the generated bitcoins, you’d have to copy wallet.dat (with
version 0.2) to a machine with a UI, swap in the wallet.dat, run bitcoin
and transfer the coins to your main account. (With version 0.1.5 you’d
have to copy the whole “%appdata%/Bitcoin” directory.) There is one
caveat about copying wallet.dat: if you happened to kill the program at
the exact moment that it generated a coin or received a payment,
wallet.dat might not work by itself and you’d have to copy the whole
directory.
Quote
I really think that having the download package contain a daily seed
snapshot will improve the bootstrapping. I have seen instances on new
test installs here where the application will sit with 0 connections / 1
block. Upon inspecting the debug.log I find that the IRC server
(freenode, I believe) claims I am already connected and refuses to let
me seed the application. (Just an example).
I see, that would happen with multiple nodes using the same NAT or
VPN or some ISP that funnels everyone through a few proxy servers. I
just committed a fix to SVN for this. If it gets “433” name already in
use (it was error 433, right?), it’ll retry with a non-address random
username.
Quote
In any event, I would like to help. I have a lot of time and a
project like this one is very exciting.
Bitcoin Forum post — December 12, 2009 — source: 0012-00054.md
Post by: satoshi on December 12, 2009, 05:52:44 PM
The average total coins generated across the network per day stays
the same. Faster machines just get a larger share than slower machines.
If everyone bought faster machines, they wouldn’t get more coins than
before.
We should have a gentleman’s agreement to postpone the GPU arms race
as long as we can for the good of the network. It’s much easer to get
new users up to speed if they don’t have to worry about GPU drivers and
compatibility. It’s nice how anyone with just a CPU can compete fairly
equally right now.
Bitcoin Forum post — December 12, 2009 — source: 0012-00055.md
Post by: satoshi on December 12, 2009, 06:17:10 PM
Quote from: madhatter2 on December 12, 2009, 06:34:21 AM
I almost have the svn 0.2 compiling on Mac OS X 10.4.11/Intel (I also
have a PPC970 machine here as well so a PPC build would be possible as
well). The windowing is native carbon too via wxwidgets! It is FAST! ;)
I had to create a new makefile (makefile.osx; based on makefile.unix of
course.. given any thought to using autoconf?) and put some ifdef’s into
header.h. I have patches. I will keep toying around. I might try it on
FreeBSD next.
Mac support would be nice. wxWidgets really pays off for cross
platform.
Please don’t try PPC. PPC is big-endian and Bitcoin is little-endian,
there would be endless endian bugs making it harder for me to debug the
network if there’s a potentially byte-swapping node out there. PPC is on
its way out anyway.
Considered autoconf. Autoconf is a necessity for large projects with
a quagmire makefile, but I think we’re small enough that it’s more
optimal without it. I’d rather keep the makefile simple as long as
possible.
Quote
I think that breaking bitcoin into two apps is ideal. A wxwidgets
front end (since it is mostly all there) and a backend that binds to a
control TCP socket. I have been reading over the source to see how hard
it would be to break it apart and I think it should be fairly simple. Of
course an API would have to be developed.
My head hurts just thinking about that. Funnelling all the UI backend
through a TCP connection would make everything twice as hard. There’s
too much bandwidth between the UI and the internal data structures in
order to keep the listview control updated, because of the way the
listview control works.
I’d rather have command line control, that would get us remote admin
and batch automation.
Bitcoin Forum post — December 13, 2009 — source: 0012-00062.md
Post by: satoshi on December 13, 2009, 04:51:25 PM
There would be a command line switch at runtime to tell it to run
without UI. All it needs to do is not create the main window. A
simplistic way would be to disable “pframeMain->Show” and
“ptaskbaricon->Show” in ui.cpp. The network threads don’t care that
the UI isn’t there. The only other UI is a message box in CheckDiskSpace
if it runs out of disk space.
Then a separate command line utility to communicate with it to do
things. Not sure what it should be named.
“natural deflation”… I like that name for it. Yes, there will be
natural deflation due to payment mistakes and lost data. Coin creation
will eventually get slow enough that it is exceeded by natural deflation
and we’ll have net deflation.
It looks like the implicit conversion from std::string to wxString
isn’t working. That’s used everywhere, the conversion needs to work.
wxString is complicated by supporting win32’s 16-bit wchar and 8-bit
ansi dual-compile. You can get that problem on Windows if the “unicode”
(meaning wchar) build is used, so that wxString is wchar and std::string
is char.
It’s probably some wxWidgets compile defines or build configuration.
What “configure” options did you use?
I’m not sure __WXMAC__ is the right define. It may be the Mac Classic
support that’s complicating wxString, and we only want OSX. Try
__WXOSX__ (or see below)
“There are two wxWidgets ports to Mac OS. One of them, wxMac, exists
in two versions: Classic and Carbon. The Classic version is the only one
to work on Mac OS version 8. The Carbon version may be built either as
CFM or Mach-O (binary format, like ELF) and the former may run under OS
9 while the latter only runs under OS X. Finally, there is a new Cocoa
port which can only be used under OS X. To summarize:
\* If you want to test for all Mac platforms, classic and OS X, you should test both \_\_WXMAC\_\_ and \_\_WXCOCOA\_\_.
\* If you want to test for any GUI Mac port under OS X, use \_\_WXOSX\_\_.
\* If you want to test for any port under Mac OS X, including, for example, wxGTK and also wxBase, use \_\_DARWIN\_\_"
Bitcoin Forum post — December 15, 2009 — source: 0012-00070.md
Post by: satoshi on December 15, 2009, 08:37:32 PM
Quote from: madhatter2 on December 15, 2009, 05:21:09 AM
It is also throwing the same std::string issue on the latest version
of Ubuntu Linux.
Then it must be something you’re doing differently with building or
configuring wxWidgets.
What options did you use on the wxWidgets “configure” script? The
options I used are in build-unix.txt.
Quote
One question: how do I enable the debug.log? I have tried stopping
bitcoin and touching ~/.bitcoin/debug.log and starting bitcoin again. It
never seems to write to the file. Am I missing something?
Never heard of that happening. Is there anything in debug.log? If you
touched the file, that sounds like something is there. Does the program
have write access to the file?
- Autostart on boot option so you can keep it running in the
background automatically
- New options dialog layout for future expansion
- Setup program for Windows
- Linux version (tested on Ubuntu)
Satoshi Nakamoto
- Multi-processor support for coin generation
- Proxy support for use with TOR
- Fixed some slowdowns in the initial block download
Major thanks to Martti Malmi (sirius-m) for all his coding work and
for hosting the new site and this forum, and New Liberty Standard for
his help with testing the Linux version.
Bitcoin Forum post — December 18, 2009 — source: 0012-00079.md
Post by: satoshi on December 18, 2009, 05:37:48 PM
What you can currently do is set “Minimize to the tray” in options,
then run it as “bitcoin -min” so it starts minimized. The only visible
part will be a small (20x20) icon on the tray, which can be
doubleclicked if you want to access the UI. Note: there’s a bug with
tray icons sometimes disappearing on 64-bit Karmic Koala, not sure if
it’s from 64-bit or Karmic, it was fine on 32-bit Jaunty.
We didn’t have time to implement the “Start Bitcoin on system
startup” feature on Linux in time for 0.2 so it’s greyed out. I figured
Linux people wouldn’t mind doing that manually anyway. I guess they need
to know about the -min switch to do it right.
You can locate the data directory where you want with the
“-datadir=” switch. I know someone is already doing that to
put it on a TrueCrypt USB drive.
Re: Is my second Transaction working correctly? +Transfer Question
Bitcoin Forum post — January 05, 2010 — source: 0017-00085.md
Post by: satoshi on January 05, 2010, 08:00:46 PM
Last edit: January 05, 2010, 08:54:11 PM by satoshi
The transfer is immediate if you send by IP address. If you send by
bitcoin address and the recipient isn’t online at the time, it might
take 30 minutes or more to see it.
Also, the recipient needs to be synced up with the block chain before
it’ll see the received transaction. That means the status bar at the
bottom needs to say at least 33000 blocks, like “x connections 33200
blocks x transactions”.
Quote from: sirius-m on January 05, 2010, 01:20:06 AM
Quote
However, once that transaction was complete, a new transaction hasn’t
started. Or maybe it has. There’s only one transaction in the list but
I’m up to 131 Blocks under “Status”. Is this the way it’s supposed to
happen? Does it keep processing on the same transaction and generating
coins every 120 blocks or so? Or is it supposed to start a new
transaction?
The number of blocks of a transaction is the amount of new blocks
that have been generated by the whole network after the transaction.
Each new block in the chain means new coins to its creator. One
“generated” -transaction in your transaction list means that you have
generated one block. You’re not the first one to find the concept of a
“block” a bit confusing on the first sight.
Would it be clearer if the status said “x confirmations”, like:
2/unconfirmed
3/unconfirmed
4/unconfirmed
5/unconfirmed
6 confirmations
7 confirmations
8 confirmations
Each block essentially means another node has confirmed that it
agrees with all transactions up to that point.
Bitcoin Forum post — January 14, 2010 — source: 0018-00097.md
Post by: satoshi on January 14, 2010, 08:17:20 PM
I haven’t tried compiling 64-bit yet. 64-bit wouldn’t make it any
faster, since it uses 64-bit numbers in only a few places and SHA-256 is
a 32-bit algorithm, but it may be convenient for those running a 64-bit
OS. If I get a chance I’ll try -m64 and see what the problem is.
You can run the 32-bit version on 64-bit Linux by installing
ia32-libs. (sudo apt-get install ia32-libs) If we made a Debian package,
it could automatically pull that in as a dependency.
Bitcoin Forum post — January 20, 2010 — source: 0021-00112.md
Post by: satoshi on January 20, 2010, 08:07:15 PM
Last edit: January 20, 2010, 09:23:55 PM by satoshi
Coins generate at the same speed with any number of connections >=
1.
More connections just add redundancy. If you only had one connection,
what if that node is slow or busy, or only connected to you? Having
several connections increases the certainty that you’re well connected
to the network. That hasn’t been a problem in practice, the network is
very thoroughly connected. If you have 2 or 3 connections, you’re
fine.
Bitcoin Forum post — January 20, 2010 — source: 0022-00113.md
Post by: satoshi on January 20, 2010, 10:05:28 PM
I’ve been thinking about that for a while. I want to add the backend
support for .onion addresses and connecting to them, then go from
there.
There aren’t many .onion addresses in use for anything because the
user has to go through a number of steps to create one. Configure TOR to
generate a .onion address, restart TOR, configure it with the generated
address. Perhaps this is intentional to keep TOR so it can’t be
integrated into file sharing programs in any sufficiently automated
way.
Bitcoin Forum post — January 27, 2010 — source: 0027-00156.md
Post by: satoshi on January 27, 2010, 09:52:27 PM
That is what happens if you copy wallet files around. If you copy
your wallet file to a second computer, then they both think the money in
the wallet is theirs. If one spends any of it, the other doesn’t know
those coins are already spent and would try to spend them again, and
that’s the error you would hit.
Now that it’s clear this is a key error message, it ought to be
something more like “the money appears to be already spent… this could
happen if you used a copy of your wallet file on another computer.”
You can move or backup your wallet file, but it needs to have only
one “lineage” and only used in one place at a time. Any time you
transfer money out of it, then you must no longer use any previous
copies.
This brings up a good point. In the case of restoring a backup that
may be from before you spent some coins, we need to add functionality to
resync it to discover which coins have already been spent. This would
not be hard to do, it just hasn’t been implemented yet. I’ll add it to
the list. This would make it mostly repair the situation instead of
giving that error message.
Re: A newb's test - anyone want to buy a picture for $1?
Bitcoin Forum post — January 28, 2010 — source: 0025-00159.md
Post by: satoshi on January 28, 2010, 01:01:48 AM
Yes, it’s a technical limitation. Sending by bitcoin address enters
the transaction into the network and the recipient discovers it from the
network. You don’t connect directly with them and they don’t have to be
online at the time.
I very much wanted to find some way to include a short message, but
the problem is, the whole world would be able to see the message. As
much as you may keep reminding people that the message is completely
non-private, it would be an accident waiting to happen.
Unfortunately, ECDSA can only sign signatures, it can’t encrypt
messages, and we need the small size of ECDSA. RSA can encrypt messages,
but it’s many times bigger than ECDSA.
Bitcoin Forum post — January 28, 2010 — source: 0027-00170.md
Post by: satoshi on January 28, 2010, 11:08:02 PM
The resync idea would go through your wallet and check it against the
block index to find any transactions that your current computer doesn’t
realize are already spent. That could happen if they were spent on
another computer with a copy of the wallet file, or you had to restore
the wallet to a backup from before they were spent. Currently, the
software just assumes it always knows whether its transactions are spent
because it marks them spent in wallet.dat when it spends them.
A wallet merge tool is possible to implement but much less in demand
once resync solves most of the problem. With resync, you could do about
the same thing by sending all the money from one wallet to the other.
The receiver would resync and discover all its overlapping coins were
spent, then receive them in the new transaction.
Bitcoin Forum post — January 28, 2010 — source: 0029-00172.md
Post by: satoshi on January 28, 2010, 11:26:09 PM
That’s the right way to do it as riX says. The software can generate
a new bitcoin address whenever you need one for each payment. “Please
send X bc to [single-use bitcoin address] to complete your order” When
the server receives that amount to the bitcoin address, that could
trigger it to automatically fulfil the order or e-mail the shop
owner.
Adding command line support is a high priority. It’s just a matter of
getting the time to code it.
Re: A newb's test - anyone want to buy a picture for $1?
Bitcoin Forum post — January 29, 2010 — source: 0025-00173.md
Post by: satoshi on January 29, 2010, 12:22:13 AM
The recommended ways to do a payment for an order:
The merchant has a static IP, the customer sends to it with a
comment.
The merchant creates a new bitcoin address, gives it to the
customer, the customer sends to that address. This will be the standard
way for website software to do it.
RSA vs ECDSA: it’s not the size of the executable but the size of the
data. I thought it would be impractical if the block chain, bitcoin
addresses, disk space and bandwidth requirements were all an order of
magnitude bigger. Also, even if using RSA for messages, it would still
make sense to do all the bitcoin network with ECDSA and use RSA in
parallel for only the message part. In that case, everything that’s been
implemented up to now would be implemented exactly as it has been.
We can figure out the best way to do this much later. It could use a
separate (maybe existing) e-mail or IM infrastructure to pass messages,
and instead of RSA, maybe just put a hash of the message in the
transaction to prove that the transaction is for the order described in
the message. The message would have to include a salt so nobody could
brute force the hash to reveal a short message.
Bitcoin Forum post — January 29, 2010 — source: 0018-00174.md
Post by: satoshi on January 29, 2010, 12:42:49 AM
I committed a fix for 64-bit compile and some fixes to support
wxWidgets 2.9.0.
There was one compile error in serialize.h with min(sizeof()) that I
fixed for 64-bit. The rest of the 64-bit compile errors I was getting
were in wxWidgets 2.8.9, so I started working on supporting wxWidgets
2.9.0.
wxWidgets 2.9.0 is UTF-8. We’ve been using the ANSI version of
wxWidgets 2.8.9 in anticipation of wxWidgets UTF-8 support.
I compiled and ran on 64-bit Ubuntu 9.10 Karmic.
I think the only bug left is where the status number is mashed up.
I’m not sure why, I have to suspect it’s a UTF-8 thing, but no idea how
that could happen. Haven’t looked into it.
build-unix.txt is updated and two makefiles on SVN:
makefile.unix.wx2.8
makefile.unix.wx2.9
Unfortunately there’s still no debian package for either version of
wxWidgets we use. They only have the wchar (“unicode”) version of
wxWidgets 2.8, which is a disaster because wchar wxString doesn’t
convert to std::string. We use either ANSI wxWidgets 2.8, or wxWidgets
2.9. So you still have to get it and build it yourself.
Bitcoin Forum post — February 03, 2010 — source: 0027-00219.md
Post by: satoshi on February 03, 2010, 11:29:57 PM
I uploaded this fix to the SVN. It watches for spent coins and
updates your wallet on load and also continuously as blocks come in. I
also put a better error message, but it should never hit it because it
always finds spent coins ahead of time, unless you spent the same money
at the same time on two computers at once.
If you want to try it, PM or e-mail me your e-mail address where I
can send it as an attachment and also what OS (win, linux 32-bit, linux
64-bit).
Bitcoin Forum post — February 04, 2010 — source: 0034-00222.md
Post by: satoshi on February 04, 2010, 12:07:07 AM
Port forwarding forwards a port to one computer. It tells the router
which computer handles connections to that port. So that’s the computer
receiving.
If you didn’t set up port forwarding, then incoming connections won’t
go to any computer, and attempts to send to that IP would just say it
couldn’t connect to the recipient and nothing is sent. When sending by
IP, you still send to a bitcoin address, but your computer connects to
that IP, gets a new bitcoin address from it, gives the transaction
directly to the them and confirms that it was received and accepted.
Someone should post their static IP so people can try out sending by
IP and also give that user free money.
There’s a 32-bit checksum in bitcoin addresses so you can’t
accidentally type an invalid address.
If 4) you send to a recipient who has abandoned or lost their
wallet.dat, then the money is lost. A subtle point can be made that
since there is then less total money in circulation, everyone’s
remaining money is worth slightly more, aka “natural deflation”.
Bitcoin Forum post — February 04, 2010 — source: 0022-00223.md
Post by: satoshi on February 04, 2010, 12:30:50 AM
When using proxy port 9050, it will only make one attempt to connect
to IRC, then give up, since it knows it will probably always fail
because IRC servers ban all the TOR exit nodes. If you’re using another
port, it would assume it might be a regular old normal proxy and would
keep retrying IRC at longer and longer intervals. You should not use
Polipo or Privoxy as those are http filters and caches that would
corrupt Bitcoin’s messages if they make any changes. Bitcoin might be
trying to overcome it by reconnecting. You should use port 9050.
As riX says, the “is giving Tor only an IP address. Apps that do
DNS…” warnings are nothing to worry about. Bitcoin doesn’t use DNS at
all in proxy mode.
Since Bitcoin can’t get through to IRC through Tor, it doesn’t know
which nodes are currently online, so it has to try all the recently seen
nodes. It tries to conserve connection attempts as much as possible, but
also people want it to connect quickly when they start it up and
reconnect quickly if disconnected. It uses an algorithm where it tries
an IP less and less frequently the longer ago it was successful
connected. For example, for a node it saw 24 hours ago, it would wait 5
hours between connection attempts. Once it has at least 2 connections,
it won’t try anything over a week old, and 5 connections it won’t try
anything over 24 hours old.
Bitcoin Forum post — February 05, 2010 — source: 0043-00249.md
Post by: satoshi on February 05, 2010, 07:19:12 PM
Last edit: August 27, 2010, 12:18:03 AM by satoshi
We had our first automatic adjustment of the proof-of-work difficulty
on 30 Dec 2009.
The minimum difficulty is 32 zero bits, so even if only one person
was running a node, the difficulty doesn’t get any easier than that. For
most of last year, we were hovering below the minimum. On 30 Dec we
broke above it and the algorithm adjusted to more difficulty. It’s been
getting more difficult at each adjustment since then.
The adjustment on 04 Feb took it up from 1.34 times last year’s
difficulty to 1.82 times more difficult than last year. That means you
generate only 55% as many coins for the same amount of work.
The difficulty adjusts proportionally to the total effort across the
network. If the number of nodes doubles, the difficulty will also
double, returning the total generated to the target rate.
For those technically inclined, the proof-of-work difficulty can be
seen by searching on “target:” in debug.log. It’s a 256-bit unsigned hex
number, which the SHA-256 value has to be less than to successfully
generate a block. It gets adjusted every 2016 blocks, typically two
weeks. That’s when it prints “GetNextWorkRequired RETARGET” in
debug.log.
Bitcoin Forum post — February 05, 2010 — source: 0034-00250.md
Post by: satoshi on February 05, 2010, 07:44:46 PM
Quote from: Sabunir on February 05, 2010, 05:31:30 PM
Perhaps there should be a feature against this? For instance, if a
transaction isn’t accepted by the recipient for a long period of time (a
month?), the transaction will be canceled and the coins returned to the
one who sent them?
That’s not possible. You’ve handed control of the money over to the
recipient’s keypair. Only that key can control it.
It’s similar to if you encrypt a file with AES and a strong password,
and you lose the password. The data is lost.
Bitcoin Forum post — February 06, 2010 — source: 0007-00264.md
Post by: satoshi on February 06, 2010, 09:06:32 PM
When you send to a bitcoin address, you don’t connect to the
recipient. You send the transaction to the network the same way you
relay transactions. There’s no distinction between a transaction you
originated and one you received from another node that you’re relaying
in a broadcast. With a very small network though, someone might still
figure it out by process of elimination. It’ll be better when the
network is larger.
If you send by IP, the recipient sees you because you connect to
their IP. You could use TOR to mask that.
You could use TOR if you don’t want anyone to know you’re even using
Bitcoin.
Bitcoin is still very new and has not been independently analysed. If
you’re serious about privacy, TOR is an advisable precaution.
Re: How divisible are bitcoins and other market/economic questions
Bitcoin Forum post — February 06, 2010 — source: 0044-00267.md
Post by: satoshi on February 06, 2010, 11:25:53 PM
Eventually at most only 21 million coins for 6.8 billion people in
the world if it really gets huge.
But don’t worry, there are another 6 decimal places that aren’t
shown, for a total of 8 decimal places internally. It shows 1.00 but
internally it’s 1.00000000. If there’s massive deflation in the future,
the software could show more decimal places.
If it gets tiresome working with small numbers, we could change where
the display shows the decimal point. Same amount of money, just
different convention for where the “,”’s and “.”’s go. e.g. moving the
decimal place 3 places would mean if you had 1.00000 before, now it
shows it as 1,000.00.
Bitcoin Forum post — February 08, 2010 — source: 0045-00278.md
Post by: satoshi on February 08, 2010, 01:22:29 AM
No, sorry. I’ve been meaning to redo it. The largest icon that still
looks good is the 20x20 one which is used for the tray icon in GNOME.
Any larger than that looks bad. The 16x16 and 20x20 ones have quite a
bit of hand tweaking to get the pixels to work out right. If you just
scale down a larger image, the pixels end up blurred and awkward in
places where the lines in “BC” don’t land square on a pixel.
The best 16x16 with full alpha channel is in src/rc/bitcoin.ico. I
don’t like the 32x32 version.
I’m attaching bitcoin20x20.png, the 20x20 version with full
transparency.
Bitcoin Forum post — February 08, 2010 — source: 0047-00279.md
Post by: satoshi on February 08, 2010, 01:27:02 AM
Last edit: February 09, 2010, 03:59:32 PM by sirius-m
Thank you for the offer to help translate. That is probably the best
way you could help.
I will need to prepare the code for translation first. wxWidgets has
locale support, and most strings are in generated code that is already
wrapped, so it shouldn’t be too hard. We also must finish upgrading to
wxWidgets-2.9.0 to get UTF-8 support. I’ve done test builds with 2.9.0
and there is one bug left to fix.
What operating system are you using? Windows, Linux 32-bit or 64
bit?
Bitcoin Forum post — February 08, 2010 — source: 0047-00283.md
Post by: satoshi on February 08, 2010, 04:10:37 PM
It’s much easier to have a single binary and multiple .mo files. It’s
too much maintenance work to have lots of build variations. Once the
software support is implemented, anyone could contribute
translations.
wxWidgets uses the gettext standard. You use the gettext tools or
something like poedit to create a .po file by scanning the sourcefiles
for strings and editing the translations into the .po file, then compile
it into a .mo file. The program loads the .mo file at runtime and
reskins all the strings. Additional languages can be added to an
existing program by adding .mo files without recompiling the
program.
On Windows, the .mo files would go in a lang subdirectory in the
directory where the EXE is located.
Right now I’m working on JSON-RPC and command line support, but when
I’m finished with that I hope to do this next.
Bitcoin Forum post — February 08, 2010 — source: 0046-00284.md
Post by: satoshi on February 08, 2010, 04:37:24 PM
There are command line options:
bitcoin -addnode=1.2.3.4 to tell bitcoin about a node to connect to
bitcoin -connect=1.2.3.4 connect only to the specified node(s)
You can use more than one of these, for instance
bitcoin -connect=(first to try) -connect=(next to try) …
You can specify non-routable IPs with -connect like 192.168.x.x, so
if you had a server farm and you wanted one server to connect to the
world and the rest to connect to the one server, you could do that.
In particular, -addnode is needed if you’re always going to connect
through TOR, since the IRC server blocks all the TOR exit nodes. To
connect through TOR, you could use:
Bitcoin Forum post — February 12, 2010 — source: 0049-00315.md
Post by: satoshi on February 12, 2010, 02:33:02 AM
Are you just trying to run the program or do you really need to
compile it? There’s a 32-bit linux binary that can be run on 64-bit
ubuntu if you “sudo apt-get ia32-libs”.
I recently updated the SVN for building on 64-bit Karmic with
wxWidgets 2.9.0. This was after the 0.2.0 release. The 0.2.0 release did
not build on 64-bit yet.
Unfortunately there currently isn’t a -dev deb package of either of
the versions of wxWidgets that we can use. On Karmic they only have the
UTF-16 version. We need either the ANSI (libwxgtk2.8-ansi-dev) version
or the UTF-8 (wxWidgets 2.9.0) version. We’re moving towards 2.9.0.
I know you said you didn’t want VM, but as a last resort, last I
checked the Windows version runs fine in Wine.
Bitcoin Forum post — February 12, 2010 — source: 0048-00316.md
Post by: satoshi on February 12, 2010, 03:08:08 AM
Last edit: February 14, 2010, 06:36:31 AM by satoshi
There’s a small transaction fee for very large transactions. The node
that generates the block that contains the transaction gets the fee.
If the same money gets sent again, it won’t incur the fee again. If
all you have is generated coins in your wallet, if you send them all in
one huge transaction, it has to bundle hundreds of 50 bc coins together.
After that it’s just one line to send the combined unit.
Bitcoin Forum post — February 12, 2010 — source: 0049-00322.md
Post by: satoshi on February 12, 2010, 03:57:37 PM
Quote from: soultcer on February 12, 2010, 02:31:50 PM
If you want, I can provide you with a precompiled binary.
Am I missing something? Is there something wrong with the 32-bit
linux precompiled binary on bitcoin.org?
The bitcoin binary in the distribution static links the wxWidgets
library, and its shared links (openssl and GTK) are included in Ubuntu,
so it can run without needing to be a .deb to pull down
dependencies.
Since we’re upgrading to wxWidgets 2.9.0 for UTF-8, which doesn’t
have a DEB package yet, we’ll continue to need to static link it.
Bitcoin Forum post — February 12, 2010 — source: 0007-00324.md
Post by: satoshi on February 12, 2010, 05:28:32 PM
True, sending by IP through Tor trades one problem for another. The
Tor exit node can see the text of your message and potentially MITM
you.
Best to only send to bitcoin addresses then. Payments by bitcoin
address are broadcast over the network as part of the normal network
traffic. All communications with the network are broadcasts of public
information.
Bitcoin Forum post — February 13, 2010 — source: 0049-00326.md
Post by: satoshi on February 13, 2010, 01:38:37 AM
Last edit: February 14, 2010, 12:09:32 AM by satoshi
I couldn’t get wxWidgets 2.8.9 to compile on Karmic 64-bit
either.
I have been compiling the latest SVN on Karmic 64-bit with wxWidgets
2.9.0, which compiles fine on 64-bit. Read build-unix.txt and use the
given ../configure parameters on wxWidgets so you can use the
makefile.unix.wx2.9 as supplied. (--enable-debug --disable-shared
--enable-monolithic)
There’s one cosmetic bug with 2.9.0 I still need to fix where
the status number display is bunched up for some reason. –
fixed
The download link on the homepage is to the sourceforge tar.gz
archive which contains the 32-bit binary and the 0.2.0 sources, which
were not yet buildable on 64-bit at the time.
The SVN was first buildable on 64-bit with wx2.9.0 on 28 January
2010.
Hopefully they’ll have a wxWidgets 2.9.0 debian package someday.
Bitcoin Forum post — February 14, 2010 — source: 0048-00327.md
Post by: satoshi on February 14, 2010, 06:28:03 AM
Quote from: theymos on February 12, 2010, 08:31:52 AM
Does the sending client send more BitCoins to account for the fee (so
the recipient gets what he’s expecting)?
Yes.
Quote from: SmokeTooMuch on February 12, 2010, 01:11:09 PM
why do we even need fees ? i thougt the no-fees-feature was one of
the advantages of bitcoin ?!
Almost all transactions are free. A transaction is over the maximum
size limit if it has to add up more than 500 of the largest payments
you’ve received to make up the amount. A transaction over the size limit
can still be sent if a small fee is added.
The average transaction, and anything up to 500 times bigger than
average, is free.
It’s only when you’re sending a really huge transaction that the
transaction fee ever comes into play, and even then it only works out to
something like 0.002% of the amount. It’s not money sucked out of the
system, it just goes to other nodes. If you’re sad about paying the fee,
you could always turn the tables and run a node yourself and maybe
someday rake in a 0.44 fee yourself.
Bitcoin Forum post — February 14, 2010 — source: 0048-00329.md
Post by: satoshi on February 14, 2010, 03:52:23 PM
Last edit: February 14, 2010, 04:02:56 PM by satoshi
Right. Otherwise we couldn’t have a finite limit of 21 million coins,
because there would always need to be some minimum reward for
generating. In a few decades when the reward gets too small, the
transaction fee will become the main compensation for nodes. I’m sure
that in 20 years there will either be very large transaction volume or
no volume.
Another big jump in difficulty yesterday from 1.82 times to 2.53
times, a 39% increase since 10 days ago. It was 10 days apart not 14
because more nodes joined and generated the 2016 blocks in less
time.
Re: Setting up multiple bitcoin machines behind NAT
Bitcoin Forum post — February 16, 2010 — source: 0054-00360.md
Post by: satoshi on February 16, 2010, 01:34:56 AM
Right now there isn’t a port number setting to do that. It’s a
feature yet to be implemented. You can only set up your NAT to
port-forward to one of the computers. (I said something earlier about
NAT port translation, but that wouldn’t work, other nodes wouldn’t know
to connect to that port)
If you want, as a small optimization, you could run the rest of your
computers as:
bitcoin -connect=<the IP of the first computer>
so they get all their network communication from the first computer
and don’t all connect over the net individually for the same
information. This saves bandwidth, although it doesn’t use much
bandwidth to begin with, so it wouldn’t really matter unless you had
tons of computers.
For redundancy in case the first computer goes down, you could have
two that connect out and the rest connect to both of them. The first two
are run normally, the rest are run like:
Bitcoin Forum post — February 16, 2010 — source: 0043-00376.md
Post by: satoshi on February 16, 2010, 05:36:40 PM
Quote from: Suggester on February 16, 2010, 02:15:49 AM
Satoshi, I figured it will take my modern core 2 duo about 20 hours
of nonstop work to create ฿50.00! With older PCs it will take forever.
People like to feel that they “own” something as soon as possible, is
there a way to make the generation more divisible? So say, instead of
making ฿50 every 20 hours, make ฿5 every 2 hours?
I thought about that but there wasn’t a practical way to do smaller
increments. The frequency of block generation is balanced between
confirming transactions as fast as possible and the latency of the
network.
The algorithm aims for an average of 6 blocks per hour. If it was 5
bc and 60 per hour, there would be 10 times as many blocks and the
initial block download would take 10 times as long. It wouldn’t work
anyway because that would be only 1 minute average between blocks, too
close to the broadcast latency when the network gets larger.
Bitcoin Forum post — February 17, 2010 — source: 0043-00388.md
Post by: satoshi on February 17, 2010, 05:58:03 PM
Quote from: Sabunir on February 16, 2010, 08:51:51 AM
. Perhaps it has to do with my connection’s very high latency (2000ms
or more on average)
2 seconds of latency in both directions should reduce your generation
success by less than 1%.
Quote from: Sabunir on February 16, 2010, 08:51:51 AM
and/or my high packet loss (sometimes up to 10% loss)?
Probably OK, but I’m not sure. The protocol is designed to resync to
the next message, and messages get re-requested from all the other nodes
you’re connected to until received. If you miss a block, it’ll also keep
requesting it every time another blocks comes in and it sees there’s a
gap. Before the original release I did a test dropping 1 out of 4 random
messages under heavy load until I could run it overnight without any
nodes getting stuck.
Bitcoin Forum post — February 21, 2010 — source: 0058-00413.md
Post by: satoshi on February 21, 2010, 03:43:48 AM
Nodes stop trying to initiate connections once they have 15. If you
can accept incoming connections, then you can get well above that from
nodes connecting to you, otherwise you max out at 15.
I don’t know if there’s any reason to have 15 connections. Maybe it
should be 10.
Since nodes that can only connect out are probably at or near 15 most
of the time now, you should level off to an equilibrium. 45 suggests a
ratio of 3 out-only nodes to every 1 in-accepting node.
The number of connections won’t be a good gauge of the size of the
network any more. Someone should periodically IRC to the bitcoin channel
on chat.freenode.net and count the number of users. That gives you the
total count of network nodes (except TOR nodes).
Block generation is again running ahead of pace. We’re in for another
big step up in difficulty at the next adjustment in about 5 days.
Bitcoin Forum post — February 21, 2010 — source: 0059-00414.md
Post by: satoshi on February 21, 2010, 04:19:53 AM
It would be nice to have a list of static IPs for new users to send
test donations to so they can see how the software works. If you can
accept incoming connections and you have a static IP address, post it
here!
Anything sent to these IPs should be considered a donation.
If you do request a round-trip, be sure to include your return
bitcoin address or IP in the comment, but please assume it’ll be
one-way. They won’t necessarily be watching for incoming transactions to
send back.
Re: Current Bitcoin economic model is unsustainable
Bitcoin Forum post — February 21, 2010 — source: 0057-00415.md
Post by: satoshi on February 21, 2010, 05:44:24 AM
Excellent analysis, xc.
A rational market price for something that is expected to increase in
value will already reflect the present value of the expected future
increases. In your head, you do a probability estimate balancing the
odds that it keeps increasing.
In the absence of a market to establish the price,
NewLibertyStandard’s estimate based on production cost is a good guess
and a helpful service (thanks). The price of any commodity tends to
gravitate toward the production cost. If the price is below cost, then
production slows down. If the price is above cost, profit can be made by
generating and selling more. At the same time, the increased production
would increase the difficulty, pushing the cost of generating towards
the price.
In later years, when new coin generation is a small percentage of the
existing supply, market price will dictate the cost of production more
than the other way around.
At the moment, generation effort is rapidly increasing, suggesting
people are estimating the present value to be higher than the current
cost of production.
Bitcoin Forum post — February 21, 2010 — source: 0060-00426.md
Post by: satoshi on February 21, 2010, 09:48:01 PM
Uploaded some UI changes to SVN as version 0.2.5.
Instead of View->Show Generated, we now have tabs:
- All Transactions
- Sent/Received
- Sent
- Received
Makes it a lot easier to flip to received and check for payments.
Moved the “Your Addresses” book inside the main address book. It was
confusing having two address books.
I found the “To:” in “From: unknown, To: (one of your bitcoin
addresses)” still confusing, so I changed it to “From: unknown, Received
with:”. The bitcoin address is abbreviated so you can see the label that
you set in the Receiving tab of the address book.
Fixed a few UI glitches from the upgrade to wxWidgets 2.9.0.
I haven’t forgotten about you people who want non-UI, but I had to do
some fun stuff before more build bashing.
Bitcoin Forum post — February 23, 2010 — source: 0061-00433.md
Post by: satoshi on February 23, 2010, 12:49:56 AM
Just a random streak of bad luck. It looks steady to me.
Competition doesn’t have an effect until the next automatic retarget
adjustment, and we haven’t reached the next one yet.
The adjustments are every 2016 blocks. To calculate our progress
towards the next one, divide the block total by 2016. The fractional
part is how far we are to the next one.
My back-of-the-envelope projection: 42032 blocks/2016 = 20.85 = 85%
of the way. About 1.5 days to go until the next one. That’ll only be
about 10 days since the last one, the target is 14 days, so 14/10 = 1.4
= around 40% difficulty increase.
Bitcoin Forum post — February 23, 2010 — source: 0060-00434.md
Post by: satoshi on February 23, 2010, 01:16:28 AM
There are now “Sending” and “Receiving” tabs in the Address Book.
Your addresses are referred to as “receiving addresses”.
madhatter was working on building it on Mac. He had errors probably
caused by UTF-16 wxWidgets 2.8. Should have better luck now with 2.9.0.
wxWidgets 2.9.0 is UTF-8 and wouldn’t have that problem.
I think he had it working on FreeBSD, but he wanted a non-UI
version.
I have the command line and JSON-RPC daemon version working now. Will
SVN it in a day or two.
I disabled gdm on my Ubuntu system so it boots into command line. I
hope I will be able to get it enabled again with rcconf.
Bitcoin Forum post — February 23, 2010 — source: 0062-00443.md
Post by: satoshi on February 23, 2010, 04:26:09 PM
There’s a separate public/private keypair for every bitcoin address.
You don’t have a single private key that unlocks everything. Bitcoin
addresses are a 160-bit hash of the public key, everything else in the
system is 256-bit.
If there was a collision, the collider could spend any money sent to
that address. Just money sent to that address, not the whole wallet.
If you were to intentionally try to make a collision, it would
currently take 2^126 times longer to generate a colliding bitcoin
address than to generate a block. You could have got a lot more money by
generating blocks.
The random seed is very thorough. On Windows, it uses all the
performance monitor data that measures every bit of disk performance,
network card metrics, cpu time, paging etc. since your computer started.
Linux has a built-in entropy collector. Adding to that, every time you
move your mouse inside the Bitcoin window you’re generating entropy, and
entropy is captured from the timing of disk ops.
Bitcoin Forum post — February 23, 2010 — source: 0063-00452.md
Post by: satoshi on February 23, 2010, 10:15:41 PM
Last edit: February 24, 2010, 12:12:44 AM by satoshi
Version 0.2.6 on SVN can now run as a daemon and be controlled by
command line or JSON-RPC.
On Linux it needs libgtk2.0-0 installed, but does not need a GUI
running. Hopefully gtk can be installed without having a windowing
system installed.
The command to start as a daemon is: bitcoin -daemon [switches…]
Or, to run the UI normally and also be able to control it from
command line or JSON-RPC, use the “-server” switch.
bitcoin -server [switches…]
With either switch, it runs an HTTP JSON-RPC server that accepts
local socket connections on 127.0.0.1:8332. The port is bound to
loopback and can only be accessed from the local machine, but from any
account, not just the user it’s running under.
To control it from the command line, the interface is a command name
without any switches, followed by parameters if any.
bitcoin [params…]
For example:
bitcoin getinfo
bitcoin getdifficulty
bitcoin setgenerate true
bitcoin stop
It’s a simple JSON-RPC client and prints the JSON result. Look at
rpc.cpp for the list of commands.
Web apps or anything automated will normally use JSON-RPC directly,
not command line. There are JSON-RPC libraries for all the major
languages. In script languages like PHP and Python the syntax is as
natural as calling a local function.
Bitcoin Forum post — February 23, 2010 — source: 0062-00453.md
Post by: satoshi on February 23, 2010, 10:24:00 PM
Quote from: NewLibertyStandard on February 23, 2010, 07:04:47 PM
Are generated bitcoins encrypted with whichever address is currently
displayed in the main Bitcoin window?
No, each generated transaction uses a new, single-use address.
Nothing uses the address in the main window, it’s just there for
convenience for you to copy. 0.2.5 has a “New…” button next to it to
make it easy to change each time you use it.
Bitcoin Forum post — February 24, 2010 — source: 0055-00481.md
Post by: satoshi on February 24, 2010, 05:57:43 AM
That would be nice at point-of-sale. The cash register displays a
QR-code encoding a bitcoin address and amount on a screen and you photo
it with your mobile.
Bitcoin Forum post — February 24, 2010 — source: 0063-00482.md
Post by: satoshi on February 24, 2010, 06:17:23 AM
Quote from: theymos on February 24, 2010, 03:07:37 AM
Quote from: satoshi on February 23, 2010, 10:15:41 PM
On Linux it needs libgtk2.0-0 installed
Will this requirement be removed sometime? I’d rather not have to
deal with GTK.
How much “dealing with” does GTK actually require? Is it just a
matter of “sudo apt-get install libgtk2.0-0” and having some extra
libraries sitting around? GTK doesn’t have to do anything, just be there
for bitcoin to link to when it loads up, have the gtk-init-check call
fail because no GUI present, then it’s done.
It saves us butchering everything with ifdefs and a separate compile
and binary to use wxBase just to try to avoid linking GTK.
Bitcoin Forum post — February 24, 2010 — source: 0045-00507.md
Post by: satoshi on February 24, 2010, 09:53:52 PM
If you GPL stuff, I have to avoid using it. Nothing against GPL
per-se, but Bitcoin is an MIT license project. Anything GPL please
clearly mark it as such.
Bitcoin Forum post — February 24, 2010 — source: 0063-00509.md
Post by: satoshi on February 24, 2010, 10:08:55 PM
When and how fast did memory usage increase? Right away, slowly over
a long time, or starting at some later event?
I have -daemon running on ubuntu 9.10 64-bit and memory usage is
steady.
It has to be something about the difference on the server besides
64-bit. Maybe some malfunction from the lack of GUI. A memory leak debug
tool could give a clue.
Bitcoin Forum post — February 25, 2010 — source: 0064-00521.md
Post by: satoshi on February 25, 2010, 01:56:24 AM
Quote from: Sabunir on February 25, 2010, 01:47:56 AM
I like them. Do they come in higher resolutions?
Yes, the original is 546x531 pixels.
It looks good at larger size too, but since the small icons are what
you mostly always see, I wanted to judge it on those first. I’ll post
larger sizes and full size a little later.
Bitcoin Forum post — February 25, 2010 — source: 0063-00539.md
Post by: satoshi on February 25, 2010, 10:54:17 PM
OK, I made a build target bitcoind that only links wxBase and does
not link GTK. Version 0.2.7 on SVN.
I split out the init and shutdown stuff from ui.cpp into init.cpp, so
now ui.cpp is pure UI. ui.h provides inline stubs if wxUSE_GUI=0. We
only have four functions that interface from the node to the UI. In the
bitcoind build, we don’t link ui.o or uibase.o.
Quote from: sirius-m on February 25, 2010, 04:32:17 PM
It started increasing right away. I’ll see if valgrind can help
me.
Sure feels like it could be something in wxWidgets retrying endlessly
because some UI thing failed or something wasn’t inited correctly. Our
hack to ignore the initialize failure and run anyway means we’re in
uncharted territory. We’re relying on the fact that we hardly use wx in
this mode. We do still use a few things like wxGetTranslation and
wxMutex.
Another way to debug would be to run in gdb, wait until everything is
quiet and all threads should be idle, and break it and see which thread
is busily doing something and what it’s doing.
I suspect bitcoind will probably work fine, but I hope you can still
debug the problem.
Bitcoin Forum post — February 25, 2010 — source: 0043-00540.md
Post by: satoshi on February 25, 2010, 11:06:29 PM
The formula is based on the time it takes to generate 2016 blocks.
The difficulty is multiplied by 14/(actual days taken). For instance,
this time it took 9.4 days, so the calculation was 14/9.4 = 1.49.
Previous difficulty 2.53 * 1.49 = 3.78, a 49% increase.
I don’t know what you’re talking about accepting easier
difficulties.
Bitcoin Forum post — February 26, 2010 — source: 0063-00555.md
Post by: satoshi on February 26, 2010, 04:29:21 PM
wx/clipbrd.h isn’t used, move it inside the #if wxUSE_GUI.
Updated headers.h on SVN.
Sorry, I linked to wxbase but I had full wxWidgets on my
computer.
The db.h:140 class Db no member named “exisits” is stranger.
pdb->get, pdb->put, pdb->del compiled before that. Do you have
version 4.7.25 of Berkeley DB?
Bitcoin Forum post — February 26, 2010 — source: 0064-00561.md
Post by: satoshi on February 26, 2010, 11:17:19 PM
Good suggestion. I made the B slightly lighter and the background
slightly darker. Very slightly. The foreground is now exactly the same
colour as the BC in the old one.
It’s kind of OK if you can’t easily read the B in the 16x16. At that
size, you just need to see that it’s a coin. It doesn’t matter so much
what’s embossed on it, just that there be some detail there because it
wouldn’t look like a coin if it was a blank smooth circle.
It’s slightly wider than tall because the dark perspective under it
goes more to the right than down.
I finished and posted the 32x31 and 48x47 versions in the first
message. I like the 48 a lot.
How does everyone feel about the B symbol with the two lines through
the outside? Can we live with that as our logo?
Bitcoin Forum post — February 27, 2010 — source: 0064-00566.md
Post by: satoshi on February 27, 2010, 04:28:29 AM
Quote from: Cdecker on February 27, 2010, 03:24:07 AM
How about an SVG version? That way we could automatically generate
smaller and larger versions as needed.
I don’t know how to do SVG, but I did the original very large, over
500 pixels across, so it can be scaled down. I’ll give the original when
I’m finished.
I had to custom tweak each icon size so the vertical lines land
square on their pixels, otherwise they’re ugly blurry and inconsistent.
Such is the challenge of making icons. The original will be good for
scaling to custom sizes between 48 and 500 but not smaller.
Bitcoin Forum post — February 27, 2010 — source: 0065-00571.md
Post by: satoshi on February 27, 2010, 09:22:53 PM
Quote from: Cdecker on February 27, 2010, 05:09:59 PM
Looking through the source of 2.8.10 it appears that unicode is
possible with that version too.
In the Windows world, “unicode” means UTF-16 (wchar).
2.8 has two build variations, ANSI and UTF-16 (unicode). The UTF-16
version is the “unicode” version provided in the Debian package. I
believe 2.8 and its UTF-16 build labelled simply “unicode” has been the
source of build problems described in the forum. We were previously
using 2.8 ANSI in anticipation of getting to UTF-8 without going through
UTF-16 hell. We cannot compile with UTF-16.
2.9 has only one version, UTF-8. On Windows, we set the codepage to
UTF-8, so on all platforms our code is UTF-8 and wxWidgets interfaces
with us in UTF-8. On Linux I assume the codepage is already UTF-8. By
standardizing on 2.9 we avoid the multi-build confusion of 2.8, and we
need 2.9 for UTF-8 internationalization.
Make sure you read build-unix.txt and configure wxWidgets using the
configure parameters given.
Curious, why is it incredibly hard to provide wxWidgets 2.9.0? If you
mean for users, that’s why we static link it.
It’s unfortunate that we require so many big dependencies, but we
need them all. At least on Debian/Ubuntu, all but wxWidgets are
available as packages. Eventually they’ll provide a 2.9 package.
Bitcoin Forum post — March 03, 2010 — source: 0069-00614.md
Post by: satoshi on March 03, 2010, 04:28:56 AM
When there’s enough scale, maybe there can be an exchange site that
doesn’t do transfers, just matches up buyers and sellers to exchange
with each other directly, similar to how e-bay works.
To make it safer, the exchange site could act as an escrow for the
bitcoin side of the payment. The seller puts the bitcoin payment in
escrow, and the buyer sends the conventional payment directly to the
seller. The exchange service doesn’t handle any real world money.
This would be a step better than e-bay. E-bay manages to work fine
even though shipped goods can’t be recovered if payment falls
through.
Bitcoin Forum post — March 05, 2010 — source: 0063-00633.md
Post by: satoshi on March 05, 2010, 01:46:25 AM
Quote from: sirius-m on February 24, 2010, 06:17:35 PM
This is strange… When I start Bitcoin as a daemon on my 64 bit Linux
server, it eats up all the 250MB of remaining RAM, 700MB of swap and
eventually crashes. On my 32 bit Ubuntu desktop, it works fine and stays
at 15MB of memory usage. The server is running a 64 bit build of
Bitcoin. Maybe there’s something wrong with the build or something.
sirius-m debugged this, it was 64-bit related.
Bitcoin Forum post — March 15, 2010 — source: 0072-00717.md
Post by: satoshi on March 15, 2010, 06:44:12 PM
It sets different priorities for each thread. The generate threads
run at PRIO_MIN. The other threads rarely take any CPU and run at
normal.
#define THREAD_PRIORITY_LOWEST PRIO_MIN
#define THREAD_PRIORITY_BELOW_NORMAL 2
#define THREAD_PRIORITY_NORMAL 0
The priorities converted from Windows priorities were probably from a
table like this:
“The following table shows the mapping between nice values and Win32
priorities. Refer to the Win32 documentation for SetThreadPriority() for
more information on Win32 priority issues.
nice value Win32 Priority
-20 to -16 THREAD_PRIORITY_HIGHEST
-15 to -6 THREAD_PRIORITY_ABOVE_NORMAL
-5 to +4 THREAD_PRIORITY_NORMAL
+5 to +14 THREAD_PRIORITY_BELOW_NORMAL
+15 to +19 THREAD_PRIORITY_LOWEST”
If you have better values, suggestions welcome.
Also, there was some advice on the web that PRIO_PROCESS is used on
Linux because threads are processes. If that’s not true, maybe it
accounts for unexpectedly setting the priority of the whole app.
// threads are processes on linux, so PRIO_PROCESS affects just the one thread
setpriority(PRIO_PROCESS, getpid(), nPriority);
Bitcoin Forum post — March 15, 2010 — source: 0083-00719.md
Post by: satoshi on March 15, 2010, 07:16:56 PM
Last edit: March 24, 2010, 05:50:31 PM by satoshi
When you want to upload an image to embed in a forum post, there are
services like imageshack, but because they’re free, they limit the
number of views. It’s a minuscule amount of bandwidth cost, but they
can’t just give it away for free, there has to be something in it for
them. It would be nice to be able to pay for the bandwidth and avoid the
limits, but conventional payments are too inconvenient for such a minor
thing.
It’s worse if you want to upload a file for others to download. There
are services like rapidshare, but they require the downloaders to go
through extra steps and delays to make them look at advertising or
encourage upgrading to a paid subscription, and they limit it to 10 or
so downloads.
It would be nice if we made some free PHP code for an image and file
hosting service that charges Bitcoins. Anyone with some extra bandwidth
quota could throw it on their webserver and run it. Users could finally
pay the minor fee to cover bandwidth cost and avoid the limits and
hassles. Ideally, it should be MIT license or public domain.
Services like this would be great for anonymous users, who have
trouble paying for things.
Bitcoin Forum post — March 16, 2010 — source: 0084-00729.md
Post by: satoshi on March 16, 2010, 07:48:47 PM
Thanks soultcer for talking with the Freenode staffer. Good to know
it’s OK at the current size, and now they know who we are. They’re
supportive of projects like TOR so I hope they would probably be
friendly to us. We don’t want to overstay our welcome. If we get too
big, then by the same token, we’re big enough that we don’t need IRC
anymore and we’ll get off.
We only needed IRC because nobody had a static IP. In the early days
there were some steady supporters, but they all had pool-allocated IPs
that change every few days. IRC was only intended as a temporary
solution. Bitcoin’s built-in addr system is the main solution.
Bitcoin can get the list of IPs from any bitcoin node. In that sense,
every node serves as a directory server.
When there are enough static IP nodes to have a good chance that at
least one will still be running by the time the current version goes out
of use, we can preprogram a seed list.
How do you think we should compile the seed list? Would it be OK to
create it from the currently connected IPs that have been static for a
while?
BTW, if we want to supplement by deploying separate directory server
software, may I suggest IRC? IRC is a good directory server (I’ve heard
it has other uses too), and there are mature IRC server implementations
available that anyone can run. :) Bitcoin’s IRC client implementation is
already thoroughly tested.
Bitcoin Forum post — March 16, 2010 — source: 0083-00731.md
Post by: satoshi on March 16, 2010, 08:17:34 PM
That’s a great idea. There’s a thriving business in those services,
but I’ve always thought the standard payment methods are at odds with
privacy minded customers.
Would you consider making your software freely available so anyone
could easily set one up? I know for competitive reasons the inclination
is to keep it to yourself, but it could get an order of magnitude more
use if anyone could give proxy access to their country just by putting
the software on a server.
I wonder if there are other kinds of web application servers where we
would only have to tack on the payment mechanism to an already existing
system?
Bitcoin Forum post — March 23, 2010 — source: 0088-00806.md
Post by: satoshi on March 23, 2010, 03:22:41 PM
It’s unrelated. There wasn’t anything there when I started.
The price of .com registrations is lower than it should be, therefore
any good name you might think of is always already taken by some domain
name speculator. Fortunately, it’s standard for open source projects to
be .org.
Bitcoin Forum post — March 23, 2010 — source: 0087-00807.md
Post by: satoshi on March 23, 2010, 05:35:34 PM
LR and Pecunix have many established exchanges to paper currencies by
various payment methods, and a number of vendors accept them as payment,
so an exchange link between Bitcoin and LR/Pecunix would give us 2nd-hop
access to all that. The possibility to cash out through them would help
support the value of bitcoins.
Bitcoin has unique properties that would be complementary. LR/Pecunix
are easy to spend anonymously, but hard to buy anonymously and not worth
the trouble to buy in small amounts. Bitcoin, on the other hand, is easy
to get in small amounts anonymously. It would be convenient to buy
LR/Pecunix with bitcoins rather than through conventional payment
methods.
Most customers who convert to LR to buy something would probably ask
the seller first if they accept Bitcoin, encouraging them to start
accepting it.
Bitcoin Forum post — March 24, 2010 — source: 0083-00809.md
Post by: satoshi on March 24, 2010, 06:01:57 PM
Title changed.
It helps that we have someone with actual experience running a proxy
service. Do you think Psiphon is the best one currently? (sometimes the
one you run was the best when you started but you found better ones
later)
Bitcoin Forum post — March 24, 2010 — source: 0083-00810.md
Post by: satoshi on March 24, 2010, 06:02:55 PM
Mihalism Multi Host is a popular open source PHP file hosting
server.
It’s geared toward image hosting, but I think by increasing the file
size limit and liberalising the allowed file extensions, it could just
as easily be used for general file upload hosting. They need the limits
to keep it reasonable as a free service, but if we bolt on a Bitcoin
payment mechanism, the limits could be relaxed.
It doesn’t have a bunch of client side scripting or anti-embedding
junk to rip out. It generates standard links that work normally.
There’s a turnover churn in these free hosting sites. Small sites can
give free image hosting, but once one starts getting popular, it gets
too swamped with moochers using them for free bandwidth. Any site that
gets well known has to become more aggressively pay-naggy to cover
bandwidth costs. It’s a perfect example of a service where the needed
price point is in the no-man’s-land between just a little too expensive
to be free, but too cheap for most users to take the trouble of a
conventional payment. It’s in the gap between 0 and 19.95. The best they
can do is try to maybe get 1 out of 1000 users to pay 9.95, but that has
999/1000 users treated like freeloaders. It can’t really be advertising
supported because the images are embedded in other sites and downloaded
without going to the hosting site.
What do you think? If I made a Bitcoin payment integration for this,
would anyone be interested in running it? It might be the first fully
automated service available to buy with Bitcoins. The advantage it could
offer over the free services is general file upload hosting of large
files without making downloading users go to the upload site and jump
through hoops. It would give a normal link directly to the file.
Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add
Bitcoin Forum post — May 16, 2010 — source: 0130-01130.md
Post by: satoshi on May 16, 2010, 09:01:44 PM
When you generate a new bitcoin address, it only takes disk space on
your own computer (like 500 bytes). It’s like generating a new PGP
private key, but less CPU intensive because it’s ECC. The address space
is effectively unlimited. It doesn’t hurt anyone, so generate all you
want.
Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses?
Bitcoin Forum post — May 16, 2010 — source: 0129-01131.md
Post by: satoshi on May 16, 2010, 09:37:36 PM
Quote from: Xunie on May 14, 2010, 09:52:53 PM
I suggest we disable IP transactions while the user uses a Proxy!
Just to be on the safe side.
That’s a good idea. At the very least a warning dialog explaining
that it’ll connect to the IP and send the information cleartext, giving
the chance to cancel.
Bitcoin can answer port 8330 on local loopback just as it does for
JSON-RPC on 8332. It would give an HTTP answer.
Quote from: DataWraith on May 02, 2010, 11:13:09 AM>
A bitcoin-link should be more like mailto: than magnet: IMHO.
I think we can do that.
Although it would be possible for Bitcoin to take care of business in
the HTTP response by presenting HTML UI to the user, as a user I would
wonder if some website is trying to trick me or if I’m really talking to
my own Bitcoin server.
The HTTP response could simply be HTML with the JavaScript equivalent
of the back button, sending it back to the page. Bitcoin then pops up
the Send Bitcoins dialog with the destination bitcoin address and amount
already filled in. It would work just like a mailto: link that pops up a
new email with the address filled in.
127.0.0.1 loopback is accessible by any user on the machine, it
doesn’t have per-user separation, but it’s OK because it would only
serve the convenience function of pre-filling the fields in a dialog.
You’d still have to press Send. We’d have to make sure the Send button
is not selected so it couldn’t jump into the foreground while you’re
typing a space or enter.
Bitcoin Forum post — May 16, 2010 — source: 0135-01133.md
Post by: satoshi on May 16, 2010, 10:53:59 PM
Does it happen every time you run it, or just happened once at some
random time?
I’ve never seen that fail before. It’s a call to OpenSSL that I
assumed would never fail, but I put an error check there just in case. I
can’t imagine how it would fail. Out of memory maybe.
Bitcoin Forum post — May 16, 2010 — source: 0101-01134.md
Post by: satoshi on May 16, 2010, 11:34:40 PM
Last edit: May 17, 2010, 12:26:28 AM by satoshi
SheriffWoody:
Bitcoin addresses you generate are kept forever. A bitcoin address
must be kept to show ownership of anything sent to it. If you were able
to delete a bitcoin address and someone sent to it, the money would be
lost. They’re only about 500 bytes.
sirius-m:
Thousands of own addresses should not be any problem at all. If
you’ve generated 50000 BTC, then you already have 1000 own addresses,
one for each 50 generated. Those are hidden, they’re not shown in the
UI.
It would be a good idea to add a little code that keeps giving the
same address to the same IP. Here’s what I did in C++ to keep giving the
same key (aka bitcoin address) until they use it:
// Keep giving the same key to the same ip until they use it
if (!mapReuseKey.count(pfrom->addr.ip))
mapReuseKey\[pfrom->addr.ip\] = GenerateNewKey();
...sends the key mapReuseKey\[pfrom->addr.ip\]
…later…
// Received something with this key
mapReuseKey.erase(pfrom->addr.ip);
If it’s not convenient to know when you’ve received, just clear the
cached keys every 20 minutes.
I want to add a parameter to getnewaddress for number of days to
expire if nothing is received with the address.
Re: Setting up multiple bitcoin machines behind NAT
Bitcoin Forum post — May 16, 2010 — source: 0054-01135.md
Post by: satoshi on May 16, 2010, 11:56:03 PM
At the moment, it always assumes the incoming port is 8333, so it
would tell other bitcoin nodes to connect to router:8333 even if you’re
redirecting from another port number.
I’m not in a big hurry to fix this because I can’t think of any
benefit to having more than one incoming connection port. If you’re
providing one incoming port, then you’ve done your bit to help the
network. Having two incoming ports to the same person doesn’t help
redundancy.
If you have many computers, then using the -connect switch on most of
them to connect locally makes more sense.
Re: Is there a way to automate bitcoin payments for a website?
Bitcoin Forum post — May 18, 2010 — source: 0112-01143.md
Post by: satoshi on May 18, 2010, 02:58:11 AM
A little late, but in case anyone else has the same issue. The
compile dump had 2 warnings (that were 20 lines long) and 2 link errors.
The errors were:
Quote
obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x13): In
function `wxArrayString::Item(unsigned long) const’:
/usr/local/include/wx-2.9/wx/buffer.h:42: undefined reference to
`wxTheAssertHandler’
obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x45): In
function `wxArrayString::Item(unsigned long) const’:
Those are probably due to switching to the release build of wxWidgets
instead of debug. They’re moving towards only debug build and ditching
the release build, so they probably don’t care that their release build
is broken by referring to non-existent assert stuff. There’s nothing to
fear about the debug build. It’s fully suitable for releases.
bitcoind runs as a daemon and can either be controlled by command
line or JSON-RPC.
Thanks madhatter and generica for detailing the instructions for
building on freebsd.
Bitcoin Forum post — May 18, 2010 — source: 0125-01149.md
Post by: satoshi on May 18, 2010, 08:06:46 PM
It’s not the download so much as verifying all the signatures in all
the blocks as it downloads that takes a long time.
How long is the initial block download typically taking? Does it slow
down half way through or is about the same speed the whole way?
I’ve thought about ways to do a more cursory check of most of the
chain up to the last few thousand blocks. It is possible, but it’s a lot
of work, and there are a lot of other higher priority things to work
on.
Simplified Payment Verification is for lightweight client-only users
who only do transactions and don’t generate and don’t participate in the
node network. They wouldn’t need to download blocks, just the hash
chain, which is currently about 2MB and very quick to verify (less than
a second to verify the whole chain). If the network becomes very large,
like over 100,000 nodes, this is what we’ll use to allow common users to
do transactions without being full blown nodes. At that stage, most
users should start running client-only software and only the specialist
server farms keep running full network nodes, kind of like how the
usenet network has consolidated.
SPV is not implemented yet, and won’t be implemented until far in the
future, but all the current implementation is designed around supporting
it.
In the meantime, sites like vekja.net
and www.mybitcoin.com have been
experimenting with account-based sites. You create an account on a
website and hold your bitcoins on account there and transfer in and out.
Creating an account on a website is a lot easier than installing and
learning to use software, and a more familiar way of doing it for most
people. The only disadvantage is that you have to trust the site, but
that’s fine for pocket change amounts for micropayments and misc
expenses. It’s an easy way to get started and if you get larger amounts
then you can upgrade to the actual bitcoin software.
Bitcoin Forum post — May 20, 2010 — source: 0030-01169.md
Post by: satoshi on May 20, 2010, 09:43:42 PM
Quote from: DataWraith on May 19, 2010, 07:52:42 PM
Can I just butt in with a question on why that is? To me it seems
that if Bitcoin uses public-key cryptography to transfer ownership of
the coins, it should be a trivial matter to include a short message that
is only readable by the recipient.
Almost but not quite. Bitcoin uses EC-DSA, which can only do digital
signing, not encryption. RSA can do both, but I didn’t use it because
it’s an order of magnitude bigger and would have been impractical.
Bitcoin Forum post — May 26, 2010 — source: 0157-01252.md
Post by: satoshi on May 26, 2010, 06:27:25 PM
Last edit: May 26, 2010, 06:53:08 PM by satoshi
I added label related functions to help with managing multiple
addresses per user. New or renamed functions are:
getreceivedbyaddress – amount received on a single address
getreceivedbylabel – amount received by all addresses with this
label
listreceivedbyaddress – list addresses and amounts they’ve
received
listreceivedbylabel – list labels and amounts they’ve received
setlabel – misc label functions for completeness
getlabel
getaddressesbylabel
For consistency I renamed getamountreceived->getreceivedbyaddress
and getallreceived->listreceivedbyaddress. The old names are still
there so as not to break existing code, but they’re deprecated.
The idea is that if you give the username whenever you call
getnewaddress, you can get the user’s total received across all their
addresses using the “bylabel” functions. You can freely change their
address without worrying about tracking all their old addresses.
A good way to automate changing the user’s receiving address: just
before displaying their current address, check if it has been used to
receive anything, if it has then replace it with a new one:
// Get a new address whenever the current one has received
anything
if (strAddr == “” || getreceivedbyaddress(strAddr) > 0)
strAddr = getnewaddress(strUsername); // Label the address with
username
Display(strAddr); // Display their current receiving address
// Get total received by all the user’s addresses
getreceivedbylabel(strUsername, 0) // unconfirmed
getreceivedbylabel(strUsername, 1) // available balance
If you’re just getting one particular user’s balance, such as in
response to a page request by that user, use getreceivedbylabel, but if
you’re scanning over all users, it’s better to use listreceivedbylabel
to get the complete list and scan against the result. Scanning users
with getreceivedbylabel would be n-squared, using listreceivedbylabel is
n-log-n (or n linear).
You should only really need to scan all users if you’re polling in
order to spontaneously take action in response to money received, rather
than the user going to a webpage, seeing their balance and telling you
what to do with it. It’s not necessary to poll very frequently. If you
require 1 confirmation, that’ll take an average of 10 minutes anyway, so
there’s no point in polling more often than every few minutes.
If you’re selling digital goods and services, where you don’t lose
much if someone gets a free access, and it can’t be resold for profit, I
think you’re fine to accept 0 confirmations.
It’s mostly only if you were selling gold or currency that you’d need
multiple confirmations.
Bitcoin Forum post — May 26, 2010 — source: 0154-01254.md
Post by: satoshi on May 26, 2010, 06:51:04 PM
Quote from: Xunie on May 26, 2010, 12:50:04 AM
Can’t we force a user to use a new address for receiving
payments?
Every time a payment is received display another Bitcoin address in
the address bar. (only transactions via Bitcoin addresses, NOT IPs of
course, since that’d be useless, right?)
The actual key would still be kept to ensure that the user would
still receive payments of people sending to the same address.
This is on my list. I will soon make the “Your Bitcoin Address:”
window automatically change whenever you receive anything to the address
displayed.
I’m also recommending this approach for the implementation of web
apps. I just posted some sample code showing a suggested way of
implementing this.
Versions on SVN since 0.2.4 already have a “New…” button next to the
address bar to encourage changing it manually too.
@theymos: If
nothing else, we can fall back on that solution in the future.
Bitcoin Forum post — May 26, 2010 — source: 0145-01256.md
Post by: satoshi on May 26, 2010, 08:09:34 PM
Quote from: molybdenum on May 22, 2010, 06:44:20 PM
An optional parameter to specify the minimum number of blocks after
that transaction (getallreceived 1 for current behavior, or just
getallreceived, getallreceived 5 for the paranoid, getallreceived 0 for
instant confirms)?
Yeah, that actually is what it is. getallreceived 0 should do what
you want. (now it’s renamed to listreceivedbyaddress 0) The default is 1
confirmation, but I think in reality most digital goods and services can
be 0 confirmations. Like you say, if you need more than 0 confirmations,
you could show two numbers, unconfirmed and available balance, so they
immediately see their transaction went through.
listreceivedbyaddress [minconf=1] [includeempty=false] [minconf] is
the minimum number of confirmations before payments are included.
[includeempty] whether to include addresses that haven’t received any
payments. Returns an array of objects containing: “address” : receiving
address “label” : the label of the receiving address “amount” : total
amount received by the address “confirmations” : number of confirmations
of the most recent transaction included
or listreceivedbylabel if you’re labelling addresses with their
username.
So far I’ve concentrated on functions for web merchants, not so much
on stuff for remote management of headless coin generators yet.
Bitcoin Forum post — May 26, 2010 — source: 0153-01258.md
Post by: satoshi on May 26, 2010, 08:34:34 PM
It does in fact download 500 blocks at a time, then the counter
counts one at a time as it verifies the blocks.
The advantage of letting bitcoin download and verify the blocks is
that you do not have to trust the person you’re downloading them from.
If you downloaded the blk*.dat files from some site, you would have to
trust that site, since you would be accepting the data without verifying
it yourself. If you’re copying blk*.dat from another computer of yours,
that should be fine.
How long is the initial block download taking for you?
Bitcoin Forum post — June 02, 2010 — source: 0158-01322.md
Post by: satoshi on June 02, 2010, 06:18:15 PM
The current sending by IP is not very useful: it connects to the IP,
so you’d like to use TOR for anonymity, but then it can totally be
eavesdropped and man-in-the-middled.
The future plan for sending to an IP is to make it a bitcoin address
plus IP, like:
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h1.2.3.4
or
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4hdomain.com
I need suggestions for the separator character. “:” is a candidate,
but IPv6 has : in it and that might get confusing. Something that’s
allowed in url parameters would be nice.
I want to use SSL for the connection, using the bitcoin address’
public key as the cert. You would be certain you’re connected to who you
thought, and safely encrypted. The bitcoin address would not be used for
the transaction, only for authentication. A new generated bitcoin
address would be sent through the SSL connection.
Since it’s authenticated, it would then be safe to allow the IP
address to be a domain name. Some care taken that if a proxy is used, it
uses socks4a instead of DNS lookup.
Bitcoin Forum post — June 02, 2010 — source: 0043-01323.md
Post by: satoshi on June 02, 2010, 06:45:38 PM
That’s a good idea. I’m not sure where exactly to fit that in, but it
could certainly calculate the expected average time between blocks
generated, and then people would know what to expect.
Every node and each processor has a different public key in its
block, so they’re guaranteed to be scanning different territory.
Whenever the 32-bit nonce starts over at 1, bnExtraNonce gets
incremented, which is an arbitrary precision integer.
Bitcoin Forum post — June 14, 2010 — source: 0084-01579.md
Post by: satoshi on June 14, 2010, 06:13:21 PM
Last edit: June 14, 2010, 06:48:17 PM by satoshi
Bitcoin has its own distributed address directory using the “addr”
message. It’s about time we coded in a list of the current long running
static nodes to seed from. I can add code so new nodes do not
preferentially stay connected to the seed nodes, just connect and get
the list, so it won’t be a burden on them.
What do you think, should I go ahead with adding the seeds?
It’ll still try IRC first. The IRC has the advantage that it lists
nodes that are currently online, since they have to stay connected to
stay on the list, but the disadvantage that it’s a single point of
failure. The “addr” system has no single point of failure, but can only
tell you what nodes have recently been seen, so it takes a little longer
to get connected since some of the nodes you try have gone offline. The
combination of the two gets us the best of both worlds and more total
robustness.
Is there anyone who wants to volunteer to run an IRC server in case
freenode gets tired of us?
Bitcoin Forum post — June 14, 2010 — source: 0158-01582.md
Post by: satoshi on June 14, 2010, 07:53:44 PM
SirArthur has a good point about the normal online merchant case,
which is what the send-by-IP option is more suited to. This is the case
where the merchant will have a server on a static IP and their own
domain name and SSL cert.
Instead of connecting by IP, we can connect to a domain name by SSL,
using the existing CA infrastructure to authenticate that you’re
connected to the owner of that domain.
The user would send to domain.com (or www.domain.com is ok too). That
would be very natural and users could see and verify that what they
entered is who they intend to pay.
The SSL also makes it safe for TOR users.
Problem is, I think merchants would still prefer to use bitcoin
addresses to be certain they know what the payment is for. You simply
cannot count on users to enter the right thing in the comment fields to
identify the transaction. It would only approach practical if we had a
mailto style link that prepopulates the comment field with the order
number, but then the link could just as well be a bitcoin address.
Just having an open bitcoin server at domain.com that users could
send unidentified payments to would be too much of a liability. Regular
users aren’t used to the idea of having to identify the payment.
Merchants would get too many blank payments followed by “I paid you,
where’s my stuff?!” a week later.
The payment sequence does have a step where the receiver verifies the
order before accepting it. It can reject the payment and return an error
message if it doesn’t contain a valid order number. That would require a
difficult level of integration of custom code with the bitcoin server
though.
Bitcoin Forum post — June 14, 2010 — source: 0191-01585.md
Post by: satoshi on June 14, 2010, 08:39:50 PM
SHA-256 is very strong. It’s not like the incremental step from MD5
to SHA1. It can last several decades unless there’s some massive
breakthrough attack.
If SHA-256 became completely broken, I think we could come to some
agreement about what the honest block chain was before the trouble
started, lock that in and continue from there with a new hash
function.
If the hash breakdown came gradually, we could transition to a new
hash in an orderly way. The software would be programmed to start using
a new hash after a certain block number. Everyone would have to upgrade
by that time. The software could save the new hash of all the old blocks
to make sure a different block with the same old hash can’t be used.
Re: What is the incentive to collect transactions?
Bitcoin Forum post — June 15, 2010 — source: 0165-01595.md
Post by: satoshi on June 15, 2010, 11:41:29 PM
Quote from: theymos on June 05, 2010, 04:26:09 PM
Adding transactions to the block you’re working on will slow down
your generation rate
The premise is false. Adding more transactions to the block you’re
working on does NOT slow down your generation rate. When generate is
scanning hashes, it only hashes the header of the block, which is
constant size. The header contains a hash of the transactions (the
Merkle root) and is only updated occasionally.
If necessary I can write code to make nodes prefer not to use a block
if it doesn’t contain enough of the transactions they know about. A
discouraged block would almost always fail to be included in the main
chain, but would be accepted if it did get in. I doubt this will be
necessary, since there’s no real advantage for nodes not to include all
transactions.
But as long as the link is already doing the typing for you, I don’t
see much benefit in using a domain address instead of bitcoin address.
With a bitcoin address, the user can’t send an unidentified payment.
They can’t send payment until they’ve been given a correct bitcoin
address to send to.
What would be nice about sending by domain is you could visually
verify who it’s going to.
A more crucial issue is what if the browser isn’t allowed to connect
to 127.0.0.1:
Bitcoin Forum post — June 17, 2010 — source: 0184-01609.md
Post by: satoshi on June 17, 2010, 05:07:56 PM
I’m working on getting version 0.3 released as soon as I can. Just a
last few things left to do. It’s been a long time since 0.2 and we need
to get a prebuilt bitcoind with command line and JSON-RPC available.
This time we’ll have both 32-bit and 64-bit linux binaries, and Laszlo
is going to build a Mac OSX release. Plus, we’ll include the German,
Dutch and Italian translations by DataWraith, Xunie and Joozero (thanks
you guys!).
Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
Bitcoin Forum post — June 17, 2010 — source: 0195-01611.md
Post by: satoshi on June 17, 2010, 06:46:08 PM
The nature of Bitcoin is such that once version 0.1 was released, the
core design was set in stone for the rest of its lifetime. Because of
that, I wanted to design it to support every possible transaction type I
could think of. The problem was, each thing required special support
code and data fields whether it was used or not, and only covered one
special case at a time. It would have been an explosion of special
cases. The solution was script, which generalizes the problem so
transacting parties can describe their transaction as a predicate that
the node network evaluates. The nodes only need to understand the
transaction to the extent of evaluating whether the sender’s conditions
are met.
The script is actually a predicate. It’s just an equation that
evaluates to true or false. Predicate is a long and unfamiliar word so I
called it script.
The receiver of a payment does a template match on the script.
Currently, receivers only accept two templates: direct payment and
bitcoin address. Future versions can add templates for more transaction
types and nodes running that version or higher will be able to receive
them. All versions of nodes in the network can verify and process any
new transactions into blocks, even though they may not know how to read
them.
The design supports a tremendous variety of possible transaction
types that I designed years ago. Escrow transactions, bonded contracts,
third party arbitration, multi-party signature, etc. If Bitcoin catches
on in a big way, these are things we’ll want to explore in the future,
but they all had to be designed at the beginning to make sure they would
be possible later.
I don’t believe a second, compatible implementation of Bitcoin will
ever be a good idea. So much of the design depends on all nodes getting
exactly identical results in lockstep that a second implementation would
be a menace to the network. The MIT license is compatible with all other
licenses and commercial uses, so there is no need to rewrite it from a
licensing standpoint.
Re: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY CHECKSIG
Bitcoin Forum post — June 18, 2010 — source: 0195-01617.md
Post by: satoshi on June 18, 2010, 04:17:14 PM
A second version would be a massive development and maintenance
hassle for me. It’s hard enough maintaining backward compatibility while
upgrading the network without a second version locking things in. If the
second version screwed up, the user experience would reflect badly on
both, although it would at least reinforce to users the importance of
staying with the official version. If someone was getting ready to fork
a second version, I would have to air a lot of disclaimers about the
risks of using a minority version. This is a design where the majority
version wins if there’s any disagreement, and that can be pretty ugly
for the minority version and I’d rather not go into it, and I don’t have
to as long as there’s only one version.
I know, most developers don’t like their software forked, but I have
real technical reasons in this case.
Quote from: gavinandresen on June 17, 2010, 07:58:14 PM
I admire the flexibility of the scripts-in-a-transaction scheme, but
my evil little mind immediately starts to think of ways I might abuse
it. I could encode all sorts of interesting information in the TxOut
script, and if non-hacked clients validated-and-then-ignored those
transactions it would be a useful covert broadcast communication
channel.
That’s a cool feature until it gets popular and somebody decides it
would be fun to flood the payment network with millions of transactions
to transfer the latest Lady Gaga video to all their friends…
That’s one of the reasons for transaction fees. There are other
things we can do if necessary.
Quote from: laszlo on June 17, 2010, 06:50:31 PM
How long have you been working on this design Satoshi? It seems very
well thought out, not the kind of thing you just sit down and code up
without doing a lot of brainstorming and discussion on it first.
Everyone has the obvious questions looking for holes in it but it is
holding up well :)
Since 2007. At some point I became convinced there was a way to do
this without any trust required at all and couldn’t resist to keep
thinking about it. Much more of the work was designing than coding.
Fortunately, so far all the issues raised have been things I
previously considered and planned for.
Bitcoin Forum post — June 18, 2010 — source: 0084-01619.md
Post by: satoshi on June 18, 2010, 05:28:18 PM
The SVN version now uses IRC first and if that fails it falls back to
a hardcoded list of seed nodes. There are enough seed nodes now that
many of them should still be up by the time of the next release. It only
briefly connects to a seed node to get the address list and then
disconnects, so your connections drop back to zero for while. At that
point, be patient. It’s only slow to get connected the first time.
This means TOR users won’t need to -addnode anymore, it’ll get
connected automatically.
Re: Get 5 free bitcoins from freebitcoins.appspot.com
Bitcoin Forum post — June 18, 2010 — source: 0183-01620.md
Post by: satoshi on June 18, 2010, 11:08:34 PM
Excellent choice of a first project, nice work. I had planned to do
this exact thing if someone else didn’t do it, so when it gets too hard
for mortals to generate 50BTC, new users could get some coins to play
with right away. Donations should be able to keep it filled. The display
showing the balance in the dispenser encourages people to top it up.
You should put a donation bitcoin address on the page for those who
want to add funds to it, which ideally should update to a new address
whenever it receives something.
Bitcoin Forum post — June 21, 2010 — source: 0149-01646.md
Post by: satoshi on June 21, 2010, 05:20:21 PM
Quote from: NewLibertyStandard on May 23, 2010, 04:28:12 PM
Bitcoin looks ugly in Ubuntu’s new default theme. It seems that some,
but not all of the theme settings are being picked up. The unselected
file menu should have light text with a dark background, but it
incorrectly has light text with a light background. They’re similar
enough that it’s unreadable on my display. It should be fixed before the
next stable release.
This is now fixed in the SVN version.
Menu bar default color.
Balance bar not a different color.
Background behind bitcoin address and balance now the same color
as toolbar.
I checked all the standard themes and it seems reasonable with all of
them.
Ubuntu minimize,maximize,close buttons to the right:
gconf-editor
apps->metacity->general
button_layout=menu:minimize,maximize,close
They’ve got it awfully buried considering 9 out of 10 users are used
to having it on the right.
Bitcoin Forum post — June 21, 2010 — source: 0198-01647.md
Post by: satoshi on June 21, 2010, 05:48:26 PM
Lost coins only make everyone else’s coins worth slightly more. Think
of it as a donation to everyone.
Quote from: laszlo on June 21, 2010, 01:54:29 PM
I wonder though, is there a point where the difficulty of generating
a new coinbase is so high that it would make more sense to try to
recover keys for lost coins or steal other people’s coins instead? The
difficulty of that is really high so for now it makes a lot more sense
to generate but I just wonder what the real figures are.. would that
ever become more productive? Maybe Satoshi can address this..
Computers have to get about 2^200 times faster before that starts to
be a problem. Someone with lots of compute power could make more money
by generating than by trying to steal.
Bitcoin Forum post — June 22, 2010 — source: 0149-01653.md
Post by: satoshi on June 22, 2010, 03:45:56 AM
Last edit: June 22, 2010, 04:05:04 AM by satoshi
On Ubuntu 10.04 it wouldn’t remove the taskbar button cleanly, so I
made it leave it there.
But now that you mention it, it’s probably better to have the
feature, even if it’s messy, than not to have it, though it may confuse
a few people when the taskbar button temporarily stays around but
disappears if you click on it.
Re: How fast do the fastest computers generate bitcoins?
Bitcoin Forum post — June 22, 2010 — source: 0197-01656.md
Post by: satoshi on June 22, 2010, 04:35:26 AM
I’ve noticed that hashing performance doesn’t vary as much between
CPUs as you’d expect. Compared to an old CPU, a newer CPU doesn’t show
as much of a speedup at hashing as it does on general benchmarks.
I guess recent CPU optimizations must have concentrated on things
like I/O and branch prediction. Most programs are a bunch of memory
access, comparisons and branching, they rarely get down to cranking away
at maths for very long.
The latest SVN version has a khash/s display. Around 400 khash/s per
processor is typical.
Bitcoin Forum post — June 22, 2010 — source: 0149-01668.md
Post by: satoshi on June 22, 2010, 04:39:43 PM
It’s too late now for feature changes to 0.3, but I’ll add that to
the post-0.3 to do list. I never would have noticed that if you hadn’t
pointed it out.
Bitcoin Forum post — June 22, 2010 — source: 0043-01669.md
Post by: satoshi on June 22, 2010, 04:51:14 PM
Agree. Certainly too trivial to clutter the user’s attention
with.
I changed it to every 30 minutes.
If I increased it to every 10 minutes, it would still be a small
enough presence in the log file. Question is whether that would be more
output than the user wants when they grep.
Bitcoin Forum post — June 22, 2010 — source: 0199-01670.md
Post by: satoshi on June 22, 2010, 05:02:07 PM
Quote from: lachesis on June 22, 2010, 06:20:02 AM
It would be nice if the listtransactions RPC method were finished
before the next release, though.
My fear is too many programmers would latch onto that for checking
for received payments. It can never be reliable that way. The
list/getreceivedbyaddress/label functions are the only way to do it
reliably.
We shouldn’t delay forever until every possible feature is done.
There’s always going to be one more thing to do.
Bitcoin Forum post — June 22, 2010 — source: 0199-01671.md
Post by: satoshi on June 22, 2010, 05:37:08 PM
Last edit: June 26, 2010, 12:02:18 AM by satoshi
Here’s RC1 for windows for testing:
(removed, see RC2 below)
Please only download this if you’re going to test and report back
whether everything seems fine or not. Make sure to look through the
files in “c:files”
Bitcoin Forum post — June 22, 2010 — source: 0199-01679.md
Post by: satoshi on June 22, 2010, 07:46:23 PM
You figured it out faster than I could post a reply. :)
It looks like laszlo’s build of Berkeley DB has database/log.* files
that are not compatible with ours. The .dat files are fine, their format
shouldn’t ever change. All data is stored in the .dat files. All your
own data is stored in wallet.dat. If you had waited for it to redownload
the block chain, your missing transactions and generateds would have
appeared as the block chain reached the point where those transactions
were recorded.
When you copied the directory except log.0000000002, that’s the best
solution. You should be good now.
The database/log.* files only contain temporary database data. If you
exited bitcoin normally the last time, not exited by forced terminating
it or crashing, then the database/log.* files can normally be deleted
safely. They’re only used so that if the database is in the middle of a
transaction when the computer crashes or the program is killed or
crashes, then it could recover without losing data.
Please keep running v0.3 if at all possible, don’t go back to
v0.2.10.
Anyone else who hits this problem, move the database* files somewhere
else. (if it works fine after that, you can delete them later)
I’m reluctant to make the installer delete or move those files. If
the previous run was stopped by crashing or killed, that would be the
wrong thing to do.
Bitcoin Forum post — June 22, 2010 — source: 0199-01686.md
Post by: satoshi on June 22, 2010, 10:23:39 PM
Laszlo figured out that enabling some more optimisation increased
performance about 20%, so 0.3 hashes 20% faster than 0.2.0, but I assume
he used that in his own build.
30khash increase to what total rate? (to figure the % increase)
Bitcoin Forum post — June 24, 2010 — source: 0199-01748.md
Post by: satoshi on June 24, 2010, 05:40:05 PM
Last edit: June 26, 2010, 12:14:27 AM by satoshi
Here’s RC1 for linux for testing:
(link removed, see below)
It contains both 32-bit and 64-bit binaries.
Recent changes:
build-unix.txt:
- Added instructions for building wxBase, which is needed to compile
bitcoind.
- The package libboost-dev doesn’t install anything anymore, you need
to get libboost-all-dev.
- Updated version numbers.
makefile.unix:
- The libboost libraries have removed the “-mt” from their filenames
in 1.40. If you’re compiling with Boost 1.38 or lower, like on Ubuntu
Karmic, you would need to change it back to boost_system-mt and
boost_filesystem-mt.
Bitcoin Forum post — June 25, 2010 — source: 0199-01760.md
Post by: satoshi on June 25, 2010, 02:17:41 AM
Last edit: June 25, 2010, 03:00:14 AM by satoshi
I don’t know. Maybe someone with more Linux experience knows how to
install the library it needs.
I built it on Ubuntu 10.04. I hope that wasn’t a mistake. Maybe it
should have been built on an older version for more backward
compatibility. Is this a problem on Linux, that if you build on the
latest version, then it has trouble working on older versions? Is there
any way I can downgrade to an older version of GCC on 10.04?
The 64-bit version shouldn’t be any faster than the 32-bit version,
but it would be great if someone could do a side-by-side comparison of
the two linux versions and check. SHA-256 is a 32-bit algorithm and
nothing in BitcoinMiner uses 64-bit at all.
We don’t need to bother with a 64-bit version for Windows. 32-bit
programs work on all versions of Windows. It’s not like Linux where the
64-bit OS wants 64-bit programs.
I’m also curious if it’s a little faster on linux than windows.
Bitcoin Forum post — June 25, 2010 — source: 0199-01769.md
Post by: satoshi on June 25, 2010, 02:10:06 PM
Thanks virtualcoin, that’s a perfect comparison.
The 8% speedup from 32-bit Windows (2310k) to 32-bit Linux (2500k) is
probably from the newer version of GCC on Linux (4.4.3 vs 3.4.5).
The 15% speedup from 32-bit to 64-bit Linux is more of a mystery. The
code is completely 32-bit.
Hmm, I think the 8 extra registers added by x86-64 must be what’s
helping. That would make a significant difference to SHA if it could
hold most of the 16 state variables in registers.
Bitcoin Forum post — June 25, 2010 — source: 0084-01781.md
Post by: satoshi on June 25, 2010, 10:40:47 PM
Quote from: laszlo on June 14, 2010, 06:30:58 PM
I run an IRC server you can use, it’s fairly stable but it’s not on
redundant connections or anything. It is only two servers right now but
we don’t mess with it or anything, it just runs.
Bitcoin Forum post — June 26, 2010 — source: 0199-01800.md
Post by: satoshi on June 26, 2010, 03:10:10 PM
The first panel of the status bar is shared with the help description
of menu items as you hover over them. Since all our menu item
descriptions are blank, it replaces it with blank when you’re hovering
in a menu.
Bitcoin Forum post — June 26, 2010 — source: 0177-01814.md
Post by: satoshi on June 26, 2010, 08:58:26 PM
Quote from: sirius-m on June 10, 2010, 01:51:16 PM
You can of course use services like vekja.net or mybitcoin.com on a
mobile browser, depositing money there to the extent you trust them.
I think that’s the best option right now. Like cash, you don’t keep
your entire net worth in your pocket, just walking around money for
incidental expenses.
They could make a smaller version of the site optimized for mobile.
If there was an app, it could be a front end to one of those, with the
main feature being QR-code reader, or maybe there’s already a universal
QR-code reading app that web sites can be designed to accept scans
from.
If there was an iPhone app that was just a front end for vekja or
mybitcoin, not a big involved P2P, would apple approve it and if not, on
what basis? It could always be an Android app instead. An app is not
really necessary though, just a mobile sized website.
A web interface to your own Bitcoin server at home wouldn’t be a
solution for everyone. Most users don’t have a static IP, and it’s too
much trouble to set up port forwarding.
Bitcoin Forum post — June 26, 2010 — source: 0206-01816.md
Post by: satoshi on June 26, 2010, 09:39:52 PM
Many big ISPs give you a new IP every time you connect, usually in
the same class B (a.b.?.?). Maybe you should have a minimum time between
payments per class-B.
If you can’t solve the problem, you can always keep lowering the
amount of bitcoins given until it’s manageable, and always require
captcha.
Bitcoin Forum post — June 27, 2010 — source: 0217-01827.md
Post by: satoshi on June 27, 2010, 12:43:50 PM
But 1.0 sounds like the first release. For some things newness is a
virtue but for this type of software, maturity and stability are
important. I don’t want to put my money in something that’s 1.0. 1.0
might be more interesting for a moment, but after that we’re still 1.0
and everyone who comes along thinks we just started. This is the third
major release and 1.3 reflects that development history. (0.1, 0.2,
1.3)
Bitcoin Forum post — June 27, 2010 — source: 0218-01828.md
Post by: satoshi on June 27, 2010, 01:02:38 PM
Welcome, Harry.
I hadn’t thought about starting out using bitcoind without using
bitcoin first. I guess for now, this thread serves as the tutorial.
The focus for bitcoind so far has been more on backend support for
websites. There’s demand for things that would be nice for adminning
headless generators like listgenerated. For the moment, you can grep the
debug.log file for “generated” and “hashmeter” for some feedback.
Generated blocks take about 24 hours before they’re credited to your
balance.
Bitcoin Forum post — June 27, 2010 — source: 0199-01834.md
Post by: satoshi on June 27, 2010, 03:30:13 PM
MinGW still only has good old stable 3.4.5. There’s not much reason
for them to update it.
When I looked at the 3.4.5 compiled SHA disassembly, I couldn’t see
any room for improvement at all. I can’t imagine how 8% more could be
squeezed out of it. Is it possible Windows could have 8% more overhead?
Not making system calls or anything, just plain busy computational code,
could task switching and other housekeeping operations take away that
much?
If SHA-256 became completely broken, I think we could come to some
agreement about what the honest block chain was before the trouble
started, lock that in and continue from there with a new hash
function.
If the hash breakdown came gradually, we could transition to a new
hash in an orderly way. The software would be programmed to start using
a new hash after a certain block number. Everyone would have to upgrade
by that time. The software could save the new hash of all the old blocks
to make sure a different block with the same old hash can’t be used.
Bitcoin Forum post — July 02, 2010 — source: 0223-01924.md
Post by: satoshi on July 02, 2010, 07:21:36 PM
Thanks for the feedback on this.
One thing we could do is lower the outbound connections from 15 to 10
or maybe even 5. The choice of 15 was arbitrary. It just needs to be
enough for redundancy and fast exponential propagation of messages. 10
would still be plenty. 5 should be fine. 10 is good as a nice round
number so users can see that it stopped intentionally.
It would help to implement UPnP so there would be more inbound
accepting nodes. Your number of connections is the ratio of inbound
accepting nodes to out-only times 15. We need to encourage more people
to accept inbound connections.
I will implement a feature to stop accepting inbound connections once
you hit a certain number.
Which version are you running?
Anyone know how many connections typical P2P software like BitTorrent
can get up to?
Other than the version number change, which included changes in
readme.txt and setup.nsi, I reduced the maximum number of outbound
connections from 15 to 8 so nodes that accept inbound don’t get too many
connections. 15 was a lot more than needed. 8 is still plenty for
redundancy.
Bitcoin Forum post — July 05, 2010 — source: 0234-01976.md
Post by: satoshi on July 05, 2010, 09:31:14 PM
Last edit: August 07, 2010, 04:50:57 PM by satoshi
BTW, I did come to my senses after that brief bout with 1.3, this
release is still going to be 0.3 beta not 1.0.
I really appreciate the effort, but there are a lot of problems.
We don’t want to lead with “anonymous”. (I’ve been meaning to edit
the homepage)
“The developers expect that this will result in a
stable-with-respect-to-energy currency outside the reach of any
government.” -- I am definitely not making an such taunt or
assertion.
It’s not stable-with-respect-to-energy. There was a discussion on
this. It’s not tied to the cost of energy. NLS’s estimate based on
energy was a good estimated starting point, but market forces will
increasingly dominate.
Sorry to be a wet blanket. Writing a description for this thing for
general audiences is bloody hard. There’s nothing to relate it to.
Bitcoin Forum post — July 06, 2010 — source: 0238-02004.md
Post by: satoshi on July 06, 2010, 06:32:35 PM
Last edit: July 06, 2010, 10:12:01 PM by satoshi
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.
What’s new:
- Command line and JSON-RPC control
- Includes a daemon version without GUI
- Transaction filter tabs
- 20% faster hashing
- Hashmeter performance display
- Mac OS X version (thanks to Laszlo)
- German, Dutch and Italian translations (thanks to DataWraith, Xunie
and Joozero)
Bitcoin Forum post — July 07, 2010 — source: 0084-02010.md
Post by: satoshi on July 07, 2010, 01:31:07 AM
Everybody needs to connect to the same IRC server and channel so they
can find each other.
Quote from: Vasiliev on June 25, 2010, 11:50:15 PM
You may want to leave Freenode in as a fallback server – if his
server doesn’t work, use Freenode’s.
It might not be good if we suddenly rushed freenode with a ton of
users all at once.
The fallback is our own seed system.
irc.lfnet.org is pretty old and has impressive uptime. I think it’s
going to be fine.
We could take IRC out at some point if we want, but I’d rather ease
into it and just test our own seed system as a backup for now, and I
really like the complementary redundant attributes of the two different
systems.
Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username
Bitcoin Forum post — July 08, 2010 — source: 0246-02068.md
Post by: satoshi on July 08, 2010, 06:24:19 PM
Thanks for finding that. We switched from ANSI in 0.2 to UTF-8 in
version 0.3, so it must be related to that.
Just to confirm, if you log in with the non-latin character username,
not having an appdata/Bitcoin directory yet, and run Bitcoin and let it
create the database from scratch, does it work or not?
Bitcoin Forum post — July 08, 2010 — source: 0241-02071.md
Post by: satoshi on July 08, 2010, 07:12:00 PM
Last edit: July 08, 2010, 07:27:42 PM by satoshi
It’s hard to imagine the Internet getting segmented airtight. It
would have to be a country deliberately and totally cutting itself off
from the rest of the world.
Any node with access to both sides would automatically flow the block
chain over, such as someone getting around the blockade with a dial-up
modem or sat-phone. It would only take one node to do it. Anyone who
wants to keep doing business would be motivated.
If the network is segmented and then recombines, any transactions in
the shorter fork that were not also in the longer fork are released into
the transaction pool again and are eligible to get into future blocks.
Their number of confirmations would start over.
If anyone took advantage of the segmentation to double-spend, such
that there are different spends of the same money on each side, then the
double-spends in the shorter fork lose out and go to 0/unconfirmed and
stay that way.
It wouldn’t be easy to take advantage of the segmentation to
double-spend. If it’s impossible to communicate from one side to the
other, how are you going to put a spend on each side? If there is a way,
then probably someone else is also using it to flow the block chain
over.
You would usually know whether you’re in the smaller segment. For
example, if your country cuts itself off from the rest of the world, the
rest of the world is the larger segment. If you’re in the smaller
segment, you should assume nothing is confirmed.
Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username
Bitcoin Forum post — July 09, 2010 — source: 0246-02077.md
Post by: satoshi on July 09, 2010, 03:01:35 AM
I think I see where the problem is. Coincidentally, I recently coded
a replacement for the function in question which should fix it. It’s not
enabled yet, but in the SVN version it prints a debug message in
debug.log showing the new directory value and old value for
comparison.
Re: BTC Vulnerability? (Massive Attack against BTC system. Is it really?)
Bitcoin Forum post — July 09, 2010 — source: 0242-02078.md
Post by: satoshi on July 09, 2010, 03:28:46 AM
What the OP described is called “cornering the market”. When someone
tries to buy all the world’s supply of a scarce asset, the more they buy
the higher the price goes. At some point, it gets too expensive for them
to buy any more. It’s great for the people who owned it beforehand
because they get to sell it to the corner at crazy high prices. As the
price keeps going up and up, some people keep holding out for yet higher
prices and refuse to sell.
The Hunt brothers famously bankrupted themselves trying to corner the
silver market in 1979:
“Brothers Nelson Bunker Hunt and Herbert Hunt attempted to corner the
world silver markets in the late 1970s and early 1980s, at one stage
holding the rights to more than half of the world’s deliverable
silver.[1] During Hunt’s accumulation of the precious metal silver
prices rose from $11 an ounce in September 1979 to nearly $50 an ounce
in January 1980.[2] Silver prices ultimately collapsed to below $11 an
ounce two months later,[2] much of the fall on a single day now known as
Silver Thursday, due to changes made to exchange rules regarding the
purchase of commodities on margin.[3]”
Re: bitcoin 0.3 win64 - broken access to APPDATA if non-latin characters in username
Bitcoin Forum post — July 09, 2010 — source: 0246-02092.md
Post by: satoshi on July 09, 2010, 03:37:05 PM
I tested this with a non-lower-ASCII account name on XP and confirmed
the bug, then tested that the new GetDefaultDataDir fixed it. This
change is revision 102 of the SVN.
Bitcoin Forum post — July 10, 2010 — source: 0240-02132.md
Post by: satoshi on July 10, 2010, 12:58:02 PM
I’ll start thinking about how to do this.
At the moment, you can kind of use -connect. You can use -connect to
make it connect to local computers on your LAN, like
-connect=192.168.0.100. If you start it out blank and don’t let it
connect to the main network, the difficulty is still at the original low
difficulty. If you’ve port-forwarded though, then outside nodes might
still connect inward to you.
With -connect it still uses IRC, do you think it shouldn’t get on IRC
when you’re telling it to only connect to specific nodes with -connect?
The main scenario for -connect is where you have a server farm, with two
connected to the network and the rest connected to the first two. In
that case, you wouldn’t want the -connect computers on IRC.
Bitcoin Forum post — July 10, 2010 — source: 0202-02133.md
Post by: satoshi on July 10, 2010, 01:36:17 PM
Quote from: llama on July 01, 2010, 10:21:47 PM
However, if something happened and the signatures were compromised
(perhaps integer factorization is solved, quantum computers?), then even
agreeing upon the last valid block would be worthless.
True, if it happened suddenly. If it happens gradually, we can still
transition to something stronger. When you run the upgraded software for
the first time, it would re-sign all your money with the new stronger
signature algorithm. (by creating a transaction sending the money to
yourself with the stronger sig)
Bitcoin Forum post — July 14, 2010 — source: 0323-02867.md
Post by: satoshi on July 14, 2010, 04:22:03 PM
So that was responsible for keeping blocks from downloading?
The link: “Win32 CPU Cycles vs ‘Live Protection’ Engines”
For BitcoinFX, Live Protection was keeping it from getting CPU for
generating coins. You said your friend was getting 1400-1600 khash/s, so
it was getting CPU. I guess Live Protection must have been blocking some
other part of the program then?
Bitcoin Forum post — July 14, 2010 — source: 0327-02871.md
Post by: satoshi on July 14, 2010, 04:29:39 PM
In Windows, you select the process in the task manager, right click,
Set Priority. Set it to BelowNormal or Low. That shouldn’t make a
difference though.
If you turn off Generate Coins, does the CPU usage go flat? That
would confirm that all the CPU time it’s taking is generate, which is
idle priority already.
It could be it’s slow just because you have too many things running
at once and you’re out of memory. When you switch from one thing to
another, it has to page it in from disk.
Bitcoin Forum post — July 14, 2010 — source: 0072-02886.md
Post by: satoshi on July 14, 2010, 05:38:31 PM
Laszlo corrected this, but unfortunately it was too late to make it
into 0.3.0. There will probably be a 0.3.1 soon though.
The problem is I used PRIO_MIN, I should have used PRIO_MAX for the
lowest priority. The OS isn’t supposed to let you increase priority, so
the PRIO_MIN ought to leave it at priority 0.
Bitcoin Forum post — July 14, 2010 — source: 0305-02895.md
Post by: satoshi on July 14, 2010, 06:02:28 PM
This is the second time I’ve seen this “Live Protection” problem
reported.
It must be blocking the program’s network communication. It sounds
like it’s allowing connections to be made, hence the 10 connections
shown, but not allowing any data to be sent or received on them.
We need to understand this problem better.
Can someone write some instructions on the wiki explaining how to
turn off or add an exclusion to Live Protection or whatever its full
proper name is.
Re: Runaway CPU usage for 64bit BitCoin (Linux Client)
Bitcoin Forum post — July 14, 2010 — source: 0299-02908.md
Post by: satoshi on July 14, 2010, 06:45:53 PM
After it initially tries incorrectly to set itself to the lowest
priority, the generate thread only changes its priority again
temporarily when it finds a block. When you’ve found a block, you should
want it to hurry up and broadcast it as soon a possible before someone
else finds one and makes yours invalid. The generate thread only changes
to higher priority for less than a second every few days.
There should be a 0.3.1 release for this soon. There are a few other
issues we need to look at fixing in 0.3.1 before making a release.
Quote from: knightmb on July 12, 2010, 10:39:13 PM
On a side note, I’ve tracked down the other GUI issue.
The “minimize to tray instead of taskbar” is what was eating up all
the CPU on my system. After I turned this off, the issue was resolved
with Runaway CPU.
This only seems to affect the 64 bit Client, as the 32 bit Clients I
have don’t seem to be affected by this.
I did notice on the 64 bit Client, what happens is, it spawns
multiple “tray” icons until X server finally kills over, so I guess I
should submit that as a bug to somewhere? ???
That’s interesting. I know the minimize to tray on Ubuntu is very
clunky, but I didn’t know it had a CPU peg problem too. Anyone else able
to reproduce this problem? We had this feature disabled on Linux before,
but then it seemed better to have the imperfect UI than to lose the
feature entirely. I’m thinking we should disable it again on Linux.
Re: Warning this block was not received by any other nodes
Bitcoin Forum post — July 14, 2010 — source: 0291-02913.md
Post by: satoshi on July 14, 2010, 06:56:29 PM
Microsoft Security Essentials Live Protection is blocking your
communication with the network. You have connections, which tricks
Bitcoin into thinking it’s connected, but they are silent because the
data is being blocked.
You need to make bitcoin.exe an excluded process in Live
Protection.
This is becoming a common problem. Someone should write this up in a
pegged thread.
The message “Warning: This block was not received by any other nodes”
occurs when Bitcoin broadcasts a block, but nobody confirms they
received it. The warning is there just for this kind of situation, where
for some reason you have connections, but they have gone dead and nobody
can hear you. Your block will never become valid because nobody received
it.
Bitcoin Forum post — July 14, 2010 — source: 0325-02935.md
Post by: satoshi on July 14, 2010, 08:25:06 PM
Quote from: knightmb on July 14, 2010, 07:17:43 PM
So if your computer was only 1% towards solving block 68000
This is a common point of confusion. There’s no such thing as being
1% towards solving a block. You don’t make progress towards solving it.
After working on it for 24 hours, your chances of solving it are equal
to what your chances were at the start or at any moment.
It’s like trying to flip 37 coins at once and have them all come up
heads. Each time you try, your chances of success are the same.
The RNG is the OpenSSL secure random number generator. On Windows
it’s seeded with the complete set of all hardware performance counters
since your computer started, on Linux it’s dev/random.
Bitcoin Forum post — July 14, 2010 — source: 0286-02947.md
Post by: satoshi on July 14, 2010, 09:10:52 PM
The design outlines a lightweight client that does not need the full
block chain. In the design PDF it’s called Simplified Payment
Verification. The lightweight client can send and receive transactions,
it just can’t generate blocks. It does not need to trust a node to
verify payments, it can still verify them itself.
The lightweight client is not implemented yet, but the plan is to
implement it when it’s needed. For now, everyone just runs a full
network node.
I anticipate there will never be more than 100K nodes, probably less.
It will reach an equilibrium where it’s not worth it for more nodes to
join in. The rest will be lightweight clients, which could be
millions.
At equilibrium size, many nodes will be server farms with one or two
network nodes that feed the rest of the farm over a LAN.
Re: Static Linux x86_64 bins for those having libcrypto troubles
Bitcoin Forum post — July 15, 2010 — source: 0326-03157.md
Post by: satoshi on July 15, 2010, 02:33:04 PM
We don’t even specify linking glibcxx_3.4.11, so gcc must
automatically link it behind the scenes. There’s probably a compiler
switch that would tell it to static link it. I’m not sure what the
licensing issues would be. Typically, compiler stuff is fully
redistributable.
Bitcoin Forum post — July 15, 2010 — source: 0327-03162.md
Post by: satoshi on July 15, 2010, 02:59:00 PM
Then all the CPU time is the generate thread, which definitely runs
at the lowest possible priority, idle priority. It’s normal that your
CPU meter is 100%. Since it’s idle priority, it won’t actually slow
anything else down, even though the CPU meter is 100%.
Bitcoin Forum post — July 15, 2010 — source: 0383-03198.md
Post by: satoshi on July 15, 2010, 05:05:54 PM
Last edit: July 16, 2010, 09:00:42 PM by satoshi
This is a bugfix maintenance release. It is now uploaded to
SourceForge. Mac OS X didn’t need any fixes so we don’t really need to
update it, 0.3.0 is still good.
The download links are on bitcoin.org
Changes:
- Added Portuguese translation by Tiago Faria
Windows
- Fix for 22DbRunRecoveryException if your username has non-ascii
characters in it
Linux
- Laszlo’s fix for lowering generate thread to lowest priority
- Fix for if you’re having trouble with libcrypto linkage
- Gavin Andresen’s implementation of “start on windowing system
startup” option
Bitcoin Forum post — July 15, 2010 — source: 0383-03221.md
Post by: satoshi on July 15, 2010, 05:56:43 PM
I don’t think you have a particular problem, I think your system is
laggy because you’re running a lot of things at once and hitting the
pagefile because memory is full. You confirmed when you shut off
generation that your CPU drops to 0%, so the CPU usage is definitely all
idle priority. There’s nothing in the 0.3.1 that would affect these
things.
Bitcoin Forum post — July 15, 2010 — source: 0151-03238.md
Post by: satoshi on July 15, 2010, 06:30:22 PM
Quote from: aidos on July 15, 2010, 12:49:11 AM
Ok here is the .po file for French. While I’m at it, I noted a couple
of issues:
1. The “About” box didn’t take the translation into account, it still
displays the english version to me, even though the rest of the software
is using the translated strings, and the .po file contains the
translation string of the “About” box message. Same problem with the
“Apply” button in the Settings window.
I need to give an updated .po file.
Quote from: aidos on July 15, 2010, 12:49:11 AM
2. If an transaction’s description in the list of transaction in the
main window contains a diacritical character (such as “éàèç”), it’s not
displayed. I suppose the string is not being properly handled as UTF8
somewhere.
OK, this must be a problem somewhere, I’ll have to take a look at it
or one of the other devs can.
Quote from: aidos on July 15, 2010, 12:49:11 AM
4. About the .po file :
- There are a few strings in the .po file that don’t needs
translation (ie: “Bitcoin”). Maybe those shouldn’t be inside _(“…”)
?
- Others shouldn’t be split. I can remember one message about
transaction fee where the string is split in two to insert the fee
value, where you could simply have put a %s. It makes the message harder
to translate as I had to go in the source to find exactly what was going
on.
- Some strings have whitespace at the end or start, which necessity
is very debatable, and it’s easy to miss in PoEdit.
Many of the strings are in code automatically generated from
uiproject.fbp where nothing can be done about these things. I have a
program I use to find all the spacing inconsistencies at the beginning
and ending of strings in your .po file and manually fix them up before I
upload them to SVN.
Bitcoin Forum post — July 15, 2010 — source: 0383-03295.md
Post by: satoshi on July 15, 2010, 09:40:34 PM
Quote from: knightmb on July 15, 2010, 07:37:10 PM
On Windows, the priority of the Coin Generation is still net for
normal. If you run BitCoin in Generate Coin mode, then load up something
to eat up all the CPU (like CPU hog for example: http://www.microtask.ca/cpuhog.html) you’ll see that
both BitCoin and CPU hog share the CPU 50/50 instead of CPU Hog taking
all the CPU and BitCoin running only on idle/low process. The khash/s is
also reduced in half, so further evidence that the threads are not
running in a lower than normal prioirty.
I was not able to reproduce this. I have dual-proc, so I ran two
memory hogs. Bitcoin got 0% of CPU according to the task manager. The
khash/sec meter stayed stuck because it couldn’t get any CPU to update
it.
Do you have dual-proc? Are you sure you weren’t running a single
processor hog?
Bitcoin Forum post — July 15, 2010 — source: 0383-03305.md
Post by: satoshi on July 15, 2010, 10:07:35 PM
Quote from: knightmb on July 15, 2010, 08:15:46 PM
On the Linux client (64 bit), the “minimize on close” will still
minimize to tray (causing X server hang after a short while by spawning
multiple tray icons).
I updated the first post with a link to rc2 for linux with the fix
for this. Please check that this is fixed for you. Thanks!
Re: "SetIcons(): icon bundle doesn't contain any suitable icon"
Bitcoin Forum post — July 15, 2010 — source: 0391-03308.md
Post by: satoshi on July 15, 2010, 10:18:26 PM
That’s surprising that we’ve never heard of that before now.
Maybe you’re the first person to ever run it on Vista :)
I have to guess it has something to do with your display color depth
selection. e.g. 8-bit, 16-bit, 24-bit, 32-bit, what is it? Do you have a
weird video card, display setup or running it on a tablet or mobile or
something?
Bitcoin Forum post — July 15, 2010 — source: 0383-03319.md
Post by: satoshi on July 15, 2010, 11:23:04 PM
Quote from: RHorning on July 15, 2010, 10:29:28 PM
I don’t see either happening, although it did get put into the
“Startup” folder. That is so Windows 95ish (just kidding….. Microsoft
has so screwed this up that it isn’t even funny). I would recommend the
registry settings for a number of reasons including the fact that most
software puts the startup in that location, even though I personally
find the startup folder to be more attractive and how most software on
Windows should behave.
It could go either way. The Startup folder has the advantage that the
end user can see it and manually remove it with the regular UI (not
regedit) if they already blew away the Bitcoin directory and its
uninstaller. Bitcoin will not relentlessly keep re-adding it if you
delete it manually.
OpenOffice is another example of something that puts its link in the
Startup folder.
Re: "SetIcons(): icon bundle doesn't contain any suitable icon"
Bitcoin Forum post — July 15, 2010 — source: 0391-03323.md
Post by: satoshi on July 15, 2010, 11:41:23 PM
Quote from: bdonlan on July 15, 2010, 11:27:14 PM
in 120DPI mode.
What is “120DPI mode”? Is that an actual setting somewhere? Sounds
like an obscure enough candidate. I suppose it needs twice the
resolution icon to fill the size of the upper left corner icon. Only one
size is provided.
It’s about to increase again in a few hours. It’s only been 3-4 days
since the last increase, so I expect it will increase by the max of 4
times, or very nearly the max. That would put it at 181.54.
The target time between adjustments is 14 days, 14/3.5 days = 4.0
times increase.
Bitcoin Forum post — July 16, 2010 — source: 0400-03492.md
Post by: satoshi on July 16, 2010, 02:52:04 PM
That’s the first time I’ve seen this error.
How many blocks do you have? (in the status bar)
You should move your blk*.dat files (in ~/.bitcoin) to another
directory and let it start over downloading the block chain again. If
you don’t mind, could you keep the old blk*.dat files for a little while
in case I need to look at them?
Bitcoin Forum post — July 16, 2010 — source: 0303-03499.md
Post by: satoshi on July 16, 2010, 03:01:33 PM
Bitcoin automatically rebroadcasts your transactions if it receives
new blocks that don’t contain them. It may take about an hour to get
rebroadcasted. It is relentless though. It will keep nagging the network
forever until your transaction gets into a block.
Bitcoin Forum post — July 16, 2010 — source: 0383-03505.md
Post by: satoshi on July 16, 2010, 03:09:59 PM
Because of all the dependencies that different systems don’t have.
It’s easier to just static link what we can. It doesn’t increase the
size by very much.
Bitcoin Forum post — July 16, 2010 — source: 0393-03510.md
Post by: satoshi on July 16, 2010, 03:37:00 PM
I like that in libraries for the external API’s, but you can probably
tell from the code that I’m not a fan of it for interior functions. Big
obligatory comment headers for each function space out the code and make
you hesitate about creating a small little function where the comment
header would be bigger than the function. They’re some trouble for
maintenance, as changes to the function then require duplicate changes
in the comment header. I like to keep code compact so you can see more
code on the screen at once.
To add them now at this point, what would be written would just be
what’s obvious from looking at the function.
The external API we have, in rpc.cpp, the usage documentation is in
the help string.
Bitcoin Forum post — July 16, 2010 — source: 0360-03520.md
Post by: satoshi on July 16, 2010, 04:13:53 PM
SHA256 is not like the step from 128 bit to 160 bit.
To use an analogy, it’s more like the step from 32-bit to 64-bit
address space. We quickly ran out of address space with 16-bit
computers, we ran out of address space with 32-bit computers at 4GB,
that doesn’t mean we’re going to run out again with 64-bit anytime
soon.
SHA256 is not going to be broken by Moore’s law computational
improvements in our lifetimes. If it’s going to get broken, it’ll be by
some breakthrough cracking method. An attack that could so thoroughly
vanquish SHA256 to bring it within computationally tractable range has a
good chance of clobbering SHA512 too.
If we see a weakness in SHA256 coming gradually, we can transition to
a new hash function after a certain block number. Everyone would have to
upgrade their software by that block number. The new software would keep
a new hash of all the old blocks to make sure they’re not replaced with
another block with the same old hash.
Bitcoin Forum post — July 16, 2010 — source: 0397-03524.md
Post by: satoshi on July 16, 2010, 04:47:14 PM
Many businesses are like that. For a car salesman, when will the next
customer walk in the door?
On the OP’s question, it’s a good feature, but the question is, how
would we word it so people don’t expect to get something after that
specific amount of time? “it said 7 days and I waited more than a week
and didn’t get anything!” Approx, average, but still they’re going to
think that way. It can’t be a whole sentence, unless we think of
somewhere else to put it, but where would that be? Suggestions?
The difficulty quadrupled a few minutes ago to 181.54. It’s going to
take typically about a week to generate now.
Bitcoin Forum post — July 16, 2010 — source: 0393-03534.md
Post by: satoshi on July 16, 2010, 05:15:47 PM
It’s in init.cpp.
It’s a wxWidgets app, so it doesn’t have a main() function. It may in
a little while, since I’m pretty close to making bitcoind build w/o
wxBase. (it’ll be in init.cpp)
Sorry about my choice of the filename “main.cpp”, another possible
name would have been “core.cpp”. It’s much too late to change. I still
prefer main.cpp.
We’re still in great need of sample code showing the recommended way
to use the JSON-RPC functions, like for a basic account system on a
typical storefront website. Using getreceivedbylabel using the username
as the label, changing to a new bitcoin address once the stored one for
that account gets used. I posted a sample code fragment on the forum
somewhere. (search on getreceivedbylabel or getnewaddress) The sample
code could be a plain vanilla bank site where you can deposit and send
payments.
Bitcoin Forum post — July 16, 2010 — source: 0383-03536.md
Post by: satoshi on July 16, 2010, 05:26:17 PM
Good point. If you’re going to have more than 8 LAN nodes connect to
one gateway node, then you’d better have the gateway node set up so it
can receive incoming connections. Otherwise, while the gateway node has
8 or more connections, it will not try to add any more outbound
connections. As the outside nodes you’re connected to come and go, it
doesn’t make new outbound connections to replace them. You’ll be fine if
you can accept incoming connections, then there will be plenty of others
connecting to you.
Bitcoin Forum post — July 16, 2010 — source: 0043-03537.md
Post by: satoshi on July 16, 2010, 05:29:28 PM
Yes, about 20 hours. (120 conf / 6 blocks per hour = 20 hours) That’s
the normal length of time before you can spend it. You know long before
that that you won one.
Bitcoin Forum post — July 16, 2010 — source: 0364-03559.md
Post by: satoshi on July 16, 2010, 06:23:04 PM
I’ve been trying to encourage someone to write and release some
sample Python code showing the recommended way to do the typical
accounting stuff, but to no avail. It would be nice if you didn’t have
to re-invent the wheel like you’re doing here. Search on getnewaddress
and you should find a thread where I gave a small fragment of sample
pseudocode.
Bitcoin Forum post — July 16, 2010 — source: 0043-03565.md
Post by: satoshi on July 16, 2010, 06:43:51 PM
Right, the difficulty adjustment is trying to keep it so the network
as a whole generates an average of 6 blocks per hour. The time for your
block to mature will always be around 20 hours.
The recent adjustment put us back to close to 6 blocks per hour
again.
There’s a site where you can see the time between blocks, and since
block 68545, it’s been more like 10 minutes per block:
Bitcoin Forum post — July 16, 2010 — source: 0417-03579.md
Post by: satoshi on July 16, 2010, 07:45:10 PM
We need someone to write sample code, preferably Python or Java,
showing the recommended way to use the JSON-RPC interface to create an
account system. Most sites that sell things will need something like
this. Someone who’s kept up on the JSON-RPC threads here should have
some idea how it should work.
When a user is logged in to their account, you show the bitcoin
address they can send to to add funds. Before showing it, you check if
it’s been used, if it has then you replace it with a new one
(getnewaddress ). You only need to keep the latest bitcoin
address for the account in your database. (I posted a sample code
fragment for this in an earlier thread somewhere, search on
getnewaddress)
You use getreceivedbylabel with the username as the label
to get the “credit” amount of the account. You need to keep a “debit”
amount in your database. The current balance of the account is (credit -
debit). When the user spends money, you increase debit.
If you’re requiring more than 0 confirmations, it’s nice if you show
the current balance (0 confirmations) and the available balance (1 or
more confirmations), so they can immediately see that their payment is
acknowledged. Not all sites need to wait for confirmations, so the dual
current & available should be optional. Most sites selling digital
goods are fine to accept 0 confirmations.
A nice sample app for this would be a simple bank site, which would
have the above, plus the option to send a payment to a bitcoin address.
The sample code should be the simplest possible with the minimum extra
stuff to make it a working site.
Bitcoin Forum post — July 16, 2010 — source: 0128-03605.md
Post by: satoshi on July 16, 2010, 10:20:09 PM
Quote from: hugolp on May 08, 2010, 10:38:51 AM
When I run bitcoin it becomes very sluggish, almost unusable. When I
stop bitcoin everything goes ok again. Its running Ubuntu desktop 10.04
amd64 using ia32libs and the binary in bitcoin 0.20 tarball.
0.3.1 fixes that, sets the generate threads to the lowest priority.
Download links are on the homepage now.
Bitcoin Forum post — July 17, 2010 — source: 0432-03769.md
Post by: satoshi on July 17, 2010, 04:06:12 PM
It must be a rounding error when getinfo converts to floating point
to return the JSON-RPC result. The only place where it uses floating
point to represent money is returning a value in JSON-RPC.
1.139999999999 is longer than bitcoin can internally represent.
internally, it could only be:
1.13999999 or
1.14000000
1.139999999999 is much much closer to 1.14000000 than 1.13999999, so
it must be 1.14000000.
The code is this:
(double)GetBalance() / (double)COIN.
(I can’t think of an easy way to fix it at the moment)
Bitcoin Forum post — July 17, 2010 — source: 0434-03770.md
Post by: satoshi on July 17, 2010, 04:27:39 PM
We should queue up a supply of pre-made addresses in the wallet to
use when a new address is needed. They aren’t very big, so it wouldn’t
hurt to have a lot of them. This would more generally cover the case
also where someone backs up, then requests a new address and receives a
big payment with it. Maybe there should be separate queues so one type
of demand on addresses doesn’t deplete it for the others.
The addresses would be created and stored in the normal place, but
also listed on a separate list of created-but-never-used addresses. When
an address is requested, the address at the front of the never-used
queue is handed out, and a new address is created and added to the
back.
There’s some kind of rescan in the block loading code that was made
to repair the case where someone copied their wallet.dat. I would need
to check that the rescan handles the case of rediscovering received
payments in blocks that were already received, but are forgotten because
the wallet was restored.
Bitcoin Forum post — July 17, 2010 — source: 0437-03807.md
Post by: satoshi on July 17, 2010, 09:35:51 PM
Last edit: July 17, 2010, 11:46:13 PM by satoshi
Download links available now on bitcoin.org. Everyone should upgrade
to this version.
- Added a simple security safeguard that locks-in the block chain up
to this point.
- Reduced addr messages to save bandwidth now that there are plenty
of nodes to connect to.
- Spanish translation by milkiway.
- French translation by aidos.
The security safeguard makes it so even if someone does have more
than 50% of the network’s CPU power, they can’t try to go back and redo
the block chain before yesterday. (if you have this update)
I’ll probably put a checkpoint in each version from now on. Once the
software has settled what the widely accepted block chain is, there’s no
point in leaving open the unwanted non-zero possibility of revision
months later.
Bitcoin Forum post — July 17, 2010 — source: 0423-03819.md
Post by: satoshi on July 17, 2010, 10:29:13 PM
Last edit: July 18, 2010, 09:49:16 PM by satoshi
I believe it’ll be possible for a payment processing company to
provide as a service the rapid distribution of transactions with
good-enough checking in something like 10 seconds or less.
The network nodes only accept the first version of a transaction they
receive to incorporate into the block they’re trying to generate. When
you broadcast a transaction, if someone else broadcasts a double-spend
at the same time, it’s a race to propagate to the most nodes first. If
one has a slight head start, it’ll geometrically spread through the
network faster and get most of the nodes.
A rough back-of-the-envelope example:
1 0
4 1
16 4
64 16
80% 20%
So if a double-spend has to wait even a second, it has a huge
disadvantage.
The payment processor has connections with many nodes. When it gets a
transaction, it blasts it out, and at the same time monitors the network
for double-spends. If it receives a double-spend on any of its many
listening nodes, then it alerts that the transaction is bad. A
double-spent transaction wouldn’t get very far without one of the
listeners hearing it. The double-spender would have to wait until the
listening phase is over, but by then, the payment processor’s broadcast
has reached most nodes, or is so far ahead in propagating that the
double-spender has no hope of grabbing a significant percentage of the
remaining nodes.
Bitcoin Forum post — July 17, 2010 — source: 0437-03825.md
Post by: satoshi on July 17, 2010, 10:54:24 PM
Quote from: llama on July 17, 2010, 09:56:25 PM
However, it’s important that you don’t lock all the way up the very
latest block. Otherwise, the attacker could generate a fake block (or a
few) right before you happen to lock it, and then his attack would be
far easier than it would have been without the block lock.
I went about 200 blocks back. The block chain was a clean straight
line without branches, and there was only one known version of the
locked block.
Quote from: llama on July 17, 2010, 09:56:25 PM
Also, I’m assuming that the block lock means that the blocks will
also come prepackaged with the client. Is this so?
Sorry, not yet, but I do want to make the initial block download
faster.
Bitcoin Forum post — July 17, 2010 — source: 0419-03840.md
Post by: satoshi on July 17, 2010, 11:25:16 PM
Quote from: NewLibertyStandard on July 17, 2010, 10:22:09 PM
Version 0.3 was supposed to reduce the number of outgoing connections
on non-port forwarded clients from 15 to 8, but I don’t think it really
happened. I’m not positive if this is the case. Correct me if I’m
wrong.
In 0.3.0, the change to 8 only ended up in the Windows version, the
other versions still had 15.
Bitcoin Forum post — July 18, 2010 — source: 0423-03867.md
Post by: satoshi on July 18, 2010, 01:59:15 AM
Quote from: llama on July 18, 2010, 12:03:29 AM
This is a good start, but still not impermeable.
I didn’t say impermeable, I said good-enough. The loss in practice
would be far lower than with credit cards.
Quote
(for example, by refusing to propogate word of the transaction at the
vending machine)
No, the vending machine talks to a big service provider (aka payment
processor) that provides this service to many merchants. Think something
like a credit card processor with a new job. They would have many well
connected network nodes.
Bitcoin Forum post — July 18, 2010 — source: 0055-04008.md
Post by: satoshi on July 18, 2010, 04:06:16 PM
Quote from: lachesis on June 16, 2010, 06:14:05 AM
I think you’re misunderstanding the issue. My browser will always be
able to go to 127.0.0.1 (barring some strange IE settings or a virus).
If I type the address into the URL bar or click a link, it will work
fine. However, it isn’t possible to use Javascript to complete POST
requests between domains (or ports on the same domain).
That’s what I thought too.
Quote from: sirius-m on June 16, 2010, 08:26:14 AM
Yeah, I meant to say that cross-domain javascript calls are
forbidden, so you can’t call 127.0.0.1 from a javascript that doesn’t
reside in 127.0.0.1. Come to think of it, it would be quite funny if
browsers allowed malicious cross-domain javascript to change people’s
Facebook pages etc.
Now I’m hearing a report that it IS possible for javascript to do a
cross-domain POST request to 127.0.0.1. Not other domains, but just
specifically to that one. Great…
If this is the case, then do not use the -server switch or bitcoind
on a system where you do web browsing.
Bitcoin Forum post — July 18, 2010 — source: 0437-04037.md
Post by: satoshi on July 18, 2010, 06:58:21 PM
The change list is basically encompassed by what’s listed in the
first message. Everyone should upgrade to get the important security
improvements.
Minimizing to tray had at least 3 different glitches and bugs on
Linux, including a crash one, so I disabled it again. You can still
re-enable the option with “-minimizetotray” if you want to use it
anyway. The bugs/glitches are somewhere in wxWidgets or GTK or Gnome and
I don’t know how to fix them. Sorry, I just don’t know what else to do,
it’s just too glitchy and buggy to have as a mainline feature.
Bitcoin Forum post — July 18, 2010 — source: 0461-04059.md
Post by: satoshi on July 18, 2010, 08:49:22 PM
I uploaded to SVN my changes to add a password to JSON-RPC. If you’re
set up to build, please test it.
The -server switch is replaced with -rpcpw=, which is also
used with bitcoind.
bitcoin -rpcpw= – runs with JSON-RPC port open
bitcoind -rpcpw= – daemon with password
If you have a better idea for the switch name, let me know, but keep
in mind there will eventually be a password for encrypting the database
too. I’m not sure but I think they may want to use different passwords
for the two.
It gives a warning if you don’t set a password.
All commands now require the password as the first parameter. It’ll
tell you that if you run “bitcoind help”.
The central code:
// Check password
if (params.size() < 1 || params[0].type() != str_type)
throw runtime_error("First parameter must be the password.");
if (params[0].get_str() != strRPCPassword)
{
if (strRPCPassword.size() < 15)
Sleep(50);
begin = strRequest.end();
printf("ThreadRPCServer incorrect password attempt\n");
throw runtime_error("Incorrect password.");
}
Any comments on these decisions?
if (strRPCPassword.size() < 15) Sleep(50); – this means if
it’s a short password, it’ll wait 50ms after each attempt. This might be
used as a DoS attack, but I figured if it’s a short password, it’s more
important to protect against brute force password scan. This may tell
outsiders whether the password is less than 15 characters, but less than
15 isn’t all that noteworthy, most passwords are less than 15. If you
want to close the DoS possibility, just use a password 15 characters or
longer.
begin = strRequest.end(); – if it’s a single request with
multiple invocations, I throw away the rest if one has a bad password.
This is so you can’t stuff it with millions of password attempts in one
packet. What do you think, is this the right thing to do? (multiple
invocation is probably almost never used anyway)
I also fixed the two duplicated commands listed in the help:
Bitcoin Forum post — July 18, 2010 — source: 0453-04068.md
Post by: satoshi on July 18, 2010, 09:24:09 PM
Last edit: July 18, 2010, 09:37:25 PM by satoshi
OpenSSL doesn’t have any interface for doing just the low level raw
block hash part of SHA256. SHA256 begins by wrapping your data in a
specially formatted buffer. Setting up the buffer takes an order of
magnitude longer than the actual hashing if you’re only hashing one or
two blocks like we do. It’s intended that the time is amortised if you
were hashing many KB or MB of data. In BitcoinMiner, we format the
buffer once and keep reusing it.
If you can find SHA256 code that’s faster (with MinGW/GCC) than what
we’ve got, that would be really great! (although, keep licensing in
mind) The one we have is the only one I tried, so there’s significant
chance for improvement.
When I wrote it more than 2 years ago, there were screaming hot SHA1
implementations but minimal attention to SHA256. That’s a lot of time
for them to come up with better stuff. SHA256 was a lot slower than the
fastest SHA1 at the time than I thought it should be. Obviously SHA256
should be slower than SHA1 by a certain amount, but not by as much as I
saw.
(hope you don’t mind I renamed your thread, SHA-256 optimisation is
something important that I keep forgetting about)
Bitcoin Forum post — July 19, 2010 — source: 0461-04169.md
Post by: satoshi on July 19, 2010, 04:43:13 AM
Right, that is quite a bit better.
Can you give me any examples of other stuff that does it that way?
(and what the command line looks like)
The main change you’re talking about here is instead of -rpcpw= when
you start bitcoind, you’d use a switch that specifies a text file to go
and read it from, right? (any ideas what I should name the switch?)
Warning: don't use -server or bitcoind where you web browse (v0.3.2 and lower)
Bitcoin Forum post — July 19, 2010 — source: 0479-04263.md
Post by: satoshi on July 19, 2010, 04:01:38 PM
Last edit: July 26, 2010, 05:34:20 PM by satoshi
Don’t use the -server or -daemon switch or run bitcoind on a machine
where you use a web browser. It opens port 8332 on 127.0.0.1, the local
loopback address, and you wouldn’t think that web browsers could
cross-site access it, but it is possible.
We’re working on a release soon that puts a password on the JSON-RPC
interface, but until then, avoid using the -server switch, and don’t web
browse on the same machine where bitcoind is running.
Update: The JSON-RPC HTTP authentication feature in 0.3.3 solves this
problem.
Bitcoin Forum post — July 19, 2010 — source: 0461-04268.md
Post by: satoshi on July 19, 2010, 04:20:50 PM
So you drop a settings file in the ~/.bitcoin directory, that sounds
better. In the “no password is set” warning, it could tell you where the
file is and what to do.
What is the most popular and common settings file format?
HTTP basic authentication should be considered. In actual practice
though, it’s more work for web developers to figure out how to specify
the password through some extra parameter in the HTTP or JSON-RPC
wrapper than to just stick an extra parameter at the beginning of the
parameter list. What do you think? Does HTTP basic authentication get us
any additional benefits? Moving it off the parameter list but then you
still have to specific it in a more esoteric place I’m not sure is a net
win.
Quote from: gavinandresen on July 19, 2010, 12:02:39 PM
I was confused for a bit because the password is given LAST on the
command line, but FIRST in the JSON-RPC params list. I agree that
reading the command-line password from a file would be more convenient
and more secure.
You’re also confusing me, what do you mean? Did I do something
unintended?
The timing is strange, just as we are getting a rapid increase in 3rd
party coverage after getting slashdotted. I hope there’s not a big hurry
to wrap the discussion and decide. How long does Wikipedia typically
leave a question like that open for comment?
It would help to condense the article and make it less promotional
sounding as soon as possible. Just letting people know what it is, where
it fits into the electronic money space, not trying to convince them
that it’s good. They probably want something that just generally
identifies what it is, not tries to explain all about how it works.
If you post in http://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Bitcoin
please don’t say “yeah, but bitcoin is really important and special so
the rules shouldn’t apply” or argue that the rule is dumb or unfair.
That only makes it worse. Try to address how the rule is satisfied.
Search “bitcoin” on google and see if you can find more big
references in addition to the infoworld and slashdot ones. There may be
very recent stuff being written by reporters who heard about it from the
slashdot article.
I hope it doesn’t get deleted. If it does, it’ll be hard to overcome
the presumption. Institutional momentum is to stick with the last
decision. (edit: or at least I assume so, that’s how the world usually
works, but maybe Wiki is different)
Bitcoin Forum post — July 21, 2010 — source: 0461-04577.md
Post by: satoshi on July 21, 2010, 12:05:20 AM
Still need to know what’s the most typical settings file format on
Linux. Is there a standard file extension? I’ve never seen a settings
file using JSON, and it doesn’t look very human friendly with everything
required to be in quotes. I think what I usually see is like:
# comment
setting=value
Is there a settings file thing in Boost?
When you’re using bitcoind to issue commands from the command line as
a client, can we have it get the password from the settings file then
too?
Gavin pointed out I forgot to increment the column of numbers in
CommandLineRPC, so the current -rpcpw= implementation doesn’t work right
from the command line with non-string parameters. (JSON-RPC is fine)
Still under construction.
Bitcoin Forum post — July 21, 2010 — source: 0461-04646.md
Post by: satoshi on July 21, 2010, 05:51:34 AM
I was researching config file formats, here’s a comparison.
YAML is massive. I’m not sure there’s a lightweight easy to build
library we can integrate into our project. Seems overkill.
JSON is tempting and I’m inclined to like it, but two main sticking
points:
No comments! How can you have a config file where you can’t
comment out a line to disable it?
Not very user friendly to have to “quote” all the strings,
including the keys, and also have to remember the comma at the end of
lines.
{
"key" : "value",
}
I suppose we could easily preprocess JSON reading the config file one
line at a time, truncate the lines at any # character (and/or “//”?),
concatenate them into a string and pass it to JSON, so you could go:
# comment
“key” : “value”, # still have to remember the comma
“key2” : “value”, // comment like this or both
Boost has boost::program_options.
We could read lines ourselves and feed them into a map<string,
string> mapConfig.
while (!eof)
read line
if ‘#’ found, truncate line
split line at first ‘:’ -> key, value
mapConfig.insert(key, value)
If we use the syntax:
# comment
key : value
…and don’t allow whitespace indenting before the keys, I guess we
would be a subset of YAML and could switch to YAML someday if we need
more complexity.
If we go with self parsed, that doesn’t mean we can’t use JSON on
particular parameter values as needed. If an option needs a list or more
structured data, it could always parse its value as json:
key : [“item1”, “item2”, “item3”]
Although it has to be all on one line then.
I guess I’m leaning towards self parsed mapConfig:
Bitcoin Forum post — July 21, 2010 — source: 0461-04758.md
Post by: satoshi on July 21, 2010, 04:07:57 PM
Quote from: gavinandresen on July 21, 2010, 12:11:10 PM
I just did a quick survey of 20 .conf files in /etc on my debian
system, and found:
1 file used “key value”
5 used “key=value”
Thanks for that survey!
I find “key value” a little unnatural. There ought to be a more
definite separator between key and value that suggests assignment. The
space people may just be getting lazy using their language’s split
function.
key=some full sentence with spaces in it. # seems more clear
key some full sentence with spaces in it. # than this
Allright then, lets go with self-parsed mapConfig, syntax: # comment
key=value
file extension .conf. What’s the filename, is it
~/.bitcoin/settings.conf or ~/.bitcoin/bitcoin.conf or what?
I think we better strip whitespace at the beginning and end of the
key and the value.
# user who likes column formatted
k = value
key = value
longerkey = this sentence would be this # “this sentence would be
this”
key = value # guess this is ok too
nextkey = value
right = justified
The normal syntax should be “key=value”, but you can’t blame people
for the occasional “key = value”.
Bitcoin Forum post — July 21, 2010 — source: 0461-04775.md
Post by: satoshi on July 21, 2010, 05:31:09 PM
boost::program_options has the same “key=value” format. Gavin pointed
out we can use it in a simple way as a parser without getting into all
the esoteric c++ syntax like typed value extraction. We can use more
features if we want later.
Lets go ahead with HTTP basic authentication instead of password as a
parameter.
Bitcoin Forum post — July 23, 2010 — source: 0461-05337.md
Post by: satoshi on July 23, 2010, 05:07:40 PM
Quote from: gavinandresen on July 23, 2010, 03:11:45 PM
Question for everybody: should I add a section to the wiki page
describing, in detail, how to do HTTP Basic authentication? PHP and
Python make is really easy-- just use the http://user:pass@host:port/ URL syntax.
Yes, I think that would be really good so each dev doesn’t have to
figure it out themselves. We need a simple example for each of Python,
PHP and Java importing the json-rpc library and using it to do a getinfo
or something, including doing the http authentication part.
Bitcoin Forum post — July 23, 2010 — source: 0548-05339.md
Post by: satoshi on July 23, 2010, 05:23:47 PM
If I recall correctly, 500 is the prescribed status code for JSON-RPC
error responses. There is still a JSON response in the body of the reply
telling the explanation of the error, which could be something like
{“result”:““,”error”:“bitcoin address not found”,“id”:“1”}.
Bitcoin Forum post — July 23, 2010 — source: 0550-05349.md
Post by: satoshi on July 23, 2010, 06:24:56 PM
Last edit: July 23, 2010, 08:08:46 PM by satoshi
By making some adjustments to the database settings, I was able to
make the initial block download about 5 times faster. It downloads in
about 30 minutes.
The database default had it writing each block to disk synchronously,
which is not necessary. I changed the settings to let it cache the
changes in memory and write them out in a batch. Blocks are still
written transactionally, so either the complete change occurs or none of
it does, in either case the data is left in a valid state.
I only enabled this change during the initial block download. When
you come within 2000 blocks of the latest block, these changes turn off
and it slows down to the old way.
I built a test build if you’d like to start using it:
These binaries also include Gavin Andresen’s JSON-RPC HTTP
authentication feature and the other important security improvements
from 0.3.2.
I’ve been running a test over the last 24 hours that kills and
restarts it randomly every 2-60 seconds (poor thing) while it’s trying
to do an initial block download and it’s been fine.
There are no changes to the way it handles wallet.dat. This change is
only for blk*.dat and the non-critical addr.dat. You can always delete
blk*.dat if it gets screwed up and let it re-download.
Bitcoin Forum post — July 23, 2010 — source: 0461-05383.md
Post by: satoshi on July 23, 2010, 08:39:03 PM
I don’t think authentication should be disabled by default if there’s
no conf file or the config file doesn’t contain “rpcpassword”, but what
if it contains “rpcpassword=”?
I can see both points.
What if the programmer can’t figure out how to do HTTP authentication
in their language (Fortran or whatever) or it’s not even supported by
their JSON-RPC library? Should they be able to explicitly disable the
password requirement?
OTOH, what if there’s a template conf file, with
rpcpassword= # fill in a password here
There are many systems that don’t allow you to log in without a
password. This forum, for instance. Gavin’s point seems stronger.
BTW, I haven’t tested it, but I hope having rpcpassword= in the conf
file is valid. It’s only if you use -server or -daemon or bitcoind that
it should fail with a warning. If it doesn’t need the password, it
should be fine. Is that right?
{“method”: “postMessage”, “params”: [“I have a question:”], “id”:
101}
Reply:
{“result”: 1, “error”: null, “id”: 99}
{“result”: 1, “error”: null, “id”: 101}
I can’t remember where I think I saw that it’s supposed to send back
HTTP status 500 for an error reply. If it contains multiple responses
and one is an error, I wonder if that makes the status 500 for the whole
thing, I guess so. Maybe it should always return 200. I think someone
sounded like the 500 might be causing a problem.
This probably gets fixed after 0.3.3. Until then, just use single
invocation. I wonder if any JSON-RPC package even supports multiple
invocation, probably not.
It would be nice if we could pin down better how multiple-invocation
is supposed to work, if at all, before trying to fix it, and whether
returning HTTP status 500 for error response is right.
Bitcoin Forum post — July 24, 2010 — source: 0548-05419.md
Post by: satoshi on July 24, 2010, 01:15:58 AM
Can anyone confirm if JSON-RPC over HTTP is supposed to use status
500 if the reply is an error reply? I can’t remember where I picked that
up, maybe it’s wrong. It seems like 200 would make more sense unless
there’s something wrong with the mechanics of the HTTP request itself.
(and maybe that’s what it said and I forgot and spread 500 to all error
responses)
Bitcoin Forum post — July 24, 2010 — source: 0556-05443.md
Post by: satoshi on July 24, 2010, 03:32:52 AM
Please test 0.3.2.5 in preparation for the 0.3.3 release! This build
is looking good and should be the one that goes into 0.3.3. I encourage
you to go ahead and upgrade now if you’re on Windows or Linux.
New features:
- Gavin Andresen’s HTTP authentication to secure JSON-RPC
- 5x faster initial block download, under 30 minutes
Bitcoin Forum post — July 24, 2010 — source: 0555-05450.md
Post by: satoshi on July 24, 2010, 04:04:20 AM
FLATDATA was a workaround to serialize a fixed field length array.
There was a cleaner way to make it understand how to serialize arrays
directly, but MSVC6 couldn’t do it and I wanted to keep compatibility
with MSVC6 at that time. We don’t support MSVC6 anymore because we use
something in Boost that doesn’t. We lost support for it after 0.2.0.
Maybe someday I’ll swap in the clean way that just knows how to
serialize fixed length arrays without wrapping them in FLATDATA.
Bitcoin Forum post — July 25, 2010 — source: 0571-05724.md
Post by: satoshi on July 25, 2010, 07:06:23 PM
Red, thanks for telling me privately first! Please go ahead and post
it (and relieve the suspense for everyone!)
His point is that transactions paid to a Bitcoin Address are only as
secure as the hash function. To make Bitcoin Addresses short, they are a
hash of the public key, not the public key itself. An attacker would
only have to break the hash function, not ECDSA.
Bitcoin Forum post — July 25, 2010 — source: 0571-05740.md
Post by: satoshi on July 25, 2010, 08:01:40 PM
Quote from: knightmb on July 25, 2010, 07:44:02 PM
If I figure out that Public Key 123456 generates Hash ABCD
and
Public Key 654321 also generates Hash ABCD
I’m still left without the Private Key.
But from what you are saying, all I need is Public Key 654321 and I
can spend coin pretending to be Public Key 123456.
You would still have to sign it with public key 654321. You need to
find a collision using a public key for which you know the private
key.
When you claim a Bitcoin Address transaction, you give your public
key that matches the hash, then you must sign it with that key.
Red’s point is that it’s easy to quickly generate insecure public
keys which you could break and find the private key after you find a
collision.
He points out that if the public key was required to be a secure one,
one which must have required significant work to find the prime numbers,
that would increase the strength above that of the hash function alone.
Someone trying to brute force would have to take time generating a key
for each attempt.
Bitcoin Forum post — July 25, 2010 — source: 0571-05754.md
Post by: satoshi on July 25, 2010, 08:48:01 PM
Last edit: July 26, 2010, 03:26:21 AM by satoshi
Quote
Here is a paper that claims to find SHA-1 collisions in 2^52 crypto
operations. And optimally secure hash would take 2^80 operations. 2^52
time is still large, but it is getting into cluster and botnet
range.
2^80 is if you can use a birthday attack. You can’t use a birthday
attack for this, so the difficulty is the full 2^160 bits. Although, if
you were trying to crack any one of 1 million (2^20) transactions, you
could do a partial birthday attack 2160/220 = 2^140.
Bitcoin Addresses are the only place where 160-bit hash is used.
Everything else is SHA-256. They’re calculated as:
bitcoinaddress = RIPEMD-160(SHA-256(publickey))
Correct me if I’m wrong (please, and I’ll gladly eat crow) but I
think it would be hard to use an analytical attack on RIPEMD-160 in this
case. An analytical attack prescribes a certain range or pattern of
inputs to try that will greatly increase your chance of finding a
collision. Here, you don’t have that kind of control over RIPEMD-160’s
input, because the input is the output of SHA-256. If an analytical
attack helps you find an input to RIPEMD-160 that produces a collision,
what are you going to do with it? You still have to get SHA-256 to
output that value, so you would still have to break SHA-256 too.
For brute force, RIPEMD-160(SHA-256(x)) is no stronger than
RIPEMD-160 alone. But for analytical attack, it seems like you must
analytical attack both RIPEMD-160 and SHA-256. If I’m wrong, then the
strength is the same as RIPEMD-160 and the SHA-256 only serves as one
round of key strengthening.
Bitcoin Forum post — July 25, 2010 — source: 0461-05767.md
Post by: satoshi on July 25, 2010, 09:34:29 PM
Quote from: lachesis on July 25, 2010, 07:52:35 PM
I found what appears to be a bug: with a long enough username and
password combination, the base64 encoder in bitcoind produces
authorization headers that look like this:
It inserts a newline every 64 characters, which obviously breaks the
Authorization header, so commands like “bitcoin getinfo” fail. The
server still works fine with properly behaving clients.
This can be solved by removing the newlines (and maybe ’s) from
result at the end of the Base64Encode function:
Bitcoin Forum post — July 25, 2010 — source: 0461-05769.md
Post by: satoshi on July 25, 2010, 09:44:16 PM
Quote from: BitLex on July 25, 2010, 08:45:38 PM
i got some problems here too trying to get this run on PHP.
so far i had no luck, neither the wiki-sample (jsonRPCClient trying
to fopen(http://username:password@localhost:8332/)), nor my
curl-sample (using setopt CURLOPT_HTTPAUTH, CURLAUTH_BASIC) seem to
work.
That’s strange, didn’t someone just say that was supposed to work?
(what library was he using?) Post if you figure out what wrong.
I hope it’s not going to put up this much of a fight for all PHP
users.
Looks like we’ve got the Fortran scenario already.
Bitcoin Forum post — July 25, 2010 — source: 0458-05772.md
Post by: satoshi on July 25, 2010, 10:06:57 PM
For future reference, here’s my public key. It’s the same one that’s
been there since the bitcoin.org site first went up in 2008. Grab it now
in case you need it later.
Bitcoin Forum post — July 25, 2010 — source: 0571-05778.md
Post by: satoshi on July 25, 2010, 10:27:36 PM
Sorry, actually it’s ECDSA (Elliptic Curve Digital Signature
Algorithm) not RSA. I shouldn’t have said “prime numbers”. ECDSA doesn’t
take much time to generate a keypair.
Bitcoin Forum post — July 26, 2010 — source: 0576-05904.md
Post by: satoshi on July 26, 2010, 05:23:33 PM
I replaced the last of the few wxBase dependencies in bitcoind.
bitcoind now compiles without wxWidgets or wxBase in SVN rev 112.
main(int argc, char* argv[]) is added to init.cpp. CMyApp and the
Startup folder stuff are moved to ui.cpp. ui.cpp and uibase.cpp aren’t
linked by bitcoind.
The makefiles have -DGUI to control whether the GUI is used.
I test compiled MinGW, VC and Ubuntu. I don’t know if I broke the Mac
OSX build, someone will need to check that.
Bitcoin Forum post — July 26, 2010 — source: 0501-05920.md
Post by: satoshi on July 26, 2010, 06:41:31 PM
Quote from: Olipro on July 26, 2010, 06:39:17 AM
Credit to tcatm for the caching part of the SHA context - this offers
absolutely brilliant performance. Additionally, the Intel compiler
really comes into its own here as its parallelisation abilities give a
massive performance boost over Visual Studio.
Performance: 4700khash/s on 4 cores, I think that speaks for
itself.
I’ve included both the VS and Intel build, but there’s really no
comparison, the Intel build craps all over VS.
Is that still starting from Crypto++? Lets get this into the main
sourcecode.
Cached SHA256: http://pastebin.com/rJAYZJ32 (although I’m pretty sure
this is publically submitted elsewhere, I was linked to it on IRC)
I added the cached SHA256 state idea to the SVN, rev 113. The speedup
is about 70%. I credited it to tcatm based on your post in the x64
thread.
I can compile the Crypto++ 5.6.0 ASM SHA code with MinGW but as soon
as it runs it crashes. It says its for MASM (Microsoft’s assembler) and
the sample command line they give looks like Visual C++. Does it only
work with the MSVC and Intel compilers?
Bitcoin Forum post — July 27, 2010 — source: 0572-06069.md
Post by: satoshi on July 27, 2010, 06:27:30 PM
Last edit: July 27, 2010, 07:44:48 PM by satoshi
Quote from: BlackEye on July 25, 2010, 10:12:23 PM
I was able to integrate the SHA256 functionality from Crypto++ 5.6.0
into Bitcoin. This is the fastest SHA256 yet using the SSE2 assembly
code. Since Bitcoin was sending unaligned data to the block hash
function, I had to change the MOVDQA instruction to MOVDQU.
I think using the SHA256 functionality from Crypto++ 5.6.0 is the way
forward right now.
I added a subset of the Crypto++ 5.6.0 library to the SVN. I stripped
it down to just SHA and 11 general dependency files. There shouldn’t be
any other crypto in there other than SHA.
I aligned the data fields and it worked. The ASM SHA-256 is about 48%
faster. The combined speedup is about 2.5x faster than version
0.3.3.
I guess it’s using SSE2. It automatically sets its build
configuration at compile time based on the compiler environment.
It looks like it has some SSE2 detection at runtime, but it’s hard to
tell if it actually uses it to fall back if it’s not available. I want
the release builds to have SSE2. SSE2 has been around since the first
Pentium 4. A Pentium 3 or older would be so slow, you’d be wasting your
electricity trying to generate on it anyway.
Bitcoin Forum post — July 27, 2010 — source: 0572-06083.md
Post by: satoshi on July 27, 2010, 07:47:42 PM
OK, thanks. I’d also like to know if it runs fine as long as you
don’t turn on Generate. You’d think as long as it doesn’t actually
execute any SSE2 instructions, it would still load. At least Pentium 3’s
could run it without generating.
Bitcoin Forum post — July 28, 2010 — source: 0601-06268.md
Post by: satoshi on July 28, 2010, 08:58:26 PM
It was able to reproduce this. The database doesn’t like the relative
path.
“bitcoind -datadir=./subdir getinfo” works against a running daemon,
but trying to start the daemon as “bitcoind -datadir=./subdir” gets that
exception.
I guess we should resolve the full path before passing it to the
database.
It looks like you were the first one to ever use -datadir with a
relative path.
Bitcoin Forum post — July 29, 2010 — source: 0587-6301.md
Post by: satoshi on July 29, 2010, 01:16:23 AM
You were looking at the wrong code. Here’s the code that applies:
Code:
bool CBlock::CheckBlock() const
{
...
// Check timestamp
if (nTime > GetAdjustedTime() + 2 * 60 * 60)
return error("CheckBlock() : block timestamp too far in the future");
...
bool CBlock::AcceptBlock()
{
...
// Check timestamp against prev
if (nTime <= pindexPrev->GetMedianTimePast())
return error("AcceptBlock() : block's timestamp is too early");
The timestamp is limited to up to 2 hours in the future. It can be
earlier than the previous block, but it must be greater than the median
of the last 11 blocks. The reason for doing it that way is so the time
can get corrected in the next block if the previous block had the time
too far in the future, like what happened.
Bitcoin Forum post — July 29, 2010 — source: 0532-06306.md
Post by: satoshi on July 29, 2010, 02:00:38 AM
The current system where every user is a network node is not the
intended configuration for large scale. That would be like every Usenet
user runs their own NNTP server. The design supports letting users just
be users. The more burden it is to run a node, the fewer nodes there
will be. Those few nodes will be big server farms. The rest will be
client nodes that only do transactions and don’t generate.
Quote from: bytemaster on July 28, 2010, 08:59:42 PM
Besides, 10 minutes is too long to verify that payment is good. It
needs to be as fast as swiping a credit card is today.
See the snack machine thread, I outline how a payment processor could
verify payments well enough, actually really well (much lower fraud rate
than credit cards), in something like 10 seconds or less. If you don’t
believe me or don’t get it, I don’t have time to try to convince you,
sorry.
Bitcoin Forum post — July 29, 2010 — source: 0338-06307.md
Post by: satoshi on July 29, 2010, 02:10:46 AM
WTF? How did we get on that? AFAIK, the only e-mail is if you tell
the forum to do notifications, and I guess the wiki registration. I’d
consider turning off the forum notification e-mails, I don’t know why we
have that.
Bitcoin Forum post — July 29, 2010 — source: 0626-06451.md
Post by: satoshi on July 29, 2010, 07:13:06 PM
Last edit: October 04, 2010, 01:37:36 PM by satoshi
Please upgrade to 0.3.6 ASAP! We fixed an implementation bug where it
was possible that bogus transactions could be displayed as accepted. Do
not accept Bitcoin transactions as payment until you upgrade to version
0.3.6!
If you can’t upgrade to 0.3.6 right away, it’s best to shut down your
Bitcoin node until you do.
Bitcoin Forum post — July 29, 2010 — source: 0626-06490.md
Post by: satoshi on July 29, 2010, 09:20:38 PM
Last edit: July 29, 2010, 09:36:48 PM by satoshi
0.3.6 Linux build is back to the old makefile.unix. It static links
libjpeg so that shouldn’t be a problem.
Is that working better?
If you got 22DbRunRecoveryException and you’ve used someone else’s
build before, you may need to delete (or move the files somewhere else)
database/log.000000*
Windows and Linux users: if you got 0.3.5 you still need to upgrade
to 0.3.6.
Bitcoin Forum post — July 29, 2010 — source: 0626-06502.md
Post by: satoshi on July 29, 2010, 09:43:15 PM
“./bitcoin: /lib64/libc.so.6: version `GLIBC_2.11’ not found
(required by ./bitcoin)” isn’t a new problem that started with 0.3.6 is
it? This was built on the same OS installations as 0.3.0.
Unfortunately I upgraded to Ubuntu 10.04 before 0.3.0. I will not
upgrade anymore. I don’t know when I might have time to reinstall to
downgrade, but at least by not upgrading, it’ll gradually fix
itself.
Bitcoin Forum post — July 29, 2010 — source: 0628-06508.md
Post by: satoshi on July 29, 2010, 10:04:15 PM
Actually, it works well to just PM me. I’m the one who’s going to be
fixing it. If you find a security flaw, I would definitely like to hear
from you privately to fix it before it goes public.
Bitcoin Forum post — July 29, 2010 — source: 0615-06512.md
Post by: satoshi on July 29, 2010, 10:08:31 PM
If the transaction didn’t go out immediately at first, like if you
weren’t connected at the time, it may take up to 2 hours to resend it.
Long term, it does keep relentlessly sending it.
I’ll shorten that length of time in a future version.
You do need to have downloaded the complete block chain (currently
71040 blocks) before you’ll see any confirms. Same with the
recipient.
Bitcoin Forum post — July 29, 2010 — source: 0612-06516.md
Post by: satoshi on July 29, 2010, 10:17:24 PM
Yeah, acutely aware that I should have stayed on 9.04 or 9.10. It’s a
lot more work to downgrade than upgrade and I’ve been squeezed for time.
Ubuntu is the most popular distro, so I’m staying with that.
Bitcoin Forum post — July 29, 2010 — source: 0626-06542.md
Post by: satoshi on July 29, 2010, 11:12:12 PM
Quote from: lachesis on July 29, 2010, 10:14:36 PM
On Debian testing 32-bit, I get a few build errors, all
resembling:
Code:
script.cpp:114: error: ‘OP_NOP1’ was not declared in this scope
I got these when attempting to “make bitcoind” without “make clean”
or “make” first. It looks like the bitcoind build instructions don’t
compile the headers first, but they also don’t delete the headers.h.gch,
so the old headers are used if present.
If anyone else gets this error, the simplest solution is to “make
clean” and retry the build.
We don’t really need pre-compiled header. It only makes it compile
slightly faster. I think I’ll just get rid of it. Even still, you’d
still need to remember to “make -f makefile.unix clean” or delete
headers.h.gch one more time to get rid of the leftover file.
Damn that GLIBC_2.11. I thought I’d been careful not to accept any of
the updates.
Re: Bug: "Immature" coins lost in wallet.dat during transaction
Bitcoin Forum post — July 30, 2010 — source: 0642-06701.md
Post by: satoshi on July 30, 2010, 07:19:05 PM
I don’t get how it let you send if it was not matured. Your balance
would have been lower than the amount. It would have said balance 0.01,
right? If I try that it says “you don’t have enough money” or
“Insufficient funds” from the command line.
How many blocks did it say it had left to mature when you sent?
There’s a chance it might still go through.
Have you copied or moved your wallet.dat in any way?
Bitcoin Forum post — July 30, 2010 — source: 0611-06706.md
Post by: satoshi on July 30, 2010, 07:40:54 PM
What are you needing to use listtransactions for?
The reason I didn’t implement listtransactions is I want to make sure
web programmers don’t use it. It would be very easy to latch onto that
for watching for received payments. There is no reliable way to do it
that way and make sure nothing can slip through the cracks. Until we
have solid example code using getreceivedbyaddress and
getreceivedbylabel to point to and say “use this! use this! don’t use
listtransactions!”, I don’t think we should implement
listtransactions.
When we do implement listtransactions, maybe one way to fight that is
to make it all text. It should not break down the fields into
e.g. comment, confirmations, credit, debit. It could be one pretty
formatted string like “0/unconfirmed 0:0:0 date comment debit 4 credit
0” or something so it’s hard for programmers to do the wrong thing and
process it. It’s only for viewing the status of your server. I guess
that would be kinda annoying for web interfaces that would rather format
it into html columns though.
Bitcoin Forum post — July 30, 2010 — source: 0626-06711.md
Post by: satoshi on July 30, 2010, 07:53:06 PM
Quote from: knightmb on July 30, 2010, 07:24:07 PM
I can only imagine the pain you went through to get these builds
because I’m trying to build the program on a Ubuntu 9.04 box and so far
I can’t seem to find all the dependencies to compile no matter how much
I keep installing packages and compiling source, LOL.
I can’t understand why you’re having so much pain. I just followed
the instructions in build-unix.txt. I made a couple little corrections
for Boost 1.37, which I’ll put on SVN the next time I update it, noted
below:
Bitcoin Forum post — July 31, 2010 — source: 0648-06751.md
Post by: satoshi on July 31, 2010, 12:29:20 AM
That’s amazing…
So are you saying you use 128-bit registers to SIMD four 32-bit data
at once? I’ve wondered about that for a long time, but I didn’t think it
would be possible due to addition carrying into the neighbour’s
value.
Bitcoin Forum post — August 02, 2010 — source: 0660-07068.md
Post by: satoshi on August 02, 2010, 06:02:20 PM
“Minimize to the tray instead of the taskbar” & “Minimize to the
tray on close” must not be implemented yet on the Mac. We should grey
them out in the next version.
Bitcoin Forum post — August 02, 2010 — source: 0632-07090.md
Post by: satoshi on August 02, 2010, 08:22:08 PM
The reason I didn’t use protocol buffers or boost serialization is
because they looked too complex to make absolutely airtight and secure.
Their code is too large to read and be sure that there’s no way to form
an input that would do something unexpected.
I hate reinventing the wheel and only resorted to writing my own
serialization routines reluctantly. The serialization format we have is
as dead simple and flat as possible. There is no extra freedom in the
way the input stream is formed. At each point, the next field in the
data structure is expected. The only choices given are those that the
receiver is expecting. There is versioning so upgrades are possible.
CAddress is about the only object with significant reserved space in
it. (about 7 bytes for flags and 12 bytes for possible future IPv6
expansion)
The larger things we have like blocks and transactions can’t be
optimized much more for size. The bulk of their data is hashes and keys
and signatures, which are uncompressible. The serialization overhead is
very small, usually 1 byte for size fields.
On Gavin’s idea about an existing P2P broadcast infrastructure, I
doubt one exists. There are few P2P systems that only need broadcast.
There are some libraries like Chord that try to provide a distributed
hash table infrastructure, but that’s a huge difficult problem that we
don’t need or want. Those libraries are also much harder to install than
ourselves.
Re: Content-Length header and 500 (was Re: Authentication, JSON RPC and Python)
Bitcoin Forum post — August 03, 2010 — source: 0689-07335.md
Post by: satoshi on August 03, 2010, 09:26:26 PM
Last edit: August 04, 2010, 12:19:17 AM by satoshi
Quote from: gavinandresen on August 03, 2010, 06:56:44 PM
Quote from: jgarzik on August 03, 2010, 06:09:08 PM
bitcoin requires the Content-Length header, but several JSON-RPC
libraries do not provide it. When the Content-Length header is absent,
bitcoin returns 500 Internal Server Error.
Can you be more specific about which JSON libraries don’t provide
Content-Length ? It’d be nice to document that.
I guess we should try to support the case where there’s no
Content-Length parameter. I don’t want to rip and replace streams
though, even if it has to read one character at a time.
Edit: That is, assuming there actually are any libraries that don’t
support Content-Length.
Re: What happens when network is split for prolonged time and reconnected?
Bitcoin Forum post — August 03, 2010 — source: 0661-07356.md
Post by: satoshi on August 03, 2010, 10:45:07 PM
creighto: I agree with that idea. After a few hours, it should be
possible for the client to notice if the flow of blocks has dropped off
by more than would be likely just by chance. It could tell if it’s not
hearing the hum of the world anymore.
Quote from: knightmb on August 03, 2010, 07:02:13 PM
Quote from: gavinandresen on August 03, 2010, 06:38:44 PM
Or if the split lasted long enough (more than 100 blocks),
transactions that involve generated coins on the shorter chain would be
invalid at the merge.
Interesting info, so other than some double-spending issues, as long
as the block chain isn’t separated for more than 100 or so blocks (or
16+ hours),
In practice, splits are likely to be very asymmetrical. It would be
hard to split the world down the middle. More likely it would be a
single country vs the rest of the world, lets say a 1:10 split. In that
case, it would take the minority fork 10 times as long to generate 100
blocks, so about 7 days. Also it would be super easy for the client to
realize it’s hearing way too few blocks and something must be wrong.
Quote from: knightmb on August 03, 2010, 07:02:13 PM
If there a hard coded limit on split delay? Meaning if I had a small
network split from the public network, spent some coin around, came back
a few days later and got them sync up to the public network (other than
coin generation if it happened) transactions should be fine?
There’s no time limit. Assuming you weren’t spending coins generated
in the minority fork, or spending someone’s double-spends you received,
your transactions can get into the other chain at any time later.
Bitcoin Forum post — August 03, 2010 — source: 0696-07364.md
Post by: satoshi on August 03, 2010, 11:40:18 PM
Version 0.3.8 adds an important security improvement. Everyone should
upgrade to get this change.
The new safety feature displays a warning message in the status bar
and locks down RPC if it detects a problem that may require an
upgrade.
If it sees a longer chain, but it can’t process it, then it knows
something is wrong. It displays “WARNING: Displayed transactions may not
be correct! You may need to upgrade.” and makes most RPC commands return
an error. It still keeps generating as normal, which is necessary for
the stability of the network.
There were important security updates in the versions before this
too, so if you haven’t upgraded recently, it’s extremely important that
you upgrade now!
Also, don’t forget, we recently added 2.4x faster generating thanks
to tcatm’s mid-state caching optimisation and BlackEye’s help getting
ASM SHA-256 working.
Bitcoin Forum post — August 04, 2010 — source: 0685-07372.md
Post by: satoshi on August 04, 2010, 12:09:32 AM
Quote from: knightmb on August 03, 2010, 11:46:46 PM
There are two versions, one built from stock code, the other modified
to accept up to 1,000 nodes (hence the super node name)
I’d rather you didn’t make a build of the 1000 node connecting
version available. It won’t take very many people running that before we
have to make another release just to limit the incoming connections.
Bitcoin Forum post — August 04, 2010 — source: 0696-07381.md
Post by: satoshi on August 04, 2010, 12:29:37 AM
Last edit: August 04, 2010, 03:09:44 AM by satoshi
I guess SourceForge hasn’t updated its mirrors yet. The files are
there on the admin side, but not on the user side. I have no idea how
long that will take. It’s always been immediate in the past.
Re: Building initial transaction trust through "coin ripping"
Bitcoin Forum post — August 04, 2010 — source: 0635-07385.md
Post by: satoshi on August 04, 2010, 12:40:40 AM
The software is designed to support things like this. I was going to
post details of the plans for Escrow, but since getting slashdotted I
haven’t had time.
Bitcoin Forum post — August 04, 2010 — source: 0287-07524.md
Post by: satoshi on August 04, 2010, 04:25:36 PM
Last edit: August 05, 2010, 03:05:09 PM by satoshi
Quote from: Insti on August 04, 2010, 02:58:31 PM
It seems to do more harm than good because it prevents micropayment
implementations such as the one bytemaster is suggesting.
Bitcoin isn’t currently practical for very small micropayments. Not
for things like pay per search or per page view without an aggregating
mechanism, not things needing to pay less than 0.01. The dust spam limit
is a first try at intentionally trying to prevent overly small
micropayments like that.
Bitcoin is practical for smaller transactions than are practical with
existing payment methods. Small enough to include what you might call
the top of the micropayment range. But it doesn’t claim to be practical
for arbitrarily small micropayments.
Bitcoin Forum post — August 05, 2010 — source: 0287-07687.md
Post by: satoshi on August 05, 2010, 04:03:21 PM
Forgot to add the good part about micropayments. While I don’t think
Bitcoin is practical for smaller micropayments right now, it will
eventually be as storage and bandwidth costs continue to fall. If
Bitcoin catches on on a big scale, it may already be the case by that
time. Another way they can become more practical is if I implement
client-only mode and the number of network nodes consolidates into a
smaller number of professional server farms. Whatever size micropayments
you need will eventually be practical. I think in 5 or 10 years, the
bandwidth and storage will seem trivial.
I am not claiming that the network is impervious to DoS attack. I
think most P2P networks can be DoS attacked in numerous ways. (On a side
note, I read that the record companies would like to DoS all the file
sharing networks, but they don’t want to break the
anti-hacking/anti-abuse laws.)
If we started getting DoS attacked with loads of wasted transactions
back and forth, you would need to start paying a 0.01 minimum
transaction fee. 0.1.5 actually had an option to set that, but I took it
out to reduce confusion. Free transactions are nice and we can keep it
that way if people don’t abuse them.
That brings up the question: if there was a minimum 0.01 fee for each
transaction, should we automatically add the fee if it’s just the
minimum 0.01? It would be awfully annoying to ask each time. If you have
50.00 and send 10.00, the recipient would get 10.00 and you’d have 39.99
left. I think it should just add it automatically. It’s trivial compared
to the fees many other types of services add automatically.
Quote from: FreeMoney on August 04, 2010, 07:30:32 PM
Bitcoin Forum post — August 05, 2010 — source: 0287-07694.md
Post by: satoshi on August 05, 2010, 04:30:20 PM
Quote from: bytemaster
Payments would generally be advanced, say 1 BTC at a time and when
the connection closes any “change” would be returned. This rule makes it
impossible to pay for a simple “search query” with no further
transactions.
One alternative is to use a round-up system. You pay for, say, 1000
pages or images or downloads or searches or whatever at a time. When
you’ve used up your 1000 pages, you pay for another 1000 pages. If you
only use 1 page, then you have 999 left that you may never use, but it’s
not a big deal because the cost per 1000 is still small.
Or you could pay per day. The first time you access the site on a
given day, you pay for 24 hours of access.
Per 1000 or per day may be easier for consumers to get their heads
around too. They worry about per item because it’s harder to figure if
it might add up too fast. Unlimited for 24 hours they know what the cost
will be. Or if 1000 seems like plenty, they’re not worrying that it’s
costing more with each click if they figure 1000 is more than they’ll
probably use.
Bitcoin Forum post — August 05, 2010 — source: 0287-07696.md
Post by: satoshi on August 05, 2010, 04:39:58 PM
Quote from: bytemaster on August 05, 2010, 03:39:19 PM
The only solution to this problem is to make broadcasting of a
transaction “non free”. Namely, if you want me to include it you have to
pay me. The net (no pun intended) result is that each client would need
to pay other clients to whom they even send their transaction, not just
the individual who gets it in a block. In this way the laws of economics
take over and no one gets a free ride on the transaction broadcast
system.
I don’t know a way to implement that. The transaction fee to the
block creator uses a special trick to include the transaction fee
without any additional size. If there was a transaction for each
transaction fee, then what about the transactions fees for the
transaction fee’s transaction?
Bitcoin Forum post — August 05, 2010 — source: 0713-07706.md
Post by: satoshi on August 05, 2010, 05:38:21 PM
I can’t think of a way to implement that. All the transaction fees
would be additional transactions. What about the transaction fees for
the transaction fee’s transaction?
Bitcoin Forum post — August 05, 2010 — source: 0287-07710.md
Post by: satoshi on August 05, 2010, 05:49:43 PM
Quote from: bytemaster on August 05, 2010, 04:46:52 PM
Right now the transaction fee address is left “blank” and the block
generator fills it out.
Now you would fill it in with the address of the person you are
asking to build the block.
If you’re only going to have one person work on building the block,
that could take days. Oh, do you mean send a different variation to each
node with the tx fee written to them?
The way it is now, it’s whoever builds this gets it.
If we needed to, we could have a BitTorrent-esque tit-for-tat for
transaction broadcast. Relay paying transactions to me, or I won’t relay
them to you. It probably won’t be an actual problem though. It only
takes one node relaying like it should to cancel out 7 others greedily
not relaying.
Re: A proposal for a semi-automated Escrow mechanism
Bitcoin Forum post — August 05, 2010 — source: 0645-07712.md
Post by: satoshi on August 05, 2010, 06:08:30 PM
A transaction can be written that requires two signatures to spend it
next. You write a payment that requires the signature of both the
recipient and the sender to spend it. To release the escrow, you give
the recipient the signature for your half, or the payee can return it by
giving you his signed half. There’s no mediator in this simple case. The
recourse is to refuse to ever release it, essentially burning the
money.
Bitcoin Forum post — August 07, 2010 — source: 0723-08103.md
Post by: satoshi on August 07, 2010, 04:28:17 PM
Once you get away from a system where each node’s influence is
proportional to their CPU power, then what else do you use to determine
who is (approximately) one person?
Bitcoin Forum post — August 07, 2010 — source: 0721-08114.md
Post by: satoshi on August 07, 2010, 05:46:09 PM
Last edit: August 07, 2010, 06:17:14 PM by satoshi
It’s the same situation as gold and gold mining. The marginal cost of
gold mining tends to stay near the price of gold. Gold mining is a
waste, but that waste is far less than the utility of having gold
available as a medium of exchange.
I think the case will be the same for Bitcoin. The utility of the
exchanges made possible by Bitcoin will far exceed the cost of
electricity used. Therefore, not having Bitcoin would be the net
waste.
Quote from: gridecon on August 06, 2010, 04:48:00 PM
As an overall point, I also do not agree with the idea that the very
high computational burden of coin generation is in fact a necessity of
the current system. As I understand it, currency creation is
fundamentally metered by TIME - and if that is the fundamental
controlling variable, what is the need for everyone to “roll as many
dice as posible” within that given time period? The “chain of proof” for
coin ownership and transactions doesn’t depend on the method for
spawning coins.
Each node’s influence on the network is proportional to its CPU
power. The only way to show the network how much CPU power you have is
to actually use it.
If there’s something else each person has a finite amount of that we
could count for one-person-one-vote, I can’t think of it. IP addresses…
much easier to get lots of them than CPUs.
I suppose it might be possible to measure CPU power at certain times.
For instance, if the CPU power challenge was only run for an average of
1 minute every 10 minutes. You could still prove your total power at
given times without running it all the time. I’m not sure how that could
be implemented though. There’s no way for a node that wasn’t present at
the time to know that a past chain was actually generated in a duty
cycle with 9 minute breaks, not back to back.
Proof-of-work has the nice property that it can be relayed through
untrusted middlemen. We don’t have to worry about a chain of custody of
communication. It doesn’t matter who tells you a longest chain, the
proof-of-work speaks for itself.
Re: A proposal for a semi-automated Escrow mechanism
Bitcoin Forum post — August 07, 2010 — source: 0645-08137.md
Post by: satoshi on August 07, 2010, 08:04:59 PM
Quote from: jgarzik on August 05, 2010, 07:00:30 PM
Due to that recourse, it is unlikely to be used as an escrow
mechanism :)
Really? Do you think people won’t be able to understand the benefit?
(If your response is an argument that there’s no benefit at all, I guess
that will reinforce the case that people won’t be able to understand
it.)
Bitcoin Forum post — August 07, 2010 — source: 0750-08140.md
Post by: satoshi on August 07, 2010, 08:13:52 PM
Here’s an outline of the kind of escrow transaction that’s possible
in software. This is not implemented and I probably won’t have time to
implement it soon, but just to let you know what’s possible.
The basic escrow: The buyer commits a payment to escrow. The seller
receives a transaction with the money in escrow, but he can’t spend it
until the buyer unlocks it. The buyer can release the payment at any
time after that, which could be never. This does not allow the buyer to
take the money back, but it does give him the option to burn the money
out of spite by never releasing it. The seller has the option to release
the money back to the buyer.
While this system does not guarantee the parties against loss, it
takes the profit out of cheating.
If the seller doesn’t send the goods, he doesn’t get paid. The buyer
would still be out the money, but at least the seller has no monetary
motivation to stiff him.
The buyer can’t benefit by failing to pay. He can’t get the escrow
money back. He can’t fail to pay due to lack of funds. The seller can
see that the funds are committed to his key and can’t be sent to anyone
else.
Now, an economist would say that a fraudulent seller could start
negotiating, such as “release the money and I’ll give you half of it
back”, but at that point, there would be so little trust and so much
spite that negotiation is unlikely. Why on earth would the fraudster
keep his word and send you half if he’s already breaking his word to
steal it? I think for modest amounts, almost everyone would refuse on
principle alone.
Bitcoin Forum post — August 07, 2010 — source: 0648-08145.md
Post by: satoshi on August 07, 2010, 09:16:01 PM
Quote from: impossible7 on August 06, 2010, 11:37:20 AM
CRITICAL_BLOCK is a macro that contains a for loop. The assertion
failure indicates that break has been called inside the body of the
loop. The only break statement in this block is in line 2762. In the
original source file, there is no break statement in this critical
block. I think you must remove lines 2759-2762. The is nothing like that
in the original main.cpp.
Sorry about that. CRITICAL_BLOCK isn’t perfect. You have to be
careful not to break or continue out of it. There’s an assert that
catches and warns about break. I can be criticized for using it, but the
syntax would be so much more bloated and error prone without it.
Is there a chance the SSE2 code is slow on Intel because of some
quirk that could be worked around? For instance, if something works but
is slow if it’s not aligned, or thrashing the cache, or one type of
instruction that’s really slow? I’m not sure how available it is, but I
think Intel used to have a profiler for profiling on a per instruction
level. I guess if tcatm doesn’t have a system with the slow processor to
test with, there’s not much hope. But it would be really nice if this
was working on most CPUs.
Bitcoin Forum post — August 09, 2010 — source: 0753-08388.md
Post by: satoshi on August 09, 2010, 06:50:41 PM
Last edit: August 09, 2010, 07:08:10 PM by satoshi
I found that SSE2 only added a slight 2% speedup, which didn’t seem
worth the incompatibility. I was trying to take the safer option.
It doesn’t look to me like Crypto++ could be deciding whether to use
SSE2 at runtime. There’s one place where it detects SSE2 for deciding
some block count parameter, but the SSE2 stuff is all #ifdef at compile
time and I can’t see how that would switch at runtime. Maybe I’m not
looking in the right place.
Should we enable SSE2 in all the makefiles? It seems like we must in
case someone compiles with 64-bit.
I will recompile the 64-bit part of the Linux 0.3.8 release.
Bitcoin Forum post — August 09, 2010 — source: 0765-08402.md
Post by: satoshi on August 09, 2010, 07:46:58 PM
When we switched to Crypto++ 5.6.0 SHA-256 in version 0.3.6,
generation got broken on the Linux 64-bit build. Version 0.3.8.1 is on
SourceForge with the 64-bit binary updated.
Re: What could be the transition plan to Y2038 compliant Bitcoin?
Bitcoin Forum post — August 09, 2010 — source: 0760-08413.md
Post by: satoshi on August 09, 2010, 08:13:26 PM
unsigned int is good until 2106. Surely the network
will have to be totally revamped at least once by then.
There should not be any signed int. If you’ve found a signed int
somewhere, please tell me (within the next 25 years please) and I’ll
change it to unsigned int.
Bitcoin Forum post — August 09, 2010 — source: 0766-08424.md
Post by: satoshi on August 09, 2010, 08:58:45 PM
SVN rev 125:
- Always make 8 outbound connections even if have 8 inbound
- Limit outbound connections to one per a.b.?.? range
- Switch -maxconnections=#
I added the (currently undocumented) switch -maxconnections=#. You
shouldn’t use it unless you need to because your router can’t maintain a
lot of connections, then try -maxconnections=30.
I haven’t really tested -maxconnections much, could someone test
it?
Bitcoin Forum post — August 09, 2010 — source: 0721-08431.md
Post by: satoshi on August 09, 2010, 09:28:39 PM
The heat from your computer is not wasted if you need to heat your
home. If you’re using electric heat where you live, then your computer’s
heat isn’t a waste. It’s equal cost if you generate the heat with your
computer.
If you have other cheaper heating than electric, then the waste is
only the difference in cost.
If it’s summer and you’re using A/C, then it’s twice.
Bitcoin generation should end up where it’s cheapest. Maybe that will
be in cold climates where there’s electric heat, where it would be
essentially free.
Bitcoin Forum post — August 11, 2010 — source: 0770-08637.md
Post by: satoshi on August 11, 2010, 12:14:22 AM
This is a very interesting topic. If a solution was found, a much
better, easier, more convenient implementation of Bitcoin would be
possible.
Originally, a coin can be just a chain of signatures. With a
timestamp service, the old ones could be dropped eventually before
there’s too much backtrace fan-out, or coins could be kept individually
or in denominations. It’s the need to check for the absence of
double-spends that requires global knowledge of all transactions.
The challenge is, how do you prove that no other spends exist? It
seems a node must know about all transactions to be able to verify that.
If it only knows the hash of the in/outpoints, it can’t check the
signatures to see if an outpoint has been spent before. Do you have any
ideas on this?
It’s hard to think of how to apply zero-knowledge-proofs in this
case.
We’re trying to prove the absence of something, which seems to
require knowing about all and checking that the something isn’t
included.
Bitcoin Forum post — August 11, 2010 — source: 0750-08649.md
Post by: satoshi on August 11, 2010, 01:30:02 AM
Quote from: jgarzik on August 10, 2010, 06:53:57 PM
Ask some real-world business owners if they want to tell their
customers about the chance of the money being lost forever,
unrecoverable by either party. That makes it sound like it might somehow
get lost and the parties can’t get it even if they want to
cooperate.
When you pay for something up front, you can’t get it back either.
Consumers seem comfortable with that. It’s no worse than that.
Either party always has the option to release it to the other.
Quote from: nelisky on August 10, 2010, 08:20:36 PM
But the money burning solution, while great at preventing
economically viable fraud, does nothing to prevent revenge and actually
makes everyone loose if one side is dishonest. I would certainly not
endorse that.
Then you must also be against the common system of payment up front,
where the customer loses.
Payment up front: customer loses, and the thief gets the money.
Simple escrow: customer loses, but the thief doesn’t get the money
either.
Are you guys saying payment up front is better, because at least the
thief gets the money, so at least someone gets it?
Imagine someone stole something from you. You can’t get it back, but
if you could, if it had a kill switch that could be remote triggered,
would you do it? Would it be a good thing for thieves to know that
everything you own has a kill switch and if they steal it, it’ll be
useless to them, although you still lose it too? If they give it back,
you can re-activate it.
Imagine if gold turned to lead when stolen. If the thief gives it
back, it turns to gold again.
It still seems to me the problem may be one of presenting it the
right way. For one thing, not being so blunt about “money burning” for
the purposes of game theory discussion. The money is never truly burned.
You have the option to release it at any time forever.
Bitcoin Forum post — August 11, 2010 — source: 0770-08798.md
Post by: satoshi on August 11, 2010, 09:07:59 PM
Still thinking this idea through…
The only job the network needs to do is to tell whether a spend of an
outpoint is the first or not.
If we’re willing to have clients keep the history for their own
money, then some of the information may not need to be stored by the
network, such as:
- the value
- the association of inpoints and outpoints in one transaction
The network would track a bunch of independent outpoints. It doesn’t
know what transactions or amounts they belong to. A client can find out
if an outpoint has been spent, and it can submit a satisfying inpoint to
mark it spent. The network keeps the outpoint and the first valid
inpoint that proves it spent. The inpoint signs a hash of its associated
next outpoint and a salt, so it can privately be shown that the
signature signs a particular next outpoint if you know the salt, but
publicly the network doesn’t know what the next outpoint is.
I believe the clients would have to keep the entire history back to
the original generated coins. Someone sending a payment would have to
send data to the recipient, as well as still communicating with the
network to mark outpoints spent and check that the spend is the first
spend. Maybe the data transfer could be done as an e-mail
attachment.
The fact that clients have to keep the entire history reduces the
privacy benefit. Someone handling a lot of money still gets to see a lot
of transaction history. The way it retrospectively fans out, they might
end up seeing a majority of the history. Denominations could be made
granular to limit fan-out, but a business handling a lot of money might
still end up seeing a lot of the history.
Bitcoin Forum post — August 11, 2010 — source: 0782-08803.md
Post by: satoshi on August 11, 2010, 09:46:51 PM
Quote from: sirius-m on August 11, 2010, 02:01:53 AM
I added to the FAQ the warning to back up after each transaction. Is
it necessary btw to stop the client before making a backup? That’s a bit
inconvenient. Automatic backups would be useful indeed.
You can get away with backing up without stopping the client if you
don’t do anything or receive a payment within a few seconds before the
backup. (like 5 seconds)
Quote from: gridecon on August 11, 2010, 08:46:08 PM
Wait, I’m confused again. I thought the essence of the surprise was
that Bitcoin is programmed to “empty your wallet” for EACH
transaction.
No, it doesn’t usually empty your wallet with each transaction. It
uses the smallest set of coins it can find to add up to near the amount.
In this case, unfortunately, his wallet had a single 9000 BTC bill in
it, and it had to break it to get 1 BTC and 8999 BTC change.
Re: Where is the separate discussion devoted to possible Bitcoin weaknesses.
Bitcoin Forum post — August 11, 2010 — source: 0788-08804.md
Post by: satoshi on August 11, 2010, 10:40:25 PM
It doesn’t have to be such a breaking change. New nodes could accept
old transactions for a long time until most nodes have already upgraded
before starting to refuse transactions without PoW. Or, they could
always accept old transactions, but only a limited number per time
period.
I’ve thought about PoW on transactions many times, but usually I end
up thinking a 0.01 transaction fee is essentially similar and better.
0.01 is basically a proof of work, but not wasted. But if the problem is
validating loads of transactions, then PoW could be checked faster.
A more general umbrella partial solution would be to implement the
idea where an unlikely dropoff in blocks received is detected. Then an
attacker would still need a substantial portion of the network’s power
to benefit from a DoS attack.
Quote from: gavinandresen on August 11, 2010, 04:10:56 PM
Bitcoin’s p2p network is subject to various kinds of denial of
service attacks.
There, I said it.
+1
Any demonstration tests at this point would only show what we already
know, and divert dev time from strengthening the system to operational
fire fighting.
Bitcoin Forum post — August 11, 2010 — source: 0287-08810.md
Post by: satoshi on August 11, 2010, 11:28:50 PM
It would be nice to keep the blk*.dat files small as long as we
can.
The eventual solution will be to not care how big it gets.
But for now, while it’s still small, it’s nice to keep it small so
new users can get going faster. When I eventually implement client-only
mode, that won’t matter much anymore.
There’s more work to do on transaction fees. In the event of a flood,
you would still be able to jump the queue and get your transactions into
the next block by paying a 0.01 transaction fee. However, I haven’t had
time yet to add that option to the UI.
Scale or not, the test network will react in the same ways, but with
much less wasted bandwidth and annoyance.
Bitcoin Forum post — August 12, 2010 — source: 0790-08814.md
Post by: satoshi on August 12, 2010, 12:02:06 AM
Quote from: dkaparis on August 11, 2010, 11:00:16 PM
There is this piece of code in headers.h:
#ifdef __WXMAC_OSX__
#define __WXMAC__ 1
#define __WXOSX__ 1
#define __BSD__ 1
#endif
#endif
That code was a bad idea anyway, I’m deleting it. Any Mac code should
only use __WXMAC_OSX__, not __WXMAC__ or __WXOSX__, and we should stop
using __BSD__.
Bitcoin Forum post — August 12, 2010 — source: 0770-08836.md
Post by: satoshi on August 12, 2010, 02:46:56 AM
Quote from: Red on August 12, 2010, 01:10:19 AM
Quote from: satoshi on August 11, 2010, 09:07:59 PM
I believe the clients would have to keep the entire history back to
the original generated coins. The fact that clients have to keep the
entire history reduces the privacy benefit.
I thought this too at first. But then I convinced myself
otherwise.
Are you back to talking about the existing Bitcoin system here?
I was talking about in the hypothetical system I was describing, if
the network doesn’t know the values and lineage of the transactions,
then it can’t verify them and vouch for them, so the clients would have
to keep the history all the way back.
If a client wasn’t present until recently, the two ways to convince
it that a transaction has a valid past is:
Show it the entire history back to the original generated
coin.
Show it a history back to a thoroughly deep block, then trust
that if so many nodes all said the history up to then was correct then
it must be true.
But if the network didn’t know all the values and lineage of the
transactions, it couldn’t do 2), I don’t think.
Bitcoin Forum post — August 12, 2010 — source: 0691-08922.md
Post by: satoshi on August 12, 2010, 09:34:44 PM
True, there would probably be someone with a dial-up modem or
satellite dish internet. Rarer would be someone who has both that and
the wired internet that has the outage, but if it’s a big enough segment
to matter, out of a million people there’s bound to be a multi-home
geek.
ISP network cuts are just your local area. If you still have
communication with the rest of your area, it would probably be something
like 1/1000 of the world or less. Block generation in the segment would
take several hours per block.
I favour the plan to monitor if the frequency of blocks received
drops too slow. That covers a large range of possibilities.
Bitcoin Forum post — August 12, 2010 — source: 0648-08929.md
Post by: satoshi on August 12, 2010, 10:07:23 PM
Last edit: August 13, 2010, 02:53:16 AM by satoshi
That big of a difference in speed, by a factor of 4 or 6, feels like
it’s likely to be some quirky weak spot or instruction that the old chip
is slow with. Unless it’s a touted feature of the i5 that they made SSE2
six times faster.
A quick summary:
Xeon Quad 41% slower
Core 2 Duo 55% slower
Core 2 Duo same (vess)
Core 2 Quad 50% slower
Core i5 200% faster (nelisky)
Core i5 100% faster (vess)
AMD Opteron 105% faster
aceat64:
My system went from ~7100 to ~4200.
This particular system has dual Intel Xeon Quad-Core CPUs (E5335) @
2.00GHz.
impossible7:
on an Intel Core 2 Duo T7300 running x86_64 linux it was 55% slower
compared to the stock version (r121)
nelisky:
My Core2Quad (Q6600) slowed down 50%,
my i5 improved ~200%,
impossible7:
on an AMD Opteron 2374 HE running x86_64 linux I got a 105%
improvement (!)
Bitcoin Forum post — August 13, 2010 — source: 0795-08960.md
Post by: satoshi on August 13, 2010, 03:15:23 AM
No, that’s not what it is.
-paytxfee allows you to include a transaction fee with your
transactions. If transaction confirmations become slow, you can get
priority by using “-paytxfee=0.01”. Any transactions you send would cost
an extra 0.01. There’s no reason to use more than 0.01.
It’s just there in case we need it. It probably won’t be needed, and
it can be explained more if we do.
Bitcoin Forum post — August 13, 2010 — source: 0691-09041.md
Post by: satoshi on August 13, 2010, 05:09:27 PM
Quote
But there will be no irc server to bootstrap from.
Which doesn’t matter because you can’t access sourceforge to download
the software either.
If you’ve ever been connected before, you don’t need IRC to bootstrap
anymore. Even if you haven’t, you can bootstrap from seed nodes. IRC is
completely redundant since 0.3.0.
Bitcoin Forum post — August 13, 2010 — source: 0770-09074.md
Post by: satoshi on August 13, 2010, 07:28:47 PM
I’m not grasping your idea yet. Does it hide any information from the
public network? What is the advantage?
If at least 50% of nodes validated transactions enough that old
transactions can be discarded, then everyone saw everything and could
keep a record of it.
Can public nodes see the values of transactions? Can they see which
previous transaction the value came from? If they can, then they know
everything. If they can’t, then they couldn’t verify that the value came
from a valid source, so you couldn’t take their generated chain as
verification of it.
Does it hide the bitcoin addresses? Is that it? OK, maybe now I see,
if that’s it.
Crypto may offer a way to do “key blinding”. I did some research and
it was obscure, but there may be something there. “group signatures” may
be related.
What we need is a way to generate additional blinded variations of a
public key. The blinded variations would have the same properties as the
root public key, such that the private key could generate a signature
for any one of them. Others could not tell if a blinded key is related
to the root key, or other blinded keys from the same root key. These are
the properties of blinding. Blinding, in a nutshell, is x = (x *
large_random_int) mod m.
When paying to a bitcoin address, you would generate a new blinded
key for each use.
Then you need to be able to sign a signature such that you can’t tell
that two signatures came from the same private key. I’m not sure if
always signing a different blinded public key would already give you
this property. If not, I think that’s where group signatures comes in.
With group signatures, it is possible for something to be signed but not
know who signed it.
As an example, say some unpopular military attack has to be ordered,
but nobody wants to go down in history as the one who ordered it. If 10
leaders have private keys, one of them could sign the order and you
wouldn’t know who did it.
Bitcoin Forum post — August 15, 2010 — source: 0648-09359.md
Post by: satoshi on August 15, 2010, 03:40:29 AM
On both MinGW GCC 4.4.1 and 4.5.0 I have it working with test.cpp but
SIGSEGV when called by BitcoinMiner. So now it doesn’t look like it’s
the version of GCC, it’s something else, maybe just the luck of how the
stack is aligned.
I have it working fine on GCC 4.3.3 on Ubuntu 32-bit.
I found the problem with Crypto++ on MinGW 4.5.0. Here’s the patch
for that:
Please report back your CPU and results! I think it’s pretty clear
that Core 2 and lower are slower, i5 faster. I don’t think we’ve heard
any i7 results yet. We need to know about the different models of AMD or
other less common CPUs.
Bitcoin Forum post — August 15, 2010 — source: 0813-09454.md
Post by: satoshi on August 15, 2010, 04:37:16 PM
Last edit: August 15, 2010, 04:50:16 PM by satoshi
Some places where generation will gravitate to:
places where it’s cheapest or free
people who want to help for idealogical reasons
people who want to get some coins without the inconvenience of
doing a transaction to buy them
There are legitimate places where it’s free. Generation is basically
free anywhere that has electric heat, since your computer’s heat is
offsetting your baseboard electric heating. Many small flats have
electric heat out of convenience.
How expensive is heating oil? With the price of oil so high, if it’s
actually more expensive than electric, then generating would have
negative cost.
There’s also kids putting it on their parent’s power bill, employees
their employer, botnets, etc.
Case 3 comes into play for small amounts. The overhead of doing an
exchange doesn’t make sense if you just need a small bit of pocket
change for incidental micropayments. I think this is a nice advantage vs
fiat currency, instead of all the seigniorage going to one big entity,
let it go in convenience amounts to people who need to scrape up a small
amount of change.
Bitcoin Forum post — August 15, 2010 — source: 0806-09475.md
Post by: satoshi on August 15, 2010, 06:11:41 PM
Quote from: jgarzik on August 15, 2010, 05:46:27 PM
the extended-help might have been based on my idea, but the code was
somewhat different.
The idea was the main part. When you posted your patch, I realized it
should have been done that way instead of “-?”. I always had
reservations about “-?” because it intrudes on the possible parameter
values, and the help response is based on the version of the caller
instead of the server.
Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2
Bitcoin Forum post — August 15, 2010 — source: 0820-09483.md
Post by: satoshi on August 15, 2010, 06:43:27 PM
I just uploaded a quick build so testers can check if I built it
right. (I don’t have an i5 or AMD) If it checks out, I’ll put together
the full package and do all the release stuff.
Bitcoin Forum post — August 15, 2010 — source: 0823-09531.md
Post by: satoshi on August 15, 2010, 09:06:45 PM
It would help if people stop generating. We will probably need to
re-do a branch around the current one, and the less you generate the
faster that will be.
A first patch will be in SVN rev 132. It’s not uploaded yet. I’m
pushing some other misc changes out of the way first, then I’ll upload
the patch for this.
Bitcoin Forum post — August 15, 2010 — source: 0823-09539.md
Post by: satoshi on August 15, 2010, 09:23:55 PM
Once you have an update, you could download knightmb’s block chain.
You’ll want one that’s old enough that it ends before block 74000 so the
most recent security lockin will check it. Can someone find the link for
that?
Bitcoin Forum post — August 15, 2010 — source: 0823-09548.md
Post by: satoshi on August 15, 2010, 09:40:19 PM
Patch is uploaded to SVN rev 132!
For now, recommended steps:
Shut down.
Download knightmb’s blk files. (replace your blk0001.dat and
blkindex.dat files)
Upgrade.
It should start out with less than 74000 blocks. Let it
redownload the rest.
If you don’t want to use knightmb’s files, you could just delete your
blk*.dat files, but it’s going to be a lot of load on the network if
everyone is downloading the whole block index at once.
Bitcoin Forum post — August 15, 2010 — source: 0823-09573.md
Post by: satoshi on August 15, 2010, 10:58:08 PM
Don’t update the block chain download. When you take someone’s block
chain download, you don’t want it right up to the end. A somewhat old
one is better so it can download and verify the most recent blocks.
tcatm’s 4-way SSE2 SHA-256 is in the file sha256.cpp and already
uploaded a few revs ago.
I just now uploaded rev 134 which is the makefile.unix that enables
building with it on Linux. If you build rev 134 on Linux now you’ll get
the -4way switch.
If you have problems building because of it, then edit makefile.unix
and:
- remove -DFOURWAYSSE2
- remove obj/sha256.o from the end of these lines:
Bitcoin Forum post — August 15, 2010 — source: 0823-09576.md
Post by: satoshi on August 15, 2010, 11:17:24 PM
Quote from: knightmb on August 15, 2010, 10:59:04 PM
[edit] Just saw your post, I’ll build one to less than 74,000 then,
should at least save you technical people a few minutes of downloading
the new chain. ;)
Just leave the old one alone! Older is better. What block number is
it? Anywhere from 60000-74000 is good. The one that you’ve had available
for a while has been vetted and is the best choice.
Bitcoin Forum post — August 15, 2010 — source: 0823-09584.md
Post by: satoshi on August 15, 2010, 11:36:10 PM
Starting at 67000 is perfect.
Yeah, at the moment you’ll stop at 74638. It should start slowly
creeping up as more nodes upgrade and generate.
Linux build links below.
The Linux version includes tcatm’s 4-way SSE2 SHA-256 that makes
generating faster on i5 and AMD CPU’s. Use the “-4way” switch to enable
it and check if it’s faster for you.
The Linux version includes tcatm’s 4-way SSE2 SHA-256 that makes
generating faster on i5, i7 (with hyperthreading) and AMD CPU’s. Try the
“-4way” switch to enable it and check if it’s faster for you.
It is no longer necessary to delete blk*.dat. The good block chain
has overtaken the bad block chain, so you can just upgrade and it’ll
automatically reorg away the bad block chain.
Bitcoin Forum post — August 16, 2010 — source: 0828-09608.md
Post by: satoshi on August 16, 2010, 12:28:28 AM
I suspect there’s some difficulty receiving blocks if all the nodes
you’re connected to are 0.3.9 or lower. We need enough of us so that at
least one node you connect to will be 0.3.10. The problem will start to
go away when we make up more than 1/8th of the network.
It’ll help if you port forward so you can get lots of
connections.
Bitcoin Forum post — August 16, 2010 — source: 0828-09612.md
Post by: satoshi on August 16, 2010, 12:37:20 AM
For now, can some people running 0.3.10 with static IP who can
receive incoming connections post their IP? Then we can -addnode= them
and make sure to connect to at least one 0.3.10 node.
Bitcoin Forum post — August 16, 2010 — source: 0823-09623.md
Post by: satoshi on August 16, 2010, 01:00:45 AM
Quote from: Ground Loop on August 16, 2010, 12:29:55 AM
Question about fallout: I had a transaction that I
submitted after the bad block, using the bad block chain.
What is the status of that transaction? From what I can tell, my
(updated) sending client wallet shows the deducted amount.
Will it get reincorporated into the fixed chain, and will the
recipient be able to spend it?
Right, it will get reincorporated into the fixed chain. The
transaction won’t disappear, it’ll still be visible on both sides, but
the confirmation count will jump back to 0 and start counting up
again.
It’s only if you generated a block in the bad chain after block 74638
that the 50 BTC from that will disappear. Any blocks in the bad chain
wouldn’t have matured yet.
Bitcoin Forum post — August 16, 2010 — source: 0823-09628.md
Post by: satoshi on August 16, 2010, 01:12:05 AM
Quote from: trebronics on August 16, 2010, 01:02:35 AM
Most people running clients are not reading this message thread. So…
Silly questions:
How will this continue to affect version 3.8.1 (pre-catastrophe)
clients with bad block chain?
How will this affect clients that upgrade to 3.8.10 but don’t remove
their block chain files?
Once more than 50% of the node power is upgraded and the good
chain overtakes the bad, the 0.3.10 nodes will make it hard for any bad
transactions to get any confirmations.
If you didn’t remove your blk*.dat files, you’re not helping to
contribute to that 50%, and you’ll still show bad transactions until the
good chain overtakes the bad chain.
Bitcoin Forum post — August 16, 2010 — source: 0823-09642.md
Post by: satoshi on August 16, 2010, 02:16:10 AM
The bad chain is also slowed down as more nodes upgrade.
We’ve already generated 14 blocks since 74638. The builds of 0.3.10
were uploaded about 2 and 3 hours ago. Of the nodes I’m connected to,
more than half are already 0.3.10. I would say we probably already have
more power than the bad chain.
Bitcoin Forum post — August 16, 2010 — source: 0823-09648.md
Post by: satoshi on August 16, 2010, 02:38:21 AM
On Windows, findstr /c:“version message” debug.log
It looks like the bad chain was on block 74678 recently. Can’t wait
to overtake it.
On the stats at http://nullvoid.org/bitcoin/statistix.php there’s been 5
blocks per hour in the last 3 hours. We had a difficulty adjustment
about a day ago that should have put it back to 6 blocks per hour.
Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2
Bitcoin Forum post — August 16, 2010 — source: 0820-09655.md
Post by: satoshi on August 16, 2010, 02:57:57 AM
Quote from: tcatm on August 16, 2010, 12:43:39 AM
I propose to compile sha256.cpp with -O3 -march=amdfamk10 (will work
on 32bit and 64bit) as only CPUs supporting this instruction set (AMD
Phenom, Intel i5 and newer) benefit from -4way and it’ll improve
performance by ~9%.
GCC 4.3.3 doesn’t support -march=amdfamk10. I get:
sha256.cpp:1: error: bad value (amdfamk10) for -march= switch
Quote from: NewLibertyStandard on August 16, 2010, 01:49:01 AM
With 4way, I get significantly better performance when I have all my
virtual cores enabled. I think I get about the same amount of hashes
when hyper threading is turned off with or without 4way.
Hey, you may be onto something!
hyperthreading didn’t help before because all the work was in the
arithmetic and logic units, which the hyperthreads share.
tcatm’s SSE2 code must be a mix of normal x86 instructions and SSE2
instructions, so while one is doing x86 code, the other can do SSE2.
How much of an improvement do you get with hyperthreading?
Bitcoin Forum post — August 16, 2010 — source: 0823-09734.md
Post by: satoshi on August 16, 2010, 12:59:38 PM
It looks like we overtook the bad chain somewhere around 74689. 0.3.9
and lower nodes have been responding with the current block number for
some hours now.
That means it’s no longer necessary to delete blk*.dat before
upgrading. You can just upgrade and it’ll reorg away the bad block
chain.
Bitcoin Forum post — August 16, 2010 — source: 0832-09754.md
Post by: satoshi on August 16, 2010, 03:25:54 PM
Last edit: August 16, 2010, 08:06:58 PM by satoshi
That’s a difficult approach.
We need to cause a reorg, which will disconnect the invalid
chain.
This is code that will rarely ever get tested, and is fairly
intricate, so something simple and safe is best.
Here’s what I was thinking of. (I haven’t tested this yet) It checks
all the blocks in the main chain. If it finds a bad one, it sets all
that chain’s bnChainWork to 0 so it can’t win best chain again, and it
reduces best chain work to the fork level so any new block after the
fork will cause a reorg. (It can’t change pindexBest without actually
doing a reorg)
This isn’t perfect yet. It still needs to receive one valid block to
trigger the reorg.
It would probably be possible to initiate an AddToBlockIndex or
Reorganize after the check, but it would require a lot more careful
attention. I probably should break out part of AddToBlockIndex that sets
the new best block. I’ll probably end up doing that instead of the code
below.
Code:
bool CTxDB::LoadBlockIndex()
{
...
// Verify blocks in the main chain
vector<CBlockIndex*> vChain;
for (CBlockIndex* pindex = pindexBest; pindex && pindex->pprev; pindex = pindex->pprev)
{
vChain.push_back(pindex);
CBlock block;
if (!block.ReadFromDisk(pindex))
return error("LoadBlockIndex() : block.ReadFromDisk failed");
if (!block.CheckBlock())
{
bnBestChainWork = pindex->pprev->bnChainWork;
foreach(CBlockIndex* pindex2, vChain)
pindex2->bnChainWork = 0;
}
}
return true;
}
Bitcoin Forum post — August 16, 2010 — source: 0837-09757.md
Post by: satoshi on August 16, 2010, 03:59:25 PM
I’d like to reduce the number of blocks displayed in the status bar
by 1. When you first load the program, it’ll display 0 blocks instead of
1:
“0 connections 0 blocks 0 transactions”
It’s always been “nBestHeight + 1” because it’s counting the genesis
block. Technically, yes, the genesis block is a block. It’s a hardcoded
block that you start out with. You can’t not have the genesis block.
Maybe think of it as a reference coin that you measure other coins
against. The block count people are looking for is the number of blocks
they’ve downloaded.
The main benefit is that blocks will be equal to the block number of
the current best block. If blocks is 10, then the highest block number
you have is 10. It means you have block 10 and you don’t have block
11.
It would reduce the confusion we had here:
Quote from: kencausey on August 15, 2010, 11:45:26 PM
Quote from: davidonpda on August 15, 2010, 11:31:37 PM
… It already is on block 74638. I assume that means that block is now
a good one?
I had some confusion on this myself and got clarification in
#bitcoin-dev:
The bad block was number 74638, the last good one was 74637. The
numbers start at 0, so when your client shows there are 74638 blocks
then that means you have up to block number 74637, the last good
one.
Bitcoin Forum post — August 16, 2010 — source: 0832-09775.md
Post by: satoshi on August 16, 2010, 05:08:02 PM
Last edit: August 16, 2010, 06:50:13 PM by satoshi
Quote from: satoshi on August 16, 2010, 03:25:54 PM
It would probably be possible to initiate an AddToBlockIndex or
Reorganize after the check, but it would require a lot more careful
attention. I probably should break out part of AddToBlockIndex that sets
the new best block. I’ll probably end up doing that instead of the code
below.
This is what I ended up doing in SVN rev 139.
Instead of deleting the bad chain, I added an extra CheckBlock to
ConnectBlock so bad blocks can’t get back into the best chain once
they’re kicked out.
Bitcoin Forum post — August 16, 2010 — source: 0841-09813.md
Post by: satoshi on August 16, 2010, 08:07:46 PM
SVN rev 139 does a basic check of the block chain after loading.
With this we wouldn’t have needed to delete blk*.dat, it would have
automatically done a reorg back to the fork. There wasn’t time to do a
careful implementation of this at the time.
It might take longer than we want, since it has to load all the
blocks. If it’s too slow, we could have it only go back to a certain
block number.
Bitcoin Forum post — August 16, 2010 — source: 0834-09816.md
Post by: satoshi on August 16, 2010, 08:20:53 PM
There is no way for the software to automatically know if one chain
is better than another except by the greatest proof-of-work. In the
design it was necessary for it to switch to a longer chain no matter how
far back it has to go.
The only exception to that is the manual checkpoints I’ve added. If
it weren’t for those, it would be able to reorg all the way back to the
first block.
Bitcoin Forum post — August 16, 2010 — source: 0823-09841.md
Post by: satoshi on August 16, 2010, 10:54:55 PM
Un-upgraded nodes have the correct chain most of the time, but they
are still trying to include the overflow transaction in every block, so
they’re continually trying to fork and generate invalid blocks. If an
old version node is restarted, its transaction pool is emptied, so it
may generate valid blocks for a while until the transaction gets
broadcast again. 0.3.9 and lower nodes still must upgrade.
The SVN now has the code we needed to automatically reorg the block
chain without having to delete the blk*.dat files manually. I knew I
couldn’t write that code fast and carefully enough yesterday, so I went
with the quick manual option.
Re: Difficulty: More nodes active, or faster nodes?
Bitcoin Forum post — August 18, 2010 — source: 0846-10076.md
Post by: satoshi on August 18, 2010, 06:01:40 PM
The performance numbers posted from a VIA C7’s hardware SHA-256
weren’t astronomical. Only in the 1500 khash/s range. If you think about
it, just because it’s implemented in hardware doesn’t mean it’s crazy
fast. It still has to do all the steps. It’s only if simplifying it down
to single-purpose hardware makes it small enough to fit many in
parallel. That’s not necessarily easy or a given.
Bitcoin Forum post — August 18, 2010 — source: 0841-10082.md
Post by: satoshi on August 18, 2010, 06:28:28 PM
In the next SVN rev, I’ll make it only go back to the last checkpoint
at block 74000. If we need to correct a problem in the future, we can
always make sure it goes back at least as far back as the problem. Also,
I’m adding code to verify the block index, which means the proof-of-work
chain is checked.
Still, the system won’t be entirely secure against your blk*.dat
files. You are trusting someone if you use a copy of their blk
files.
Re: Convert Bitcoin to GTK: Yes? No? wx is better?
Bitcoin Forum post — August 19, 2010 — source: 0867-10272.md
Post by: satoshi on August 19, 2010, 06:44:36 PM
Quote from: BioMike on August 19, 2010, 08:05:18 AM
WxWidgets is not really a problem. My problem is the version that is
used (2.9), which is considered unstable by many distro packagers
(although the WxWidgets devs say it isn’t). On the other side, as far as
I know WxWidgets uses gtk under Linux for drawing the whole stuff and
makes it for the bitcoins devs easy to make things cross platform.
wxWidgets 2.9 is their first UTF-8 version. We are UTF-8 on all
platforms including Windows.
The distro packages of 2.8 are UTF-16, so they just trip people up.
People had endless build problems with 2.8 and its wxString UTF-16/ANSI
conditional build options until we standardized on 2.9. Also, to use
2.8, we were using ANSI, which was just a temporary stopgap until
wxWidgets supported UTF-8.
This is a problem that will solve itself. With time, 2.9 will become
a more mainline release.
Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Bitcoin Forum post — August 19, 2010 — source: 0820-10281.md
Post by: satoshi on August 19, 2010, 07:07:43 PM
Quote from: Ground Loop on August 18, 2010, 11:14:26 PM
Any non-Mac i5 love?
Windows i5 64-bit got slower here.
That’s the first I’ve heard anyone say i5 was slower. Everyone else
has said 4way was faster on i5. Moreso with hyperthreading enabled.
Quote from: nelisky on August 18, 2010, 11:02:25 PM
And i5, at least on my macbookpro
Good, so I take it that’s a confirmation that it’s working on Mac as
well?
Laszlo told me he did compile in the -4way stuff on Mac, so the -4way
switch is also available to try on Mac. I don’t think makefile.osx on
SVN has it yet, just the built version.
Need a post writing up some things users should know
Bitcoin Forum post — August 19, 2010 — source: 0873-10297.md
Post by: satoshi on August 19, 2010, 08:14:01 PM
I’m not sure what to call it, but we could use a post that lists
these things users should know. If someone has time to write it, here’s
the list:
- Make sure your clock is set correctly.
- Microsoft Security Essentials. This never got written up
proper.
- Warning not to mess around with your wallet.dat file. It’s a
database file, it’s not as simple as you think. In this Beta version, we
haven’t had time to try and tinker-proof it yet. It may not work as
expected if you start swapping it around.
Re: Hypothetical question on lost coins / transfers
Bitcoin Forum post — August 19, 2010 — source: 0870-10300.md
Post by: satoshi on August 19, 2010, 08:28:50 PM
That’s right. You don’t need to be re-broadcasting your transactions
for it to work.
When any node disconnects a fork, it dumps all the transactions from
the fork back into the transaction pool to add to the new chain. The
entire network is making sure to re-integrate your transactions again.
All you should see is that your number of confirmations starts over from
0.
In some types of forks, your transaction would have gotten into both
forks already, so you’re already good either way.
Re: 28 days without generation, i have 4200khash/s
Bitcoin Forum post — August 22, 2010 — source: 0862-10717.md
Post by: satoshi on August 22, 2010, 11:01:02 PM
Search debug.log for “proof-of-work found”. If you find any, then
check for any errors right after that.
Quote from: davidonpda on August 19, 2010, 07:43:01 PM
How big of a margin on the time is allowed for things to work
right.
The margin is 2 hours.
This should be solved in SVN rev 141 and the next release (0.3.11+).
It’ll pop up a message box alerting you if your clock is off by more
than an hour.
Bitcoin Forum post — August 22, 2010 — source: 0898-10722.md
Post by: satoshi on August 22, 2010, 11:55:06 PM
Last edit: August 25, 2010, 03:57:33 PM by satoshi
I’ve been working on writing the alert system. Alerts are broadcast
through the network and apply to a range of version numbers. Alert
messages are signed with a private key that only I have.
Nodes can do two things in response to an alert:
- Put a warning message on the status bar.
- Make the money handling methods of the json-rpc interface return an
error.
In cases like the overflow bug or a fork where users may not be able
to trust received payments, the alert should keep old versions mostly
safe until they upgrade. Manual users should notice the status bar
warning when looking for received payments, and the json-rpc safe mode
stops automated websites from making any more trades until they’re
upgraded.
The json-rpc methods that return errors during an alert are:
Re: tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10
Bitcoin Forum post — August 24, 2010 — source: 0820-11068.md
Post by: satoshi on August 24, 2010, 10:43:56 PM
Quote from: ArtForz on August 21, 2010, 04:56:31 PM
AMD K10: 2 128bit units
intel nehalem: 3 128bit units
This probably explains why hyperthreading increases performance with
-4way. If three SSE2 units is excessive, then hyperthreading would help
keep them all busy.
Bitcoin Forum post — August 24, 2010 — source: 0898-11074.md
Post by: satoshi on August 24, 2010, 11:51:12 PM
Last edit: August 25, 2010, 04:33:12 PM by satoshi
If you’re so paranoid that you’re getting hysterical over this, then
surely you’re paranoid enough that if a warning message displays on the
status bar, you’ll check the website and forum.
I think if another bug like the overflow bug occurs, it’s important
that automated websites stop trading until their admins can check out
what’s going on and decide what to do. If you decide it’s a false alarm
and want to take your chances, you can use the “-disablesafemode”
switch.
Bitcoin Forum post — August 25, 2010 — source: 0898-11150.md
Post by: satoshi on August 25, 2010, 03:17:37 PM
Last edit: August 25, 2010, 04:39:54 PM by satoshi
It can’t do arbitrary actions remotely. Maybe some of you are
responding to other posters who suggested the alert system should do
more?
If there is an alert, the following json-rpc methods return an
error:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel
The remaining 14 methods function as normal.
I believe the safer option should be enabled by default. If you want
your server to keep trading and ignore an alert saying the money its
receiving might be like the money from the overflow bug, then you can
use the switch and not blame anyone else if you lose your money.
Worst case if you leave alerts enabled, your site stops trading until
you upgrade or add the -disablesafemode switch.
Getting surprised by some temporary down time when your node would
otherwise be at risk is better than getting surprised by a thief
draining all your inventory.
Someday when we haven’t found any new bugs for a long time and it has
been thoroughly security reviewed without finding anything, this can be
scaled back. I’m not arguing that this is the permanent way of things
forever. It’s still beta software.
Bitcoin Forum post — August 25, 2010 — source: 0898-11155.md
Post by: satoshi on August 25, 2010, 04:56:15 PM
Last edit: August 25, 2010, 06:05:24 PM by satoshi
Quote from: jimbobway on August 25, 2010, 04:45:22 PM
Quote from: BioMike on August 23, 2010, 05:15:43 AM
@mizerydearia, I think the quote button
is easier to find then the reply one.
So, theoretical this is a first control system where <some
goverment> can arrest satoshi and demand that he hands over his key
(or get it from his computer) and shut down the complete network?
Or is that not possible? How far would <some goverment>
get?
A few rhetorical questions for satoshi:
Can you resist waterboarding?
Can you endure electric shock?
All forms of torture?
Lastly, are you Jack Bauer by any chance? Seriously.
WRT the alert system, who cares? The most the key can do is
temporarily disable six json-rpc commands until the site owners either
add the -disablesafemode switch or upgrade. All nodes keep running and
generating, the network stays up. If I’m not available, any script
kiddie can figure out how to add two characters and make a new version
that disables the alert system. It would be a temporary inconvenience
only.
Quote from: BioMike on August 23, 2010, 05:15:43 AM
So, theoretical this is a first control system where
can arrest satoshi and demand that he hands over his key (or get it from
his computer) and shut down the complete network?
This is what makes me think the people objecting don’t know what
they’re talking about. It can’t “shut down the complete network”.
Bitcoin Forum post — August 25, 2010 — source: 0898-11158.md
Post by: satoshi on August 25, 2010, 05:59:30 PM
Quote from: nelisky on August 25, 2010, 01:28:32 AM
So what kind of warning do admins get from bitcoind? Is there
something we can grep from debug.log? Or will rpc calls raise some
specific error? Is there a way to locally force this to happen, for
unittesting services?
getinfo has a new field that shows any alert messages or other errors
that would be displayed on the status bar.
The rpc methods return a json-rpc error with the error description
“Safe mode:” followed by additional text specified by the alert.
I added the switch “-testsafemode” for you. SVN rev 145.
This stuff is very new and may still be subject to change.
Quote from: mizerydearia on August 25, 2010, 12:11:50 AM
Many switches are intentionally undocumented, like if their
functionality is still under construction or I haven’t settled on their
name yet, or just test code not intended for release.
-4way should eventually be replaced by an auto-detect.
Bitcoin Forum post — August 26, 2010 — source: 0898-11219.md
Post by: satoshi on August 26, 2010, 12:08:12 AM
Quote from: BioMike on August 25, 2010, 06:23:45 PM
Quote from: satoshi on August 25, 2010, 04:56:15 PM
Quote from: BioMike on August 23, 2010, 05:15:43 AM
So, theoretical this is a first control system where <some
goverment> can arrest satoshi and demand that he hands over his key
(or get it from his computer) and shut down the complete network?
Or is that not possible? How far would <some goverment>
get?
This is what makes me think the people objecting don’t know what
they’re talking about. It can’t “shut down the complete network”.
I’ve never objected this change/idea, just asking if this was
possible and to what extent.
What’s wrong with getting informed? ;)
My apologies, your post was indeed a question not a statement.
Bitcoin Forum post — August 26, 2010 — source: 0920-11224.md
Post by: satoshi on August 26, 2010, 12:33:28 AM
Can you provide more details about what removing DB_PRIVATE does?
I can’t remember if I had a specific reason for DB_PRIVATE, or if I
just copied the flags from some example code. Does removing DB_PRIVATE
make it safe for other processes to open the database simultaneously?
That may be an improvement, depending what the side effects are. Does it
substantially reduce performance by making it have to write out every
change immediately or do other coordination? Are there additional
locking or coordination files then? What else changes? You could test by
timing an initial block download with and without DB_PRIVATE, preferably
-connect-ing to a local machine so network isn’t a factor.
Apparently, DB_PRIVATE doesn’t do what you would hope it would do,
which is prevent other processes from being able to open the database.
It still lets them, it just screws up if they do. Another option, if
there’s a way, would be to make it lock the database files so they can’t
be accessed by other processes.
Re: Need a post writing up some things users should know
Bitcoin Forum post — August 26, 2010 — source: 0873-11227.md
Post by: satoshi on August 26, 2010, 12:44:05 AM
Any backup process/procedure would just be a stopgap until there’s
time to properly work on coding solutions in software. We can try to use
words to help the situation until code gets there.
The main backup improvement will be pre-made pool of keys, and a
rescan at load to scrape missed transactions from the block history.
Then a backup will last forward for a long time.
Bitcoin Forum post — August 26, 2010 — source: 0921-11228.md
Post by: satoshi on August 26, 2010, 12:57:40 AM
I started posting in the other topic but I’ll repeat here, this
thread seems more specific to the topic.
The main backup improvement will be a pre-generated pool of keys and
a rescan at load to scrape missed transactions from the block history.
Then a backup will last forward for a long time.
I was starting to post the same idea you said nelisky.
How about a json-rpc command that locks the wallet, flushes it,
copies wallet.dat to a location you specified, then unlocks it? That
would be a smaller project than the pooled keys, so maybe it could be
done first.
What’s the simplest portable way to copy a file? Is there something
in Boost?
Bitcoin Forum post — August 27, 2010 — source: 0930-11342.md
Post by: satoshi on August 27, 2010, 12:49:43 AM
Try -datadir=
Last time I tried $(shell /usr/bin/wx-config), there was immediate
hollering about build problems with it. There wasn’t time to investigate
at the time.
One problem with $(shell /usr/bin/wx-config) is it will pick up any
version (wx 2.8 ) and any configuration (non-UTF-8 ) of wxWidgets that
happens to be there. -lwx_gtk2ud-2.9 only matches the right
configuration. It fails if wxWidgets was built with the wrong
configuration.
Quote
Iirc, chatting in #wxwidgets on freenode, the devs there were baffled
why that was used.
Did they say why they were baffled?
Quote
This is because on my system the path is
/usr/include/wx-2.9/wx/wx.h
Why is it there? Was it included by the OS, or did you have to build
it? If you built it, I wonder why it would put itself in a different
place.
Has wxWidgets 2.9 finally started to become available as a debian
package?
Again, those paths help make sure it’s only 2.9 and will fail with
2.8.
wxWidgets 2.8 comes in ANSI and UTF-16, both wrong for us. It’s
tempting because it’s so easily available as a package; a lot of people
were frustrated by it until we started hardcoding 2.9 into the
makefile.
Bitcoin Forum post — August 27, 2010 — source: 0921-11345.md
Post by: satoshi on August 27, 2010, 01:13:42 AM
If you read it into memory and write it out, it could fail in tight
memory situations.
I’m looking for something like copyfile(const char* from, const char*
to) or copyfile(path from, path to), preferably something in Boost if it
has it. If you find it for me, it’s more likely I’ll get to implementing
it.
Quote from: nelisky on August 26, 2010, 01:21:57 AM
As for the file copy, why add to the boost dependency? I for one
would love to get a core lib with very little deps.
We require Boost for JSON and a dozen things replacing dependencies
on wxWidgets. Boost is good, portable stuff, we should not shy away from
it.
Bitcoin Forum post — August 27, 2010 — source: 0921-11350.md
Post by: satoshi on August 27, 2010, 02:54:07 AM
I doubt there’s an mmap(2) on Windows. I’d rather call an existing
file copy function than make and test my own.
Quote from: nelisky on August 27, 2010, 01:21:09 AM
But if you are already using features from boost::filesystem you can
use copy_file from that. I just think that, if not already required for
something else, it’s a tad overkill.
Thanks. I thought it would be in there somewhere.
We already use boost::filesystem in a dozen places. It’s not a new
added dependency. It gives us a lot of portable stuff that we would
otherwise have to have a #ifdef for each OS and test everywhere.
Bitcoin Forum post — August 27, 2010 — source: 0921-11399.md
Post by: satoshi on August 27, 2010, 03:47:57 PM
Last edit: August 27, 2010, 04:16:05 PM by satoshi
Sorry, I’ve been so busy lately I’ve been skimming messages and I
still can’t keep up.
We want to avoid Windows API calls whenever possible. They usually
take about 6-8 parameters and a lot of testing to get right, it takes a
page of code to do something simple.
I usually shy away from iostreams. Seems like I too often hit
limitations. They kind of botched the C++ streams standard in the 90’s,
which is too bad, streams can be very powerful and useful when done
right. Using it in rpc.cpp may still turn out to be a mistake.
Bottom line is I’d rather call an existing file copy function than
make and test my own.
Re: Bitcoin does NOT violate Mises' Regression Theorem
Bitcoin Forum post — August 27, 2010 — source: 0583-11405.md
Post by: satoshi on August 27, 2010, 05:32:07 PM
Last edit: August 27, 2010, 06:17:17 PM by satoshi
As a thought experiment, imagine there was a base metal as scarce as
gold but with the following properties:
- boring grey in colour
- not a good conductor of electricity
- not particularly strong, but not ductile or easily malleable
either
- not useful for any practical or ornamental purpose
and one special, magical property:
- can be transported over a communications channel
If it somehow acquired any value at all for whatever reason, then
anyone wanting to transfer wealth over a long distance could buy some,
transmit it, and have the recipient sell it.
Maybe it could get an initial value circularly as you’ve suggested,
by people foreseeing its potential usefulness for exchange. (I would
definitely want some) Maybe collectors, any random reason could spark
it.
I think the traditional qualifications for money were written with
the assumption that there are so many competing objects in the world
that are scarce, an object with the automatic bootstrap of intrinsic
value will surely win out over those without intrinsic value. But if
there were nothing in the world with intrinsic value that could be used
as money, only scarce but no intrinsic value, I think people would still
take up something.
Bitcoin Forum post — August 27, 2010 — source: 0941-11439.md
Post by: satoshi on August 27, 2010, 09:54:12 PM
Last edit: August 28, 2010, 02:34:24 PM by satoshi
Version 0.3.11 is now available.
Changes:
- Some blk*.dat checking on load
- Built the -4way code with -march=amdfam10, which makes it a little
faster
- Warning if your clock is too far off
- Warnings/errors/alerts can also be seen in the getinfo command
- Alert system
The alert system can display notifications on the status bar to alert
you if you’re running a version that needs to be upgraded for an
important security update.
In response to an alert, your node may also go into safe mode, which
disables the following json-rpc commands (used by automated websites) to
protect it from losing money until you get a chance to upgrade:
sendtoaddress
getbalance
getreceivedbyaddress
getreceivedbylabel
listreceivedbyaddress
listreceivedbylabel
If you decide it’s a false alarm and want to take your chances, you
can use the switch -disablesafemode to re-enable them.
This is an important safety improvement. For a large segment of
possible problems, this can warn everyone immediately once a problem is
discovered and prevent them from acting on bad information.
Nodes keep operating and do not stop generating in response to an
alert, so old versions may still try to make a fork, but the alert
system can make sure users are warned not to act on anything in the
fork.
Bitcoin Forum post — August 28, 2010 — source: 0941-11505.md
Post by: satoshi on August 28, 2010, 02:54:04 PM
Quote from: torservers on August 28, 2010, 01:00:37 PM
The “About” dialog still shows 0.3.10.1 beta.
What OS? I ran the Windows and 64-bit Linux version and checked the
about dialog.
The Mac version is still 0.3.10.1.
Quote from: pavelo on August 28, 2010, 07:36:07 AM
iirc, it is possible to specify -march on a per-function basis using
some gcc attribute. That way, only the function in
question would be optimized, and if the user doesn’t specify -4way,
everything else should be ok.
I updated the first post to be more specific. Only the -4way code is
compiled this way.
Bitcoin Forum post — August 29, 2010 — source: 0816-11610.md
Post by: satoshi on August 29, 2010, 10:14:36 PM
The code assumes little-endian throughout and was written with the
intention of never being ported to big-endian. Every integer that is
sent over the network would have to be byte swapped, in addition to many
dozens of other places in code. It would not be worth the extra
sourcecode bloat.
Bitcoin Forum post — September 05, 2010 — source: 0967-12062.md
Post by: satoshi on September 05, 2010, 11:25:32 PM
You can probably just comment out the line
cryptopp/secblock.h:187
//assert(false);
Let me know if it works, and watch if it memory leaks.
It looks like a template class to make sure the derived class defines
its own version of allocate and deallocate. It would be weird if that
was the actual problem and it made it all the way to release. Probably a
false alarm.
Bitcoin Forum post — September 06, 2010 — source: 0969-12130.md
Post by: satoshi on September 06, 2010, 09:21:21 PM
This is in SVN rev 147.
This is more standard, and although json-rpc 1.0 didn’t specify the
format of error objects, it did specify that they would be objects not
strings or other values, so we needed to change this to be correct. The
code/message members have become standard in later json-rpc specs.
If you have code that checks the error and expects a string, you’ll
need to change it. When there is an error, the error member is now an
object not a string.
Also in SVN rev 147:
- The command line json-rpc returns the error code as its exit code.
Exit codes can only be 0-255 on unix, so it’s abs(code)%256.
- The “backupwallet ” command that was discussed in
another thread. It locks the wallet and copies it, so you can be sure
you get a correct copy.
Bitcoin Forum post — September 07, 2010 — source: 0994-12168.md
Post by: satoshi on September 07, 2010, 04:32:21 PM
Another option is to reduce the number of free transactions allowed
per block before transaction fees are required. Nodes only take so many
KB of free transactions per block before they start requiring at least
0.01 transaction fee.
The threshold should probably be lower than it currently is.
I don’t think the threshold should ever be 0. We should always allow
at least some free transactions.
Bitcoin Forum post — September 07, 2010 — source: 0999-12181.md
Post by: satoshi on September 07, 2010, 07:17:55 PM
Last edit: September 07, 2010, 08:34:31 PM by satoshi
Version 0.3.12 is now available.
Features:
json-rpc errors return a more standard error object. (thanks to
Gavin Andresen)
json-rpc command line returns exit codes.
json-rpc “backupwallet” command.
Recovers and continues if an exception is caused by a message you
received. Other nodes shouldn’t be able to cause an exception, and it
hasn’t happened before, but if a way is found to cause an exception,
this would keep it from being used to stop network nodes.
If you have json-rpc code that checks the contents of the error
string, you need to change it to expect error objects of the form
{“code”:,“message”:}, which is the standard. See this
thread:
Bitcoin Forum post — September 08, 2010 — source: 0994-12237.md
Post by: satoshi on September 08, 2010, 05:30:14 PM
Currently, paying a fee is controlled manually with the -paytxfee
switch. It would be very easy to make the software automatically check
the size of recent blocks to see if it should pay a fee. We’re so far
from reaching the threshold, we don’t need that yet. It’s a good idea to
see how things go with controlling it manually first anyway.
It’s not a big deal if we reach the threshold. Free transactions
would just take longer to get into a block.
I did a rough tally of 4000 blocks from around 74000-78000. This is
excluding the block reward transactions:
There were average 2 transactions per block, 17 transactions per
hour, 400 transactions per day.
Average transaction bytes per block was 428 bytes, or 214 bytes per
transaction.
The current threshold is 200KB per block, or about 1000 transactions
per block. I think it should be lowered to 50KB per block. That would
still be more than 100 times the average transactions per block.
The threshold can easily be changed in the future. We can decide to
increase it when the time comes. It’s a good idea to keep it lower as a
circuit breaker and increase it as needed. If we hit the threshold now,
it would almost certainly be some kind of flood and not actual use.
Keeping the threshold lower would help limit the amount of wasted disk
space in that event.
Bitcoin Forum post — September 08, 2010 — source: 0999-12240.md
Post by: satoshi on September 08, 2010, 06:06:04 PM
Bitcoin clients currently only create and recognize transactions that
match two possible templates.
Those are some quick tests that loosely check if transactions fit
some general metrics that those standard transactions fit. Nodes will
only work on adding those transactions to their block.
In the future, if we add more templates to the existing 2 types of
transactions, we can change the “rather not work on nonstandard
transactions” test to accept them.
Re: Bitcoin Blogger: Is It Better To Buy Or Generate Bitcoins?
Bitcoin Forum post — September 08, 2010 — source: 0955-12248.md
Post by: satoshi on September 08, 2010, 08:27:39 PM
Quote from: BitLex on September 07, 2010, 08:10:54 PM
AMD X3 @2.8ghz
->stock client
~3800khs ~150Watt
Did you try -4way?
Quote
How many hashes can I expect with a 24 core machine? I have a
quad-core generating 4,300 hashes-per-second, so I am estimating a
24-core machine could mine bitcoins at 25,000 hashes-per-second.
AMD Phenom (I think 4-core) CPUs are doing about 11,000khps with
-4way, about 100% speedup. 24 cores should get 66,000khps. AMD is the
best choice because it has the best SSE2 implementation. (or maybe
because tcatm had an AMD and optimised his code for that)
There’s been so much else to do that I haven’t had time to make -4way
automatic. For now you still have to do it manually.
Bitcoin Forum post — September 09, 2010 — source: 1007-12262.md
Post by: satoshi on September 09, 2010, 01:04:05 AM
SVN rev 150 has some code to try to auto-detect whether to use 4-way
SSE2. We need this because it’s only faster on certain newer CPUs that
have 128-bit SSE2 and not ones with 64-bit SSE2.
It uses the CPUID instruction to get the CPU brand, family, model
number and stepping. That’s the easy part. Knowing what to do with the
model number is the hard part. I was not able to find any table of
family, model and stepping numbers for CPUs. I had to go by various
random reports I saw.
Here’s what I ended up with:
Code:
// We need Intel Nehalem or AMD K10 or better for 128bit SSE2
// Nehalem = i3/i5/i7 and some Xeon
// K10 = Opterons with 4 or more cores, Phenom, Phenom II, Athlon II
// Intel Core i5 family 6, model 26 or 30
// Intel Core i7 family 6, model 26 or 30
// Intel Core i3 family 6, model 37
// AMD Phenom family 16, model 10
bool fUseSSE2 = ((fIntel && nFamily * 10000 + nModel >= 60026) ||
(fAMD && nFamily * 10000 + nModel >= 160010));
I saw some sporadic inconsistent model numbers for AMD CPUs, so I’m
not sure if this will catch all capable AMDs.
If it’s wrong, you can still override it with -4way or -4way=0.
It prints what it finds in debug.log. Search on CPUID.
Re: Won't let me send coins because it requires a transaction fee?
Bitcoin Forum post — September 10, 2010 — source: 1013-12342.md
Post by: satoshi on September 10, 2010, 12:46:37 AM
I think I know what happened. Doubleclick on the generated
transaction. It probably has a sub-0.01 transaction fee in it.
Someone has been paying a 0.00000010 transaction fee. I don’t think
you can even set that with -paytxfee, I think you’d have to modify the
code to do it. Your generated block is worth 50.00000010, so when you
try to send the whole thing you have 0.00000010 left over for the
change, which triggers the dust spam 0.01 fee.
It would normally be harmless except in this corner case. I should
add a special case to CreateTransaction to handle this.
Bitcoin Forum post — September 12, 2010 — source: 0589-12483.md
Post by: satoshi on September 12, 2010, 05:40:20 PM
Quote from: lachesis on August 10, 2010, 03:24:55 PM
Also, does Bitcoin open the BerkeleyDB as exclusive, precluding
the need for a file lock?It does not – did my own tests.
Is there a way to open BerkeleyDB exclusive?
DB_PRIVATE is the worst of both worlds. DB_PRIVATE is not exclusive,
but it does make it get screwed up if another process tries to access it
at the same time.
Bitcoin Forum post — September 12, 2010 — source: 0920-12484.md
Post by: satoshi on September 12, 2010, 06:00:39 PM
Last edit: September 12, 2010, 06:25:04 PM by satoshi
Trying it without the DB_PRIVATE flag in rev 153. We need to keep an
eye on what’s different.
On Windows at least, it creates six __db.001 - __db.006 files with
sizes from 24K to 4MB. It doesn’t delete them on exit, it just leaves
them behind.
The docs say it uses memory mapped files. I assume they have the same
file permissions as the database files, so the same user access
restrictions apply.
Tests on Windows private LAN download of 78500 blocks:
with DB_PRIVATE 20 minutes 51 seconds
without DB_PRIVATE 20 minutes 51 seconds
I wasn’t expecting them to come out exactly the same.
Bitcoin Forum post — September 12, 2010 — source: 0989-12494.md
Post by: satoshi on September 12, 2010, 07:24:53 PM
If the only library is closed source, then there’s a project to make
an open source one.
If the only library is GPL, then there’s a project to make a non-GPL
one.
If the best library is MIT, Boost, new-BSD or public domain, then we
can stop re-writing it.
I don’t question that GPL is a good license for operating systems,
especially since non-GPL code is allowed to interface with the OS. For
smaller projects, I think the fear of a closed-source takeover is
overdone.
Bitcoin Forum post — September 19, 2010 — source: 1023-13201.md
Post by: satoshi on September 19, 2010, 05:22:03 PM
Bouncing between 0 and 2 connections could be if it’s connecting to
itself. Are you using the “-connect” switch?
Did you compile it or is this a release build, and what version?
I’m not sure how the 200Kb/sec, since it waits at least a half second
between connection attempts. How fast is it flickering between 0 and 2
connections? Faster than twice a second?
Bitcoin Forum post — September 19, 2010 — source: 1034-13206.md
Post by: satoshi on September 19, 2010, 06:46:46 PM
Last edit: September 19, 2010, 07:04:36 PM by satoshi
The lines it’s tripping on:
Code:
ERROR extern map<string, string> mapAddressBook;
ERROR extern CCriticalSection cs_mapAddressBook;
ERROR extern vector<unsigned char> vchDefaultKey;
OK extern bool fClient;
OK extern int nBestHeight;
OK extern unsigned int nWalletDBUpdated;
ERROR extern DbEnv dbenv;
So it’s acting like nothing is defined, not even map and vector.
Yet, db.h is included by headers.h (and only there, nowhere else)
which includes vector, map, util.h and everything before db.h.
Is VC trying to use precompiled headers and screwing it up? Could
there be some leftover precompiled header files in your directory from
previously failed attempts that it’s finding and using?
There’s an installer package now that makes it really easy to install
MinGW. Don’t use the latest version 4.5.0, use a few versions back like
4.4.1 (1.908.0) or 1.812.0. A setup program completely installs
everything, it’s not hard like it used to be. I think the only thing I
had to do was rename make*.exe something to make.exe.
Off topic, but: It would be nice if someone would hack on getting
tcatm’s 4-way 128-bit SSE2 code working on Windows. There’s something
with MinGW’s optimisation, I’m not sure but maybe a problem with 16-byte
alignment on the stack, that makes it segfault. With some fiddling, I
was able to get his code to work in a test program, but not in Bitcoin
itself for some reason.
Bitcoin Forum post — September 19, 2010 — source: 1063-13211.md
Post by: satoshi on September 19, 2010, 07:58:11 PM
I don’t know anything about any of the bug trackers. If we were to
have one, we would have to make a thoroughly researched choice.
We’re managing pretty well just using the forum. I’m more likely to
see bugs posted in the forum, and I think other users are much more
likely to help resolve and ask follow up questions here than if they
were in a bug tracker. A key step is other users helping resolve the
simple stuff that’s not really a bug but some misunderstanding or
confusion.
I keep a list of all unresolved bugs I’ve seen on the forum. In some
cases, I’m still thinking about the best design for the fix. This isn’t
the kind of software where we can leave so many unresolved bugs that we
need a tracker for them.
Bitcoin Forum post — September 19, 2010 — source: 1048-13219.md
Post by: satoshi on September 19, 2010, 09:49:30 PM
Probably best to disable receiving by IP unless you specifically
intend to use it. This is a lot of surface area that nobody uses that
doesn’t need to be open by default.
In storefront cases, you would typically only want customers to send
payments through your automated system that only hands out bitcoin
addresses associated with particular orders and accounts. Random
unidentified payments volunteered to the server’s IP address would be
unhelpful.
In general, sending by IP has limited useful cases. If connecting
directly without a proxy, the man-in-the-middle risk may be tolerable,
but no privacy. If you use a privacy proxy, man-in-the-middle risk is
unacceptably high. If we went to all the work of implementing SSL, only
large storefronts usually go to the trouble of getting a CA cert, but
most of those cases would still be better off to use bitcoin
addresses.
I uploaded this change to SVN rev 156. The switch to enable is
“-allowreceivebyip”.
Senders with this version will get the error “Recipient is not
accepting transactions sent by IP address”. Older version senders will
get “Transfer was not accepted”.
I used a different name for the switch because “-allowiptransactions”
sounds like it includes sending. If there’s a better name for the
switch, we can change it again.
Bitcoin Forum post — September 23, 2010 — source: 1269-13831.md
Post by: satoshi on September 23, 2010, 04:19:08 PM
In the next release (0.3.13), I’m going to change the format of the
internal version number integer from 313 to 31300, for instance 31305 =
0.3.13.5. The last number represents changes on the SVN between releases
and ought to be properly represented in the version number. Otherwise,
it would be a pain if we had a mistake or something in one of the sub
versions that needed to be worked around.
Bitcoin Forum post — September 23, 2010 — source: 0960-13833.md
Post by: satoshi on September 23, 2010, 04:28:25 PM
I don’t understand, are you under the impression that the program
sets the system clock? It doesn’t.
Quote from: Cdecker on September 19, 2010, 08:14:08 PM
We already have ways to synchronize (approximately) the clients, so
why not make use of that?
We use an internal offset based on the median of other nodes’ times,
but for security reasons we don’t let them offset us by more than an
hour. If they indicate we’re off by more than an hour, then we resort to
alerting the user to fix their clock.
Bitcoin Forum post — September 23, 2010 — source: 0671-13844.md
Post by: satoshi on September 23, 2010, 05:56:55 PM
Last edit: October 09, 2010, 09:48:02 PM by satoshi
Bitcoin would be convenient for people who don’t have a credit card
or don’t want to use the cards they have, either don’t want the spouse
to see it on the bill or don’t trust giving their number to “porn guys”,
or afraid of recurring billing.
It’s absolutely safer than a straight payment without escrow, but not
as good as a human arbitrated escrow, assuming you trust the human
enough.
In this kind of escrow, a cheater can’t win, but it’s still possible
for you to lose. It at least takes away the profit motive for cheating
you. The seller is assured that the money is reserved for him, while the
buyer retains the leverage that the seller hasn’t been paid yet until
completion.
Bitcoin Forum post — September 30, 2010 — source: 1306-14714.md
Post by: satoshi on September 30, 2010, 04:38:53 PM
As you figured out, the root problem is we shouldn’t be counting or
spending transactions until they have at least 1 confirmation.
0/unconfirmed transactions are very much second class citizens. At most,
they are advice that something has been received, but counting them as
balance or spending them is premature.
I made changes so they show up in lighter print, with the credit
amount in square brackets like [+1.23], and the amount not counted
towards your balance and not available for spending. This doesn’t apply
to transactions you sent, which you implicitly trust, since you wrote
them.
I didn’t make it (+1.23) because parenthesis in accounting means
negative. I hope square brackets is different enough to be clear what is
meant.
The JSON-RPC interface can still see 0/unconfirmed if it wants by
specifying 0 confirmations.
I uploaded the changes to SVN rev 158. I will post a 0.3.13 RC
shortly.
If you have any of these transactions in your wallet, do not send any
payments until you’ve upgraded to 0.3.13, which will be coming soon.
If you’ve already sent any of these transactions, or you’re the
creator of them, then use theymos’ patch or make the following change
and use it to send your clean transactions to a new wallet to clean
things up.
change: if (pcoin->GetDepthInMainChain() < 1 &&
pcoin->GetDebit() <= 0) continue; to: if
(pcoin->GetDepthInMainChain() < 1) continue;
Bitcoin Forum post — September 30, 2010 — source: 0652-14729.md
Post by: satoshi on September 30, 2010, 05:50:32 PM
If you do, I think it should be a very brief, single paragraph
article like 100 words or less that simply identifies what Bitcoin
is.
I wish rather than deleting the article, they put a length
restriction. If something is not famous enough, there could at least be
a stub article identifying what it is. I often come across annoying red
links of things that Wiki ought to at least have heard of.
The article could be as simple as something like:
“Bitcoin is a peer-to-peer decentralised /link/electronic
currency/link/.”
The more standard Wiki thing to do is that we should have a paragraph
in one of the more general categories that we are an instance of, like
Electronic Currency or Electronic Cash. We can probably establish a
paragraph there. Again, keep it short. Just identifying what it is.
Bitcoin Forum post — September 30, 2010 — source: 1314-14732.md
Post by: satoshi on September 30, 2010, 06:11:56 PM
Last edit: September 30, 2010, 10:20:15 PM by satoshi
It ramps up the fee requirement as the block fills up:
<50KB free
50KB 0.01
250KB 0.02
333KB 0.03
375KB 0.04
etc.
It’s a typical pricing mechanism. After the first 50KB sells out, the
price is raised to 0.01. After 250KB is sold, it goes up to 0.02. At
some price, you can pretty much always get in if you’re willing to
outbid the other customers.
Bitcoin Forum post — October 01, 2010 — source: 1327-14788.md
Post by: satoshi on October 01, 2010, 12:34:35 AM
Last edit: October 06, 2010, 04:37:06 PM by satoshi
Version 0.3.13 is now available. You should upgrade to prevent
potential problems with 0/unconfirmed transactions. Note: 0.3.13
prevents problems if you haven’t already spent a 0/unconfirmed
transaction, but if that already happened, you need 0.3.13.2.
Changes:
- Don’t count or spend payments until they have 1 confirmation.
- Internal version number from 312 to 31300.
- Only accept transactions sent by IP address if -allowreceivebyip is
specified.
- Dropped DB_PRIVATE Berkeley DB flag.
- Fix problem sending the last cent with sub-cent fractional
change.
- Auto-detect whether to use 128-bit 4-way SSE2 on Linux.
Gavin Andresen:
- Option -rpcallowip= to accept json-rpc connections from another
machine.
You can still control the SSE2 use manually with -4way and
-4way=0.
Version 0.3.13.2 (SVN rev 161) has improvements for the case where
you already had 0/unconfirmed transactions that you might have already
spent. Here’s a Windows build of it:
Bitcoin Forum post — October 03, 2010 — source: 1327-15102.md
Post by: satoshi on October 03, 2010, 06:17:06 PM
Quote from: ShadowOfHarbringer on October 02, 2010, 01:00:07 PM
That’s nice, however the automatic 4way detection is not working on
my Gentoo AMD 64 version client.
I still have to add the “-4way” switch.
Forgot to say, I suspected the detect might not work on 64-bit AMD. I
found it hard to believe but AMD reports a different model number in
64-bit mode.
Could you grep CPUID your debug.log and tell me what it says? (and
anyone else with 64-bit AMD) And what AMD chip do you have?
Do all AMDs that support 64-bit have the better SSE2 hardware
also?
Bitcoin Forum post — October 03, 2010 — source: 1327-15110.md
Post by: satoshi on October 03, 2010, 07:39:06 PM
Could a few people please run this special build? It’ll amnesty the
dust spam transactions, which will clear up the 0/unconfirmed problem
for now. We really just need one block letting them through to clear up
the previous transactions. Post if you generate a block with this.
These are binaries only. The linux version is 64-bit only.
The linux 64-bit version includes a change to the cpuid 4-way 128-bit
SSE2 autodetect for AMD in 64-bit mode, if you’d like to test that and
see if that’s better.
Bitcoin Forum post — October 03, 2010 — source: 1327-15136.md
Post by: satoshi on October 03, 2010, 08:54:07 PM
Quote from: theymos on October 03, 2010, 08:09:51 PM
ArtForz is already running with no fees, and he has 20-30% of the
network’s CPU power. The person who originally sent the broken
transactions deleted his wallet, though, and the network has forgotten
these historical transactions, so any transactions based on this won’t
confirm.
Transactions aren’t accepted or displayed as 0/unconfirmed until your
node has a path of transactions back to the block chain.
Any transactions in your wallet also have bundled with them all
unrecorded transactions required to reach the block chain. If you have a
transaction that is displayed as 0/unconfirmed, then you have all the
previous unrecorded transactions it depends on and you will also
rebroadcast those transactions when you rebroadcast yours.
If a no-fee block has already been generated and hasn’t helped, then
I need to look at what’s wrong. It’s a part of code that doesn’t get
much use. They should be recorded in the wallets of everyone who has a
transaction depending on them.
Quote from: theymos on October 03, 2010, 08:09:51 PM
The person who originally sent the broken transactions deleted his
wallet
Sigh… why delete a wallet instead of moving it aside and keeping the
old copy just in case? You should never delete a wallet.
Quote from: tcatm on October 03, 2010, 08:10:47 PM
It’s running. Should find a block within 3 hours.
It may take a while to collect re-broadcast transactions. It’ll help
if you can accept inbound connections so you’ll be listening to more
nodes. Even if you find a block in 3 hours, keep it running continuously
for a few days at least.
Bitcoin Forum post — October 03, 2010 — source: 1332-15142.md
Post by: satoshi on October 03, 2010, 09:30:04 PM
Last edit: October 04, 2010, 12:22:41 AM by satoshi
Quote from: theymos on October 02, 2010, 06:11:11 AM
Quote from: lzsaver on October 02, 2010, 05:49:47 AM
Can you tell more about it:
“they have to do weird things with extraNonce, which increases the
size of the block header”.
When you generate, you calculate hashes of the block header. Hashing
more data is slower than hashing less data, so the block header is
critically of a fixed size for everyone, with one exception.
This is the point of confusion. extraNonce is not part of the block
header, it is part of the first transaction. It does not slow down your
hashing. It does not change the size of the header.
We need to be vigilant and nip in the bud any misconception that the
contents of your block slows down your hash speed. It doesn’t.
extraNonce never needs to be very big. We could reset it every second
whenever the time changes if we wanted. Worst case, if you didn’t want
to keep track of incrementing it, extraNonce could be 4 random bytes and
the chance of wasting time from collision would be negligible.
Separate machines are automatically collision proof because they have
different generated public keys in the first transaction. That also goes
for each thread too.
Bitcoin Forum post — October 03, 2010 — source: 1327-15147.md
Post by: satoshi on October 03, 2010, 09:43:20 PM
ShadowOfHarbringer, is yours faster with -4way?
If it is, then I’m thinking that any AMD that supports 64-bit has
128-bit SSE2.
The specialbuild version I posted here looks for model 4 or higher.
If yours is faster with -4way, then I should change it to always use
SSE2 with any AMD with 64-bit.
Bitcoin Forum post — October 03, 2010 — source: 1023-15150.md
Post by: satoshi on October 03, 2010, 10:07:00 PM
You’re connecting to yourself. All 21 connection attempts were to a
node with version 31300 (0.3.13). Not everyone has 0.3.13 yet.
IRC seems to be working. It ought to have other nodes to try.
There may be something I need to do to make sure it doesn’t try to
connect to itself again right away after disconnecting. I can’t see how
it’s happening though, it should be resetting nLastTry which would put
it to the back of the queue, but the log doesn’t show it.
You can try moving addr.dat aside. Maybe there’s something wrong in
it.
Bitcoin Forum post — October 04, 2010 — source: 0151-15360.md
Post by: satoshi on October 04, 2010, 07:21:01 PM
Quote from: eurekafag on October 04, 2010, 10:55:56 AM
Where can I find the latest English .po file to keep the translation
up-to-date?
poedit does it. Either get the src directory from a release, or
download it with SVN. Place your .po file 3 directories deep under the
src directory. Open it with poedit and do Catalog->Update from
sources.
So for example, you have:
src
src58.h
src.h
…
src.cpp
src.h
src
src_MESSAGES.po
Open bitcoin.po with poedit, do Catalog->Update from sources. It
looks for the sourcecode up 3 directories (..\..\..) from where
bitcoin.po is.
This updates your existing .po file you already worked on and adds
any news strings. It may try to match close strings, so check things
over and make sure it didn’t make any bad guesses.
Make sure you use the .po file I uploaded to SVN or in a release,
because I always fix up at least a few things. I’m attaching your
Russian one to this message.
Bitcoin Forum post — October 04, 2010 — source: 1347-15366.md
Post by: satoshi on October 04, 2010, 07:48:40 PM
It can be phased in, like:
if (blocknumber > 115000)
maxblocksize = largerlimit
It can start being in versions way ahead, so by the time it reaches
that block number and goes into effect, the older versions that don’t
have it are already obsolete.
When we’re near the cutoff block number, I can put an alert to old
versions to make sure they know they have to upgrade.
Bitcoin Forum post — October 06, 2010 — source: 0151-15660.md
Post by: satoshi on October 06, 2010, 03:42:39 PM
Last edit: October 06, 2010, 04:40:31 PM by satoshi
poedit reorganised the file for some reason. I re-ran update from
sources and it put it back in the original order so it’s fine now. Did
you run it on a drive where files aren’t sorted alphabetically, like a
FAT drive or USB flash drive?
Strings aren’t added or changed very often. It’s months before enough
changes build up.
I uploaded the changes.
This Windows build has the Russian translation in it:
Bitcoin Forum post — October 06, 2010 — source: 1306-15672.md
Post by: satoshi on October 06, 2010, 04:54:23 PM
That’s going to be more of a SelectCoins thing.
SVN rev 161 has a refinement to recursively determine if your own
unconfirmed transactions can be spent. This is needed because you should
be able to spend your own change right away.
The new recursive determination is: 0/unconfirmed can be spent if
it’s yours and all its dependencies are either in a block or also
yours.
This version is an improvement if you already had a 0/unconfirmed
transaction and might have already spent it. If you were the original
creator of a 0/unconfirmed transaction, you still need theymos’ patch
instead.
Re: Tor connections not working reliably, many seednodes offline
Bitcoin Forum post — October 06, 2010 — source: 1375-15682.md
Post by: satoshi on October 06, 2010, 05:36:41 PM
Maybe you were just unlucky to have an exit node without reverse
lookup.
The IRC server’s response doesn’t look like it was disconnecting you
for that. It’s supposed to go IRC SENDING: NICK after that, and it
doesn’t so it gets timed out.
I see the problem. The IRC code is looking for various phrases to see
when the server is ready to receive your NICK, but it’s not looking for
that particular phrase. I’ll fix it.
I don’t know if it’s really required to wait for the server to finish
looking up hostname before sending nick.
How long did it take to get connected with TOR the first time, having
to use the seed nodes?
Bitcoin Forum post — October 06, 2010 — source: 1268-15741.md
Post by: satoshi on October 06, 2010, 11:10:31 PM
Last edit: October 09, 2010, 10:12:07 PM by satoshi
Quote from: kiba on September 23, 2010, 04:00:16 PM
1. Download site like rapidshare and other crappy host. Inconvenient
captcha and required paypal. Bitcoin can possibly take both roles and
streamline the whole process.
Repeating myself here, but there is open source software for that, so
it would just be a matter of bolting on a Bitcoin payment mechanism. One
good one I found was Mihalism Multi Host. It’s designed as a free host,
so it would just need a few tweaks to loosen up restrictions consistent
with paid use.
Bitcoin Forum post — October 09, 2010 — source: 1414-16316.md
Post by: satoshi on October 09, 2010, 08:19:33 PM
SVN rev 163 (ver 0.3.13.3) has the key pool feature. Pre-generated
new keys are aged in a queue before use, so that backups of wallet.dat
hold keys you’ll use in the future.
For now I made the default pool size 100. It can be configured with
-keypool=. Be aware, it takes a little time to increase the pool size,
so don’t go crazy with it. Disk space is about 1K per key.
I have not addressed the recovery side of this yet. If you actually
did restore an old wallet.dat, I think you may have to delete blk*.dat
to rediscover your own transactions during the redownload.
I’ve only tested this moderately. You might not want to use this for
a website server until it’s had some more testing.
Bitcoin Forum post — October 21, 2010 — source: 0151-17965.md
Post by: satoshi on October 21, 2010, 10:50:47 PM
The order matters not to the program, but it matters to me
maintaining it. If it jumbles the order of the .po file then I can’t
diff for changes. I have to update all 7 translation files when I change
the English text in the program, and it’s easier when they’re all in the
same order.
I can still put it back into normal order by making poedit rescan
it.
It is normal that untranslated strings are shown on top.
Quote from: eurekafag on October 06, 2010, 07:39:36 PM
By the way, there are some similar lines that possibly may be
replaced by one. They are very close by meaning and differs only by 1-2
words. Just a suggestion of course.
I know, but not easily without complicating the sourcecode.
Bitcoin Forum post — October 23, 2010 — source: 1530-18241.md
Post by: satoshi on October 23, 2010, 06:22:49 PM
Quote from: theymos on October 21, 2010, 10:00:26 PM
his block count remains “stuck” at 1698.
He was generating invalid blocks at difficulty 1.0. He must have a
corrupted entry in his blk0001.dat or blkindex.dat file. He just needs
to delete blk*.dat and let it redownload.
The safety lockdown detected the problem and was displaying “WARNING:
Displayed transactions may not be correct!” because it saw a longer
chain existed that it was unable to accept. The safety lockdown cannot
stop generation or it would create an attack possibility.
Quote from: gavinandresen on October 22, 2010, 02:25:14 PM
The Bitcoin client really shouldn’t allow coin generation until you
have all of the blocks up to the last block checkpoint.
Good idea, I made a change to make sure it won’t generate before
checkpoint block 74000.
Bitcoin Forum post — October 23, 2010 — source: 1540-18246.md
Post by: satoshi on October 23, 2010, 06:52:02 PM
Quote from: Odin on October 22, 2010, 09:24:38 PM
Fault Module Name: mingwm10.dll
This is the important clue. I believe it’s saying it crashed in that.
Maybe there are other versions of it to try. mingwm10.dll is just a
simple placeholder thing that satisfies some callback requirement for
multithreaded apps.
Re: Suggestion: Allow short messages to be sent together with bitcoins ?
Bitcoin Forum post — October 23, 2010 — source: 1545-18250.md
Post by: satoshi on October 23, 2010, 07:02:57 PM
ECDSA can’t encrypt messages, only sign signatures.
It would be unwise to have permanently recorded plaintext messages
for everyone to see. It would be an accident waiting to happen.
If there’s going to be a message system, it should be a separate
system parallel to the bitcoin network. Messages should not be recorded
in the block chain. The messages could be signed with the bitcoin
address keypairs to prove who they’re from.
Bitcoin Forum post — October 24, 2010 — source: 0665-18349.md
Post by: satoshi on October 24, 2010, 07:17:51 PM
I have the beginning of something like this. It’s mostly like what
Gavin described.
Some more rpc interface:
move
Move from one internal account to another. I think blank account name
(““) will be your default account. If you sell something to a user, you
could do move”theiraccount” “” 123.45.
Is “move” the best name for this? I shied away from “transfer”
because that sounds too close to sending a transaction.
I’m thinking a new function getaccountaddress instead of overloading
getnewaddress:
getaccountaddress
Gives you an address allocated from getnewaddress . It’ll
keep giving the same address until something is received on the address,
then it allocates a new address. (It automatically does what the sample
code I posted some time ago did)
Would these commands make it possible in simple cases to implement
your website without needing a database of your own?
Bitcoin Forum post — October 25, 2010 — source: 1540-18511.md
Post by: satoshi on October 25, 2010, 05:27:47 PM
Last edit: October 26, 2010, 04:29:02 PM by satoshi
The only thing I can think of is to see if there are other versions
of mingwm10.dll you can get. mingwm10.dll is a tiny little DLL that came
with the MinGW compiler that you need when you build for multi-thread. I
don’t know exactly what it does, but it probably just says something
like “yes Windows, see I’m in a DLL like you insisted.”
The end of your debug.log file might show the last thing it was doing
before it crashed.
Bitcoin Forum post — November 13, 2010 — source: 0064-21766.md
Post by: satoshi on November 13, 2010, 12:55:51 AM
I’m happy if someone with artistic skill wants to contribute
alternatives. The icon/logo was meant to be good as an icon at the 16x16
and 20x20 pixel sizes. I think it’s the best program icon, but there’s
room for improvement at larger sizes for a graphic for use on
websites.
It’ll be a lot simpler if authors could make their graphics public
domain.
Re: Some testing that I did on the testnetwork, my findings.
Bitcoin Forum post — November 13, 2010 — source: 1668-21896.md
Post by: satoshi on November 13, 2010, 11:25:26 PM
Thank you for limiting flood tests to the testnet.
Version 0.3.15 combines several features to help legitimate
transactions jump the queue during a flood attack. The key was Gavin’s
idea for prioritising transactions based on the age of their
dependencies. Every coin is entitled to turn over so often. The longer
waited, the more priority accumulates. Priority is sum(valuein * age) /
txsize. Transaction fee still takes precedence over priority, and
priority determines the order of processing within a fee strata.
In support of the priority feature, SelectCoins only uses your own 0
conf transactions only as a last resort if that’s all you have left.
This helps keep you from turning your coins over rapidly unless you’re
forcing it by actually turning all your coins over rapidly.
Re: Some testing that I did on the testnetwork, my findings.
Bitcoin Forum post — November 14, 2010 — source: 1668-21959.md
Post by: satoshi on November 14, 2010, 04:53:19 PM
Last edit: November 14, 2010, 05:15:52 PM by satoshi
Quote from: ByteCoin on November 13, 2010, 11:55:11 PM
Of course, if the network is not being flooded and you’re not overly
concerned about the current transaction getting held up then it’s
probably worth preferring to use your 0 conf transactions so that you
can “save” the higher priority coins for when the network is being
flooded.
You should use at least some priority in case a flood comes along
before the next block.
As long as all dependencies have at least 1 conf, if the transaction
doesn’t have enough priority at first, the dependencies will age until
it does.
Quote
Gaming the system by including 1000 or so recently turned over BTC to
bump the priority as described in my post above still works of
course!
Or managing how much priority you spend on a transaction. The
software would have to know your future plans to know whether to spend
your priority now or save it for later. I don’t think we’ll need to get
into that much detail though. There’s a wide enough difference between
normal users and flooders.
Priority doesn’t have to do everything. Once you know there’s a
flood, you can add -paytxfee=0.01. Hopefully with priority, your
transactions before that should be at worst slow, not stuck.
Re: Need OP\_BLOCKNUMBER to allow "time" limited transactions
Bitcoin Forum post — November 15, 2010 — source: 1786-22119.md
Post by: satoshi on November 15, 2010, 06:37:44 PM
We can’t safely do OP_BLOCKNUMBER. In the event of a block chain
reorg after a segmentation, transactions need to be able to get into the
chain in a later block. The OP_BLOCKNUMBER transaction and all its
dependants would become invalid. This wouldn’t be fair to later owners
of the coins who weren’t involved in the time limited transaction.
nTimeLock does the reverse. It’s an open transaction that can be
replaced with new versions until the deadline. It can’t be recorded
until it locks. The highest version when the deadline hits gets
recorded. It could be used, for example, to write an escrow transaction
that will automatically permanently lock and go through unless it is
revoked before the deadline. The feature isn’t enabled or used yet, but
the support is there so it could be implemented later.
Re: Transaction / spam flood attack currently under way
Bitcoin Forum post — November 19, 2010 — source: 1850-22952.md
Post by: satoshi on November 19, 2010, 11:50:24 PM
Quote from: creighto on November 19, 2010, 08:29:12 PM
Perhaps in addition to the age priority rule recently implimented,
there should be a minimum age rule without a transaction fee. Said
another way, perhaps a generation rule that says that a free transaction
must be 3 blocks deep before it can be transfered again for free. This
will still allow real users to immediately spend new funds if they have
to, while still permitting real users to reshuffle funds to suit their
needs without an overhead cost. I think that this would significantly
inhibit the type of spamming attack that is currently underway.
I’m doing something like that. Priority is a more formalised version
of the concept you’re describing.
Quote from: FreeMoney on November 19, 2010, 05:39:44 PM
As it stands now 3.15 has a lot of free transaction space and that
space is given first to transactions with the highest
[age]*[value]/[size] correct? Would it be reasonable to make some
arbitrary portion of the free space require [age]*[value]/[size] > C
?
Maybe set C so that a standard 1BTC transaction can get into the main
free area on the next block. And a .1 can get in after waiting about 10
blocks. And make the area which allows [age]*[value]/[size] < C to
let in about a dozen transactions or so. Yes, like this. And the
no-priority-requirement area is 3K, about a dozen transactions per
block.
I just uploaded SVN rev 185 which has a minimal priority requirement
for free transactions. Transaction floods are made up of coins that are
re-spent over and over, so they depend on their own 0 conf transactions
repeatedly. 0 conf transactions have 0 priority, so free transactions
like that will have to wait for one transaction to get into a block at a
time.
Version 0.3.15 doesn’t write transactions using 0 conf dependencies
unless that’s all it has left, so normal users shouldn’t usually have a
problem with this.
I think this is a good compromise short of making the default fee
0.01. It’s not so much to ask that free transactions can only be used to
turn coins over so often. If you’re using free transactions, you’re
taking charity and there has to be some limit on how often you can use
it with the same coins.
We’ve always said free transactions may be processed more slowly. You
can help ensure your transactions go through quickly by adding
-paytxfee=0.01.
Bitcoin Forum post — November 20, 2010 — source: 1334-23097.md
Post by: satoshi on November 20, 2010, 05:24:20 PM
Last edit: November 20, 2010, 05:39:18 PM by satoshi
Quote from: m0mchil on November 20, 2010, 10:16:19 AM
updated to SVN 186
Thanks m0mchil for keeping up on the updates!
GPU miners, please upgrade as soon as possible to shut down the free
transaction abuse! This version has the new priority-based limit on free
transaction spam.
Quote from: m0mchil on November 16, 2010, 10:30:41 AM
Just updated to SVN 181 and fixed getwork patch to wait 60 seconds
between rebuilding the block with new transactions. This is actually the
behavior of the original client, was forgotten in the patch by mistake.
Fixes heavy CPU usage on every getwork request (this became obvious with
recent heavy transaction spam). Please upgrade.
Before SVN 184, compiling transactions into a block used an n^2
algorithm. The new efficient single-pass algorithm is orders of
magnitude quicker. (O(n) vs O(n^2)/2 algorithm, n=200 maybe 10 to 100
times quicker)
Bitcoin Forum post — November 23, 2010 — source: 1901-23876.md
Post by: satoshi on November 23, 2010, 07:50:12 PM
Last edit: November 24, 2010, 04:43:43 PM by satoshi
I uploaded a redesign of m0mchil’s getwork to SVN rev 189 (version
31601)
m0mchil’s external bitcoin miner idea has solved a lot of problems.
GPU programming is immature and hard to compile, and I didn’t want to
add additional dependencies to the build. getwork allows these problems
to be solved separately, with different programs for different hardware
and OSes. It’s also convenient that server farms can run a single
Bitcoin node and the rest only run getwork clients.
The interface has a few changes:
getwork [data]
If [data] is not specified, returns formatted hash data to work
on:
“midstate” : precomputed hash state after hashing the first half of
the data
“data” : block data
“hash1” : formatted hash buffer for second hash
“target” : little endian hash target
If [data] is specified, tries to solve the block and returns true if
it was successful. [data] is the same 128 byte block data that was
returned in the “data” field, but with the nonce changed.
Notes:
- It does not return work when you submit a possible hit, only when
called without parameter.
- The block field has been separated into data and hash1.
- data is 128 bytes, which includes the first half that’s already
hashed by midstate.
- hash1 is always the same, but included for convenience.
- Logging of “ThreadRPCServer method=getwork” is disabled, it would
be too much junk in the log.
Bitcoin Forum post — November 24, 2010 — source: 1901-24095.md
Post by: satoshi on November 24, 2010, 05:21:01 PM
Last edit: November 24, 2010, 05:31:31 PM by satoshi
Quote from: jgarzik on November 24, 2010, 04:47:42 AM
I suspect something weird going on with ByteReverse (or lack
thereof). It’s quite unclear whether or not ‘data’ and ‘nonce’ must be
byte-reversed, and in what way.
getwork does the byte-reversing. midstate, data and hash1 are already
big-endian, and you pass data back still big-endian, so you work in
big-endian and don’t have to do any byte-reversing. They’re the same
data that is passed to the ScanHash_ functions. You can take midstate,
data and hash1, put them in 16-byte aligned buffers and pass them to a
ScanHash_ function, like ScanHash(pmidstate, pdata + 64, phash1,
nHashesDone). If a nonce is found, patch it into data and call
getwork.
I should probably change the ScanHash_ functions to use pdata instead
of pdata + 64 so they’re consistent.
target is little endian, it’s supposed to be the same as how
m0mchil’s did it. (if it’s not, then it should be fixed) That’s the only
case where you would use byte reverse. I think you do it like: if
ByteReverse((unsigned int*)hash[6]) < (unsigned int*)target[6].
Quote from: DiabloD3 on November 24, 2010, 11:31:11 AM
Satoshi, please fix your implementation of getwork so it complies
with m0mchill’s specification
This is the new spec. It shouldn’t be hard to update your miner to
use it.
The changes are:
- It does not return work when you submit a possible hit, only when
called without parameter.
- The block field has been split into data and hash1.
- state renamed to midstate for consistency.
- extranonce not needed.
Source file: bitcoin-forum-satoshi-nakamoto.tgz
External link:
Re: OpenCL miner for the masses
Bitcoin Forum post — November 24, 2010 — source: 1334-24101.md
Post by: satoshi on November 24, 2010, 05:53:09 PM
A revised version of getwork is now in the official client, but the
miners need to be updated a little to use it.
Re: RFC: ship block chain 1-74000 with release tarballs?
Bitcoin Forum post — November 25, 2010 — source: 1931-24438.md
Post by: satoshi on November 25, 2010, 05:51:39 PM
It’s not the downloading that takes the time, it’s verifying and
indexing it.
Bandwidthwise, it’s more efficient than if you downloaded an archive.
Bitcoin only downloads the data in blk0001.dat, which is currently 55MB,
and builds blkindex.dat itself, which is 47MB. Building blkindex.dat is
what causes all the disk activity.
During the block download, it only flushes the database to disk every
500 blocks. You may see the block count pause at ??499 and ??999. That’s
when it’s flushing.
Doing your own verifying and indexing is the only way to be sure your
index data is secure. If you copy blk0001.dat and blkindex.dat from an
untrusted source, there’s no way to know if you can trust all the
contents in them.
Maybe Berkeley DB has some tweaks we can make to enable or increase
cache memory.
Re: RFC: ship block chain 1-74000 with release tarballs?
Bitcoin Forum post — November 26, 2010 — source: 1931-24662.md
Post by: satoshi on November 26, 2010, 05:32:01 PM
I tested it on a slow 7 year old drive, where bandwidth and CPU were
clearly not the bottleneck. Initial download took 1 hour 20 minutes.
If it’s taking a lot longer than that, certainly 24 hours, then it
must be downloading from a very slow node, or your connection is much
slower than around 15KB per sec (120kbps), or something else is wrong.
It would be nice to know what appears to be the bottleneck when that
happens.
Every 10 minutes or so when the latest block is sent, it should have
the chance to change to a faster node. When the latest block is
broadcast, it requests the next 500 blocks from other nodes, and
continues the download from the one that sends it fastest. At least,
that’s how it should work.
Quote from: jgarzik on November 26, 2010, 02:07:43 AM
Quote from: satoshi on November 25, 2010, 05:51:39 PM
Maybe Berkeley DB has some tweaks we can make to enable or increase
cache memory.
Which of the ACID
properties do you need, while downloading?
It may only need more read caching. It has to read randomly all over
blk0001.dat and blkindex.dat to index. It can’t assume the file is
smaller than memory, although it currently still is. Caching would be
effective, since most dependencies are recent.
Someone should experiment with different Berkeley DB settings and see
if there’s something that makes the download substantially faster. If
something substantial is discovered, then we can work out the
particulars.
Quote
Adding BDB records is simply appending to a log file, until you issue
a checkpoint. The checkpoint then updates the main database file.
Bitcoin Forum post — November 26, 2010 — source: 1925-24719.md
Post by: satoshi on November 26, 2010, 10:02:41 PM
You should try it with tcatm’s 4-way SSE2 SHA in sha256.cpp. It
compiles fine as a C file, just rename sha256.cpp to sha256.c. I was
able to get it to work in simple tests on Windows, but not when linked
in with Bitcoin. It may have a better chance of working as part of a C
program instead of C++.
Currently it’s only enabled in the Linux build, so if you get it to
work you could make it available to Windows users. It’s about 100%
speedup on AMD CPUs.
Bitcoin Forum post — November 28, 2010 — source: 1976-25119.md
Post by: satoshi on November 28, 2010, 04:03:30 PM
Last edit: November 28, 2010, 04:25:20 PM by satoshi
ribuck’s description is spot on.
Pool operators can modify their getwork to take one additional
parameter, the address to send your share to.
The easy way for the pool operator would be to wait until the next
block is found and divy it up proportionally as:
user’s near-hits/total near-hits from everyone
That would be easier and safer to start up. It also has the advantage
that multiple hits from the same user can be combined into one
transaction. A lot of your hits will usually be from the same
people.
The instant gratification way would be to pay a fixed amount for each
near-hit immediately, and the operator takes the risk from randomness of
having more or less near-hits before a block is found.
Either way, the user who submits the hit that solves the block should
get an extra amount off the top, like 10 BTC.
New users wouldn’t really even need the Bitcoin software. They could
download a miner, create an account on mtgox or mybitcoin, enter their
deposit address into the miner and point it at anyone’s pool server.
When the miner says it found something, a while later a few coins show
up in their account.
Miner writers better make sure they never false-positive near-hits.
Users will depend on that to check if the pool operator is cheating
them. If the miner wrongly says it found something, users will look in
their account, not find anything, and get mad at the pool operator.
Re: RFC: ship block chain 1-74000 with release tarballs?
Bitcoin Forum post — November 28, 2010 — source: 1931-25138.md
Post by: satoshi on November 28, 2010, 05:13:01 PM
Last edit: November 28, 2010, 08:07:59 PM by satoshi
Despite everything else said, the current next step is:
Quote
Someone should experiment with different Berkeley DB settings and see
if there’s something that makes the download substantially faster. If
something substantial is discovered, then we can work out the
particulars.
In particular, I suspect that more read caching might help a lot.
Quote from: jgarzik on November 28, 2010, 02:33:29 AM
Another new user on IRC, Linux this time, was downloading at a rate
of 1 block every 4 seconds – estimated total download time around 4
days.
Then something more specific was wrong. That’s not due to normal
initial download time. Without more details, it can’t be diagnosed. If
it was due to slow download, did it speed up after 10-20 minutes when
the next block broadcast should have made it switch to a faster source?
debug.log might have clues. How fast is their Internet connection? Was
it steadily slow, or just slow down at one point?
Quote
We have the hashes for genesis block through block 74000 hardcoded
(compiled) into bitcoin, so there’s no reason why we shouldn’t be able
to automatically download a compressed zipfile of the block database
from anywhere, unpack it, verify it, and start running.
The 74000 checkpoint is not enough to protect you, and does nothing
if the download is already past 74000. -checkblocks does more, but is
still easily defeated. You still must trust the supplier of the
zipfile.
If there was a “verify it” step, that would take as long as the
current normal initial download, in which it is the indexing, not the
data download, that is the bottleneck.
Quote from: jgarzik on November 28, 2010, 07:33:55 AM
Presumably at some point there will be a lightweight client that only
downloads block headers, but there will still be hundreds of thousands
of those…
80 bytes per header and no indexing work. Might take 1 minute.
Quote
uncompressed data using a protocol (bitcoin P2P) that wasn’t designed
for bulk data transfer.
The data is mostly hashes and keys and signatures that are
uncompressible.
The speed of initial download is not a reflection of the bulk data
transfer rate of the protocol. The gating factor is the indexing while
it downloads.
Re: Is safe running bitcoins with the same wallet on more computers simultaneously?
Bitcoin Forum post — November 28, 2010 — source: 1986-25154.md
Post by: satoshi on November 28, 2010, 06:06:39 PM
Last edit: November 28, 2010, 06:22:45 PM by satoshi
Quote
Will it be synchronized automatically?
Very much not. Using multiple copies of wallet.dat is not recommended
or supported, in fact all of Bitcoin is designed to defeat that. Both
copies will get screwed up.
If you’re trying to consolidate your generated coins into one wallet,
a better solution now is to run getwork miners on the additional
systems. jgarzik has a CPU miner, and it supports tcatm’s 4-way SSE2, so
on Windows it’s up to twice as fast as the built-in SHA if you have an
AMD or recent Intel (core 3, 5 or 7).
Re: RFC: ship block chain 1-74000 with release tarballs?
Bitcoin Forum post — November 29, 2010 — source: 1931-25449.md
Post by: satoshi on November 29, 2010, 08:19:12 PM
Last edit: November 29, 2010, 08:53:12 PM by satoshi
It seems like you’re inclined to assume everything is wrong more than
is actually so.
Writing the block index is light work. Building the tx index is much
more random access per block. I suspect reading all the prev txins is
what’s slow. Read caching would help that. It’s best if the DB does
that. Maybe it has a setting for how much cache memory to use.
Quote
bitcoin should be opening databases, not just environment, at
program startup, and closing database at program shutdown.
Already does that. See CDB. The lifetime of the (for instance) CTxDB
object is only to support database transactions and to know if anything
is still using the database at shutdown.
Quote
And, additionally, bitcoin forces a database checkpoint, pushing all
transactions from log into main database.
If it was doing that it would be much slower. It’s supposed to be
only once a minute or 500 blocks:
if (!fReadOnly)
dbenv.txn_checkpoint(0, nMinutes, 0);
Quote
For the initial block download, txn commit should occur once every N
records, not every record. I suggest N=1000.
Does transaction commit imply flush? That seems surprising to me. I
assume a database op wrapped in a transaction would be logged like any
other database op. Many database applications need to wrap almost every
pair of ops in a transaction, such as moving money from one account to
another. (debit a, credit b) I can’t imagine they’re required to batch
all their stuff up themselves.
In the following cases, would case 1 flush once and case 2 flush
twice?
case 1:
write
write
write
write
checkpoint
case 2:
begin transaction
write
write
commit transaction
begin transaction
write
write
commit transaction
checkpoint
Contorting our database usage will not be the right approach. It’s
going to be BDB settings and caching.
Bitcoin Forum post — December 05, 2010 — source: 1735-26999.md
Post by: satoshi on December 05, 2010, 09:08:08 AM
Quote from: RHorning on December 04, 2010, 10:17:44 PM
Basically, bring it on. Let’s encourage Wikileaks to use Bitcoins and
I’m willing to face any risk or fallout from that act.
No, don’t “bring it on”.
The project needs to grow gradually so the software can be
strengthened along the way.
I make this appeal to WikiLeaks not to try to use Bitcoin. Bitcoin is
a small beta community in its infancy. You would not stand to get more
than pocket change, and the heat you would bring would likely destroy us
at this stage.
Re: JSON-RPC method idea: list transactions newer than a given txid
Bitcoin Forum post — December 08, 2010 — source: 2151-28228.md
Post by: satoshi on December 08, 2010, 08:21:49 PM
Last edit: December 08, 2010, 09:54:40 PM by satoshi
It’s not safe to use listtransactions this way.
I know I’ve been criticized for being reluctant about
listtransactions. Let me explain my reluctance.
Transactions are dynamic. Past transactions can become unconfirmed,
go away and come back, become invalid and disappear, or be replaced by a
different double-spend. Their date can change, their order can
change.
Programmers are naturally inclined to want to use listtransactions
like this: feed me the new transactions since I last asked, and I’ll
keep my own tally or static record of them. This will seem to work in
all regular use, but if you use the amounts for anything, it is highly
exploitable:
How do you know if a past transaction becomes invalid and
disappears?
When there’s a block-chain reorg, it would be easy to
double-count transactions when they get confirmed again.
A transaction can be replaced by a double-spend with a different
txid. You would count both spends.
The model where you assume you only need to see new transactions
because you’ve already seen previous transactions is not true. Old
transactions can change at any time.
Any time you take an action based on payment amounts received, you
always need to go back to bitcoin and ask for a current balance total
(or use move or sendfrom), and be ready for the possibility that it can
go down.
Now that we have the Accounts feature making it easier to do it the
right way, we’re better prepared to have listtransactions.
Re: JSON-RPC method idea: list transactions newer than a given txid
Bitcoin Forum post — December 09, 2010 — source: 2151-28313.md
Post by: satoshi on December 09, 2010, 12:12:17 AM
I’m not talking about the normal risk for a given minconf level, I’m
talking about additional pitfalls from listtransactions when used this
way.
Quote from: satoshi on December 08, 2010, 10:36:45 PM
When there’s a block-chain reorg, it would be easy to double-count
transactions when they get confirmed again.
The OP’s example of listtransactions [count=10] [txid]
seems to imply and it would be very easy for programmers to assume that
if they pass in the last txid of the previous call to listtransactions,
they will never see the same transaction more than once, which is not
the case. It would be very easy to double-count payments if you don’t
maintain your own persistent map or dictionary to track which txid’s
you’ve already accepted.
It doesn’t seem right to have a function that seems tailor made to be
used a certain obvious way, and that way is a non-obvious trap.
Quote from: jgarzik on December 08, 2010, 11:07:22 PM
Quote from: satoshi on December 08, 2010, 10:36:45 PM
A transaction can be replaced by a double-spend with a different
txid. You would count both spends.
listtransactions does not add anything to this problem, beyond that
which is already vulnerable through listreceivedbyaddress.
Suppose both spends are to the same address. getreceivedbyaddress
would always count only one or the other spend at any given time, never
both.
Using listtransactions, it would be very easy to count both. You see
the first spend, you count it. You see the second spend, you count it.
Total is double counted.
Bitcoin Forum post — December 09, 2010 — source: 2162-28533.md
Post by: satoshi on December 09, 2010, 02:37:05 PM
New transaction templates can be added as needed. Within a few days,
there will be plenty of GPU power that accepts and works on it. Network
support will be thorough long before there’ll be enough clients
who understand how to receive and interpret the new transaction.
Timestamp hashes are still already possible:
txin: 0.01
txout: 0.00 <appid, hash> OP_CHECKSIG
fee: 0.01
If there’s an actual application like BitDNS getting ready to
actually start inserting hashes, we can always add a specific
transaction template for timestamps.
I like Hal Finney’s idea for user-friendly timestamping. Convert the
hash of a file to a bitcoin address and send 0.01 to it:
Quote from: Hal on December 05, 2010, 11:43:56 PM
I thought of a simple way to implement the timestamp concept I
mentioned above. Run sha1sum on the file you want to timestamp. Convert
the result to a Bitcoin address, such as via http://blockexplorer.com/q/hashtoaddress . Then send a
small payment to that address.
The money will be lost forever, as there is no way to spend it
further, but the timestamp Bitcoin address will remain in the block
chain as a record of the file’s existence.
I understand that this is arguably not a good use of the Bitcoin
distributed database, but nothing stops people from doing this so we
should be aware that it may be done.
Bitcoin Forum post — December 09, 2010 — source: 2162-28549.md
Post by: satoshi on December 09, 2010, 03:17:53 PM
I came to agree with Gavin about whitelisting when I realized how
quickly new transaction types can be added.
Quote from: nanotube on December 09, 2010, 06:19:05 AM
why not make it easier on everyone and just allow say, 64 or 128
bytes of random data in a transaction?
That’s already possible. OP_CHECKSIG. can be 33 to
120 bytes.
I also support a third transaction type for timestamp hash sized
arbitrary data. There’s no point not having one since you can already do
it anyway. It would tell nodes they don’t need to bother to index
it.
Re: JSON-RPC method idea: list transactions newer than a given txid
Bitcoin Forum post — December 09, 2010 — source: 2151-28640.md
Post by: satoshi on December 09, 2010, 06:08:08 PM
Quote from: jgarzik on December 09, 2010, 12:58:05 AM
I agree with you and satoshi about “txs after ”. My
listtransactions (now xlisttransactions) patch pointedly does not have
that feature, and never has.
As long as the interface is designed for things like showing the user
the last N transactions history, it’s fine, now that we have the
Accounts feature making it easier to do payment detection the right
way.
Gavin, could listtransactions have an option to list transactions for
all accounts?
I’m not sure what the interface could be, maybe:
listtransactions <JSON null type> [count]
It would be hard to do that from the command line though.
I can’t think of a good solution for the interface, that’s the
problem. Maybe “*” special case like “” is. Everyone would have to make
sure no user can create account name “*“.
Quote from: jgarzik on December 09, 2010, 04:13:50 PM
Sure, and that’s easy enough to track with transactions.
I don’t get how that’s “easy” to track with transactions.
Bitcoin Forum post — December 09, 2010 — source: 0644-28643.md
Post by: satoshi on December 09, 2010, 06:28:45 PM
Thanks for setting this up Cdecker.
Is there any chance of getting it to build the GUI version also? If
this is Ubuntu, if you get wxWidgets 2.9.0 it should just be a matter of
following the steps in build-unix.txt exactly. Is this an environment
where you can build wxWidgets once and leave it there and just keep
using it?
Bitcoin Forum post — December 09, 2010 — source: 1790-28696.md
Post by: satoshi on December 09, 2010, 09:02:42 PM
I think it would be possible for BitDNS to be a completely separate
network and separate block chain, yet share CPU power with Bitcoin. The
only overlap is to make it so miners can search for proof-of-work for
both networks simultaneously.
The networks wouldn’t need any coordination. Miners would subscribe
to both networks in parallel. They would scan SHA such that if they get
a hit, they potentially solve both at once. A solution may be for just
one of the networks if one network has a lower difficulty.
I think an external miner could call getwork on both programs and
combine the work. Maybe call Bitcoin, get work from it, hand it to
BitDNS getwork to combine into a combined work.
Instead of fragmentation, networks share and augment each other’s
total CPU power. This would solve the problem that if there are multiple
networks, they are a danger to each other if the available CPU power
gangs up on one. Instead, all networks in the world would share combined
CPU power, increasing the total strength. It would make it easier for
small networks to get started by tapping into a ready base of
miners.
Bitcoin Forum post — December 09, 2010 — source: 1790-28715.md
Post by: satoshi on December 09, 2010, 10:46:50 PM
Last edit: December 09, 2010, 11:19:08 PM by satoshi
Quote from: nanotube on December 09, 2010, 09:20:40 PM
seems that the miner would have to basically do “extra work”. and if
there’s no reward from the bitdns mining from the extra work (which of
course, slows down the main bitcoin work), what would be a miner’s
incentive to include bitdns (and whatever other side chains) ?
The incentive is to get the rewards from the extra side chains also
for the same work.
While you are generating bitcoins, why not also get free domain names
for the same work?
If you currently generate 50 BTC per week, now you could get 50 BTC
and some domain names too.
You have one piece of work. If you solve it, it will solve a block
from both Bitcoin and BitDNS. In concept, they’re tied together by a
Merkle Tree. To hand it in to Bitcoin, you break off the BitDNS branch,
and to hand it in to BitDNS, you break off the Bitcoin branch.
In practice, to retrofit it for Bitcoin, the BitDNS side would have
to have maybe ~200 extra bytes, but that’s not a big deal. You’ve been
talking about 50 domains per block, which would dwarf that little 200
bytes per block for backward compatibility. We could potentially
schedule a far in future block when Bitcoin would upgrade to a
modernised arrangement with the Merkle Tree on top, if we care enough
about saving a few bytes.
Note that the chains are below this new Merkle Tree. That is, each of
Bitcoin and BitDNS have their own chain links inside their blocks. This
is inverted from the common timestamp server arrangement, where the
chain is on top and then the Merkle Tree, because that creates one
common master chain. This is two timestamp servers not sharing a
chain.
Bitcoin Forum post — December 09, 2010 — source: 2181-28729.md
Post by: satoshi on December 09, 2010, 11:58:54 PM
Not locktime.
There’s a possible design for far in the future:
You intentionally write a double-spend. You write it with the same
inputs and outputs, but this time with a fee. When your double-spend
gets into a block, the first spend becomes invalid. The payee does not
really notice, because at the moment the new transaction becomes valid,
the old one becomes invalid, and the new transaction simply takes its
place.
It’s easier said than implemented. There would be a fair amount of
work to make a client that correctly writes the double-spend, manages
the two versions in the wallet until one is chosen, handles all the
corner cases. Every assumption in the existing code is that you’re not
trying to write double-spends.
There would need to be some changes on the Bitcoin Miner side also,
to make the possibility to accept a double-spend into the transaction
pool, but only strictly if the inputs and outputs match and the
transaction fee is higher. Currently, double-spends are never accepted
into the transaction pool, so every node bears witness to which
transaction it saw first by working to put it into a block.
Bitcoin Forum post — December 10, 2010 — source: 1790-28917.md
Post by: satoshi on December 10, 2010, 05:29:28 PM
Last edit: December 11, 2010, 12:28:48 PM by satoshi
Piling every proof-of-work quorum system in the world into one
dataset doesn’t scale.
Bitcoin and BitDNS can be used separately. Users shouldn’t have to
download all of both to use one or the other. BitDNS users may not want
to download everything the next several unrelated networks decide to
pile in either.
The networks need to have separate fates. BitDNS users might be
completely liberal about adding any large data features since relatively
few domain registrars are needed, while Bitcoin users might get
increasingly tyrannical about limiting the size of the chain so it’s
easy for lots of users and small devices.
Fears about securely buying domains with Bitcoins are a red herring.
It’s easy to trade Bitcoins for other non-repudiable commodities.
If you’re still worried about it, it’s cryptographically possible to
make a risk free trade. The two parties would set up transactions on
both sides such that when they both sign the transactions, the second
signer’s signature triggers the release of both. The second signer can’t
release one without releasing the other.
Bitcoin Forum post — December 10, 2010 — source: 1790-28959.md
Post by: satoshi on December 10, 2010, 07:55:12 PM
Last edit: December 10, 2010, 10:16:10 PM by satoshi
Quote from: Hal on December 10, 2010, 07:14:04 PM
additional block chains would each create their own flavor of coins,
which would trade with bitcoins on exchanges? These chain-specific coins
would be used to reward miners on those chains, and to purchase some
kinds of rights or privileges within the domain of that chain?
Right, the exchange rate between domains and bitcoins would
float.
A longer interval than 10 minutes would be appropriate for
BitDNS.
So far in this discussion there’s already a lot of housekeeping data
required. It will be much easier if you can freely use all the space you
need without worrying about paying fees for expensive space in Bitcoin’s
chain. Some transactions:
Changing the IP record.
Name change. A domain object could entitle you to one domain, and you
could change it at will to any name that isn’t taken. This would
encourage users to free up names they don’t want anymore. Generated
domains start out blank and the miner sells it to someone who changes it
to what they want.
Renewal. Could be free, or maybe require consuming another domain
object to renew. In that case, domain objects (domaincoins?) could
represent the right to own a domain for a year. The spent fee goes to
the miners in the next block fee.
Bitcoin Forum post — December 10, 2010 — source: 1790-28963.md
Post by: satoshi on December 10, 2010, 08:19:39 PM
Last edit: December 11, 2010, 12:30:09 PM by satoshi
I agree. All transactions, IP changes, renewals, etc. should have
some fee that goes to the miners.
You might consider a certain amount of work to generate a domain,
instead of a fixed total circulation. The work per domain could be on a
schedule that grows with Moore’s Law. That way the number of domains
would grow with demand and the number of people using it.
Bitcoin Forum post — December 11, 2010 — source: 1790-29159.md
Post by: satoshi on December 11, 2010, 01:08:30 PM
@dtvan: all 3
excellent points.
IP records don’t need to be in the chain, just do registrar
function not DNS. And CA problem solved, neat.
Pick one TLD, .web +1.
Expiration and significant renewal costs, very
important.
Quote from: joe on December 11, 2010, 10:53:58 AM > > However,
thinking more about this now I support inclusion of additional coinbases
/ tracking systems in the main network. The reason for doing this is so
as not to water down CPU power into multiple networks. We want one
strong network, so the network should be versatile.
Bitcoin Forum post — December 11, 2010 — source: 2208-29165.md
Post by: satoshi on December 11, 2010, 01:32:37 PM
Quote from: da2ce7 on December 11, 2010, 05:49:22 AM
direct to IP address transfers seems like a obvious surface area to
attack.
If you ever find anyone who turned it on. It’s disabled by
default.
Quote from: witchspace on December 11, 2010, 09:59:40 AM
There is no way to be absolutely sure that there are no buffer
overflow attacks. Although it would help to implement the client in a
language that doesn’t have buffer overflows because it checks array
indices (Python, Java, C#, …).
Bitcoin Forum post — December 11, 2010 — source: 2188-29259.md
Post by: satoshi on December 11, 2010, 10:07:04 PM
Quote from: Hal on December 11, 2010, 08:08:45 PM
I’d like to hear some specific criticisms of the code. To me it looks
like an impressive job, although I’d wish for more comments. Now I’ve
mostly studied the init, main, script and a bit of net modules. This is
some powerful machinery.
Bitcoin Forum post — December 12, 2010 — source: 2228-29479.md
Post by: satoshi on December 12, 2010, 06:22:33 PM
Last edit: December 13, 2010, 04:45:48 PM by satoshi
There’s more work to do on DoS, but I’m doing a quick build of what I
have so far in case it’s needed, before venturing into more complex
ideas. The build for this is version 0.3.19.
- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all
resistant to DoS attack. This is one improvement, but there are still
more ways to attack than I can count.
I’m leaving the -limitfreerelay part as a switch for now and it’s
there if you need it.
- Removed “safe mode” alerts
“safe mode” alerts was a temporary measure after the 0.3.9 overflow
bug. We can say all we want that users can just run with
“-disablesafemode”, but it’s better just not to have it for the sake of
appearances. It was never intended as a long term feature. Safe mode can
still be triggered by seeing a longer (greater total PoW) invalid block
chain.
