/nBitcoin open source implementation of P2P currency

P2P Foundation

2009-02-11 22:27:00 UTC - Original Post

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.orgThe 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.pdfThe 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 Nakamotohttp://www.bitcoin.org/nRe: Repost: How anonymous are
bitcoins?

Bitcointalk

2009-11-25 18:17:23 UTC - Original Post

> 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:9050The 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=<someipaddress>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./nRe: Exception:
9key_error error

Bitcointalk

2010-05-16 22:53:59 UTC - Original Post

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.The code is:key.h:  EC_KEY* pkey;   Â
pkey = EC_KEY_new_by_curve_name(NID_secp256k1);Â Â Â Â if (pkey == NULL)Â Â
    throw key_error("CKey::CKey() : EC_KEY_new_by_curve_name
failed");NID_secp256k1 is a constant./nRe: removing bitcoin addresses

Bitcointalk

2010-05-16 23:34:40 UTC - Original Post

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./nRe: Setting up multiple bitcoin machines behind NAT
 Bitcointalk

2010-05-16 23:56:03 UTC - Original Post

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./nRe:
Is there a way to automate bitcoin payments for a website?

Bitcointalk

2010-05-18 02:58:11 UTC - Original Post

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:Quoteobj/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+0x4
5): In function `wxArrayString::Item(unsigned long)
const':/usr/src/bitcoin/trunk/uint256.h:526: undefined reference to
`wxOnAssert(char const*, int, char const*, char const*, wchar_t 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./nRe: Ummmm... where did my bitcoins go?

Bitcointalk

2010-05-18 20:06:46 UTC - Original Post

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./nRe: We accept Bitcoins
 Bitcointalk

2010-05-20 21:43:42 UTC - Original Post

Quote from: DataWraith on May 19, 2010, 07:52:42 PMCan 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./nJSON-RPC programming tips using labels

Bitcointalk

2010-05-26 18:27:25 UTC - Original Post

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 getaddressesbylabelFor
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
anythingif (strAddr == "" || getreceivedbyaddress(strAddr) > 0)Â Â strAddr =
getnewaddress(strUsername); // Label the address with usernameDisplay(strAddr); //
Display their current receiving address// Get total received by all the user's
addressesgetreceivedbylabel(strUsername, 0) //
unconfirmedgetreceivedbylabel(strUsername, 1) // available balanceIf 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./nRe: Tracing a coin's lineage

Bitcointalk

2010-05-26 18:51:04 UTC - Original Post

Quote from: Xunie on May 26, 2010, 12:50:04 AMCan'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./nRe: CLI bitcoin generation

Bitcointalk

2010-05-26 20:09:34 UTC - Original Post

Quote from: molybdenum on May 22, 2010, 06:44:20 PMAn 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 includedor
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./nRe: Share database blocks ?

Bitcointalk

2010-05-26 20:34:34 UTC - Original Post

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?/nRepost: Linux/UNIX
compile

Bitcointalk

2009-11-27 17:17:22 UTC - Original Post

--------------------scott:Linux/UNIX compilePosted:Thu 08 of Oct, 2009 (05:49
UTC)Can we get instructions or modifications to compile and install BitCoin on
Linux? A command line version would be great./nRe: Website translations

Bitcointalk

2010-05-26 21:16:34 UTC - Original Post

Does anyone want to translate the Bitcoin client itself? Â It would be great to
have at least one other language in the 0.3 release.All you have to do is get
poedit and translate the po file I'm attaching to this post. Â It's less than 750
words.Updated bitcoin.po attachment for 0.3.1/nRe: Odd amount of generated coins

Bitcointalk

2010-05-26 21:34:32 UTC - Original Post

 In the SVN version, if a transaction requires a transaction fee, it says"This
transaction is over the size limit. You can still send it for a fee of #,which
goes to the nodes that process your transaction and helps to support the network.Do
you want to pay the fee?"If you don't have enough money with the fee added, it
says"Total exceeds your balance when the # transaction fee is included "/nRe:
Website translations

Bitcointalk

2010-05-27 14:18:22 UTC - Original Post

Hurray! Â We have our first language. Â I uploaded it to SVN to go in with the
0.3 release./nRe: Hostnames instead of IP Addresses

Bitcointalk

2010-06-02 18:18:15 UTC - Original Post

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:1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>1.2.3.4or1auaDZCFYqa
Gx4FKS5WenNfurk2SkoDu4h<someseparatorcharacter>domain.comI 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./nRe: Proof-of-work difficulty increasing

Bitcointalk

2010-06-02 18:45:38 UTC - Original Post

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./nRe: Website translations

Bitcointalk

2010-06-02 22:18:09 UTC - Original Post

I uploaded the 93% complete Dutch translation to SVN. Thanks!/nRe: On IRC
bootstrapping

Bitcointalk

2010-06-14 18:13:21 UTC - Original Post

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?/nRe: Hostnames instead of IP Addresses

Bitcointalk

2010-06-14 19:53:44 UTC - Original Post

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./nRe: Dealing with SHA-256 Collisions

Bitcointalk

2010-06-14 20:39:50 UTC - Original Post

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. /nRe:
Technical clarifications

Bitcointalk

2010-06-14 22:21:55 UTC - Original Post

3) Nothing, if sending by bitcoin address5) It is decentralised. After you have
connected to the network the first time, you no longer need IRC. /nRe: Repost:
Linux/UNIX compile

Bitcointalk

2009-11-27 17:27:09 UTC - Original Post

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.Command line is on the to-do list after 0.2./nRe: Can't Build
r80 from SVN
 Bitcointalk

2010-06-14 22:40:14 UTC - Original Post

Sorry, I didn't test compile on linux the last few revisions.Reverted
makefile.unix./nRe: What is the incentive to collect transactions?

Bitcointalk

2010-06-15 23:41:29 UTC - Original Post

Quote from: theymos on June 05, 2010, 04:26:09 PMAdding transactions to the block
you're working on will slow down your generation rateThe 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./nRe: URI-scheme for bitcoin

Bitcointalk

2010-06-16 00:15:47 UTC - Original Post

http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345orhttp://
127.0.0.1:8330/?to=<bitcoinaddress><separatorchar>1.2.3.4&amount=200.00But 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:http://bitcointalk.org/index.php?topic=63.msg1589#msg1589and if that's
true, then what about that example freenet link that had 127.0.0.1 in it?/nRe:
Website translations

Bitcointalk

2010-06-16 16:53:34 UTC - Original Post

Thanks DataWraith! The German translation is uploaded to SVN.This is great,
we've already got 3 major languages./nRe: new binary release?

Bitcointalk

2010-06-17 17:07:56 UTC - Original Post

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!)./nRe: Transactions and Scripts: DUP
HASH160 ... EQUALVERIFY CHECKSIG

Bitcointalk

2010-06-17 18:46:08 UTC - Original Post

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./nRe: Transactions and Scripts: DUP HASH160 ... EQUALVERIFY
CHECKSIG

Bitcointalk

2010-06-18 16:17:14 UTC - Original Post

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 PMI 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 PMHow 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./nRe: On IRC bootstrapping

Bitcointalk
 2010-06-18 17:28:18 UTC - Original Post
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. Â /nRe: Get 5 free bitcoins from freebitcoins.appspot.com

Bitcointalk

2010-06-18 23:08:34 UTC - Original Post

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./nRe: Bitcoin in Ubuntu 10.04

Bitcointalk

2010-06-21 17:20:21 UTC - Original Post

Quote from: NewLibertyStandard on May 23, 2010, 04:28:12 PMBitcoin 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.1) Menu bar default
color.2) Balance bar not a different color.3) 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-editorapps->metacity-
>generalbutton_layout=menu:minimize,maximize,closeThey've got it awfully buried
considering 9 out of 10 users are used to having it on the right./n[OLD THREAD]
Bitcoin version 0.2 development status

Bitcointalk

2009-11-27 22:48:39 UTC - Original Post

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 downloadI'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: - Multi-processor support
for coin generation - Proxy support/nRe: Dying bitcoins

Bitcointalk

2010-06-21 17:48:26 UTC - Original Post

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 PMI 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./nRe: Proof-of-work difficulty increasing

Bitcointalk

2010-06-21 18:09:17 UTC - Original Post

I integrated the hashmeter idea into the SVN version. It displays khash/s in
the left section of the status bar.Two new log messages:21/06/2010 01:23
hashmeter  2 CPUs  799 khash/s21/06/2010 01:23 generated 50.00grep your
debug.log for "generated" to see what you've generated, and grep for "hashmeter" to
see the performance. On windows, use: findstr "hashmeter generated" "%appdata%\
bitcoin\debug.log"I have the hashmeter messages once an hour. How often do you
think it should be?/nRe: Bitcoin in Ubuntu 10.04

Bitcointalk

2010-06-22 03:45:56 UTC - Original Post

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.Updated SVN.Thanks for testing./n0.3 almost ready -- please test the Mac
version!

Bitcointalk

2010-06-22 04:01:53 UTC - Original Post

I finished everything on my list to do for version 0.3. Â The code on SVN is
about ready to release.Testing at this point is much appreciated./nRe: How fast do
the fastest computers generate bitcoins?

Bitcointalk

2010-06-22 04:35:26 UTC - Original Post

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./nRe: Bitcoin in Ubuntu 10.04

Bitcointalk

2010-06-22 16:39:43 UTC - Original Post

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./nRe:
Proof-of-work difficulty increasing

Bitcointalk

2010-06-22 16:51:14 UTC - Original Post

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./nRe: 0.3 almost ready
 Bitcointalk

2010-06-22 17:02:07 UTC - Original Post

Quote from: lachesis on June 22, 2010, 06:20:02 AMIt 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./nRe:
0.3 almost ready

Bitcointalk

2010-06-22 17:37:08 UTC - Original Post

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:\program files\bitcoin"/nRe: 0.3 almost
ready

Bitcointalk

2010-06-22 19:11:41 UTC - Original Post

Quote from: davidonpda on June 22, 2010, 06:23:26 PMEXCEPTION:
22DbRunRecoveryExceptionDBENv::open: DB_RUNRECOVERY: Fatal error, run database
recoveryC:\Program Files\Bitcoin\bitcoin.exe in OnInit()What operating system?
Normally when it does that it's because the directory where the data directory
should go doesn't exist. Â See if the "%appdata%" directory exists.Do you get that
error with 0.2 also? Â It's hard to see how you could get that with 0.3 and not
with 0.2 since there's nothing different in that regard./nRe: A few suggestions

Bitcointalk

2009-12-09 18:45:10 UTC - Original Post

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?/nRe: 0.3 almost ready

Bitcointalk

2010-06-22 19:25:13 UTC - Original Post

davidonpda, were you also running laszlo's build previously?Check if the
"%appdata%" directory exists, and "%appdata%\bitcoin"Try:Â rename "%appdata%\
bitcoin" bitcoin2 does it work then?/nRe: 0.3 almost ready

Bitcointalk

2010-06-22 19:46:23 UTC - Original Post

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\
log.000000000* 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./nRe: 0.3 almost ready

Bitcointalk

2010-06-22 22:23:39 UTC - Original Post

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)/nRe:
0.3 almost ready

Bitcointalk

2010-06-24 17:40:05 UTC - Original Post

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./nRe: 0.3 almost ready

Bitcointalk
 2010-06-25 02:17:41 UTC - Original Post
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.Do you think I should make
the directories:/bin32//bin64/instead of/bin/32//bin/64//nRe: 0.3 almost ready

Bitcointalk

2010-06-25 14:10:06 UTC - Original Post

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./nRe: Bitcoin clients
getting k-lined from the IRC bootstrapping channel

Bitcointalk

2010-06-25 21:15:15 UTC - Original Post

We need more details about what happened MadHatter.Both 0.2 and 0.3 have a backup
way of getting connected without IRC, it's just slower to get connected.0.2 can
find other nodes without IRC if it's ever been connected before, but a new install
can't discover the network for the first time without IRC.0.3 can also seed without
IRC. It can operate entirely without IRC if it needs to, but it's better having
IRC for redundancy./nRe: On IRC bootstrapping

Bitcointalk

2010-06-25 22:40:47 UTC - Original Post

Quote from: laszlo on June 14, 2010, 06:30:58 PMI 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.My box is
a dedicated irc server:Â 2:28PMÂ up 838 days, 20:54, 1 user, load averages: 0.06,
0.08, 0.08You can use irc.lfnet.org to connect.This seems like a good idea.What
does everyone think, should we make the switch for 0.3?/nRe: 0.3 almost ready

Bitcointalk

2010-06-26 00:32:09 UTC - Original Post

Lets try using Laszlo's irc.lfnet.org instead of freenode. Â Here's RC2, that's
the only change in it:(see below for download links)/nRe: Bitcoin clients getting
k-lined from the IRC bootstrapping channel

Bitcointalk

2010-06-26 14:28:06 UTC - Original Post

Freenode is too visible, right in the middle of where all those users and
moderators are hanging out. Laszlo's option is a much better fit for us.I made
0.3.0.RC2 available that uses irc.lfnet.org instead of freenode if you want to
start switching
over:http://bitcointalk.org/index.php?topic=199.msg1787#msg1787/nRe: A few
suggestions

Bitcointalk

2009-12-10 19:31:49 UTC - Original Post

Quote from: madhatter2 on December 10, 2009, 02:00:17 PMFront 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.QuoteThe 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.QuoteAlso 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.QuoteCan 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.QuoteI 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./nRe: 0.3 almost ready

Bitcointalk

2010-06-26 15:10:10 UTC - Original Post

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./nBeta?

Bitcointalk

2010-06-26 17:02:43 UTC - Original Post

Is it about time we lose the Beta? I would make this release version 1.3./nRe:
1.3 almost ready

Bitcointalk

2010-06-26 19:21:05 UTC - Original Post

Changed the version number to 1.3 and removed "Beta".(links removed, see
below)Uses irc.lfnet.org./nRe: Bitcoin mobile.

Bitcointalk

2010-06-26 20:58:26 UTC - Original Post

Quote from: sirius-m on June 10, 2010, 01:51:16 PMYou 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./nRe: Building BitCoin Client completely Headless

Bitcointalk

2010-06-26 21:06:06 UTC - Original Post

The linux release candidate in the "1.3 almost ready" thread contains prebuilt
bitcoind./nRe: Bitcoin Faucet changes

Bitcointalk

2010-06-26 21:39:52 UTC - Original Post

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./nRe: Beta?

Bitcointalk

2010-06-27 12:43:50 UTC - Original Post

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)/nRe: IPv6, headless client, and more

Bitcointalk

2010-06-27 13:02:38 UTC - Original Post

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./nRe: 1.3 almost ready

Bitcointalk

2010-06-27 15:30:13 UTC - Original Post

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?/nRe: Major Meltdown

Bitcointalk
 2010-06-27 19:06:09 UTC - Original Post
Here's an answer to a similar question about how to recover from a major
meltdown.https://www.bitcoin.org/smf/index.php?topic=191.msg1585#msg1585Quote from:
satoshi on June 14, 2010, 08:39:50 PMIf 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. /nRe: Questions about Bitcoin

Bitcointalk

2009-12-10 20:49:02 UTC - Original Post

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%\Bitcoin
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./nRe: Feature Request: Limiting Connections

Bitcointalk

2010-07-02 19:21:36 UTC - Original Post

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?/nRe: 1.3 almost ready

Bitcointalk

2010-07-02 20:37:17 UTC - Original Post

 Quote from: dkaparis on June 27, 2010, 10:02:25 PMOn a related note, is the thing
compilable by Visual C++? I'm inclined to give it a try when I get around to it.It
is, but generating is more than twice as slow./nRe: 0.3 almost ready

Bitcointalk

2010-07-02 21:57:45 UTC - Original Post

(reverted to rc2)Links removed, 0.3 is now released, so go to
http://www.bitcoin.org to download it./nRe: Beta?

Bitcointalk

2010-07-02 22:03:41 UTC - Original Post

OK, back to 0.3 then.Please download RC4 and check it over as soon as possible.
 I'd like to release it soon.http://bitcointalk.org/index.php?
topic=199.msg1927#msg1927Other 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./nRe: Feature Request: Limiting Connections

Bitcointalk

2010-07-02 22:20:20 UTC - Original Post

I reduced max outbound connections from 15 to 8 in RC4.15 was way more than we
needed for redundancy. Â 8 is still plenty of redundancy.As the nodes upgrade to
this version, this will cut in half the number of connections that inbound
accepting nodes get.If anyone wants more than 8 connections, they can open port
8333 on their firewall./nRe: 0.3 almost ready -- please test the Mac version!

Bitcointalk

2010-07-04 21:52:28 UTC - Original Post

Laszlo's build is going to be our first Mac release so please test it!/nRe:
Slashdot Submission for 1.0

Bitcointalk

2010-07-05 21:31:14 UTC - Original Post

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./nBitcoin 0.3 released!

Bitcointalk

2010-07-06 18:32:35 UTC - Original Post

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
http://www.bitcoin.org or read the forum to find out more./nRe: 0.3 almost ready --
please test the Mac version!

Bitcointalk

2010-07-06 19:43:18 UTC - Original Post

0.3 releasedhttp://bitcointalk.org/index.php?topic=238.msg2004#msg2004/nRe: On
IRC bootstrapping

Bitcointalk

2010-07-07 01:31:07 UTC - Original Post

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 PMYou 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./nRe: Questions about Bitcoin

Bitcointalk

2009-12-11 17:58:57 UTC - Original Post

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./nRe: bitcoin 0.3 win64 - broken access to APPDATA if non-
latin characters in username

Bitcointalk

2010-07-08 18:24:19 UTC - Original Post

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?/nRe: Anonymity

Bitcointalk

2010-07-08 19:12:00 UTC - Original Post

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./nRe: bitcoin 0.3 win64 - broken access to APPDATA if non-latin
characters in username

Bitcointalk

2010-07-09 03:01:35 UTC - Original Post

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./nRe: BTC Vulnerability? (Massive
Attack against BTC system. Is it really?)

Bitcointalk

2010-07-09 03:28:46 UTC - Original Post

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]"http://en.wikipedia.org/wiki/Cornering_the_market/nRe: bitcoin 0.3 win64 -
broken access to APPDATA if non-latin characters in username

Bitcointalk

2010-07-09 15:37:05 UTC - Original Post

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./nRe: Security

Bitcointalk

2010-07-10 12:58:02 UTC - Original Post

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.void ThreadIRCSeed(void* parg){Â Â if
(mapArgs.count("-connect"))Â Â Â Â return;/nRe: Major Meltdown

Bitcointalk

2010-07-10 13:36:17 UTC - Original Post

Quote from: llama on July 01, 2010, 10:21:47 PMHowever, 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)/nRe: No
blocks downloaded... why?

Bitcointalk

2010-07-14 16:22:03 UTC - Original Post

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?/nRe: resource hog

Bitcointalk

2010-07-14 16:29:39 UTC - Original Post

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./nRe: stopped prodicing coins

Bitcointalk

2010-07-14 17:04:02 UTC - Original Post

Thanks for making that calculator.The difficulty doubled a day or two ago, plus
it's just random and you can have surprisingly long dry spells./nRe: A few
suggestions

Bitcointalk

2009-12-11 19:27:55 UTC - Original Post

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 AMIf 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=0You 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 -genTo 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.QuoteI 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. Â QuoteIn any event, I would like to help. I have a lot of
time and a project like this one is very exciting.That's great, any help is really
appreciated!/nRe: Building Bitcoin 0.3

Bitcointalk

2010-07-14 17:34:50 UTC - Original Post

It doesn't work with wxWidgets 2.8, it needs wxWidgets 2.9. Unfortunately,
there isn't a Debian package of wxWidgets 2.9 yet./nRe: bitcoin auto-renice-ing

Bitcointalk

2010-07-14 17:38:31 UTC - Original Post

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./nRe: Stuck
on 513 blocks

Bitcointalk

2010-07-14 18:02:28 UTC - Original Post

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./nRe: Error on
Ubuntu 10.04

Bitcointalk

2010-07-14 18:25:41 UTC - Original Post

What language is your computer set to? Is it set to German, Dutch or Italian?Â
Is it one of those sub-languages like "nl-??"?It's trying to load a translation and
failing. You could delete the locale directory that came with bitcoin so it
doesn't try to use it.Can someone test each language on Ubuntu and see if there's a
problem with just one of them or maybe all three?/nRe: Runaway CPU usage for 64bit
BitCoin (Linux Client)

Bitcointalk

2010-07-14 18:45:53 UTC - Original Post

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 PMOn 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./nRe: Warning this
block was not received by any other nodes

Bitcointalk

2010-07-14 18:56:29 UTC - Original Post

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./nRe: Hash/sec Throttling for Democracy

Bitcointalk

2010-07-14 20:25:06 UTC - Original Post

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./nRe:
Scalability

Bitcointalk

2010-07-14 21:10:52 UTC - Original Post

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./nRe: Runaway CPU usage for 64bit BitCoin (Linux Client)

Bitcointalk
 2010-07-15 00:18:23 UTC - Original Post
OK, the undocumented switch "-minimizetotray" which re-enables the option.I
uploaded the change to SVN./nRe: [Bitcoin 0.3.0] Runtime error

Bitcointalk

2010-07-15 14:05:20 UTC - Original Post

More directly, this:http://bitcointalk.org/index.php?topic=246.0I will be posting
release candidate of 0.3.1 with this fix shortly. Please try that and let me know
if it fixes the problem./nRe: A few suggestions

Bitcointalk

2009-12-12 17:52:44 UTC - Original Post

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./nRe: Static Linux x86_64 bins for those
having libcrypto troubles

Bitcointalk

2010-07-15 14:33:04 UTC - Original Post

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./nRe: resource hog

Bitcointalk

2010-07-15 14:59:00 UTC - Original Post

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%./nBitcoin 0.3.1 released

Bitcointalk

2010-07-15 17:05:54 UTC - Original Post

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.orgChanges:- Added Portuguese translation by
Tiago FariaWindows- Fix for 22DbRunRecoveryException if your username has non-ascii
characters in itLinux- 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/nRe: 0.3.1 release
candidate, please test

Bitcointalk

2010-07-15 17:23:48 UTC - Original Post

Well, it can't hurt to do a backup and it's a good idea to backup regularly, but
no, a backup is not required before installing this./nRe: 0.3.1 release candidate,
please test

Bitcointalk
 2010-07-15 17:56:43 UTC - Original Post
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./nRe: Website and software translations

Bitcointalk

2010-07-15 18:30:22 UTC - Original Post

Quote from: aidos on July 15, 2010, 12:49:11 AMOk 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 AM2. 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 AM4.
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./nRe: Website and software
translations

Bitcointalk

2010-07-15 18:37:13 UTC - Original Post

I uploaded an updated bitcoin.po for 0.3.1 attached to this
message:http://bitcointalk.org/index.php?topic=151.msg1259#msg1259please use it if
you're starting a new translation.If you already have a po file, poedit can update
it. - Get the src directory from the 0.3.1 release candidate posted in the
development forum, any version will do:http://bitcointalk.org/index.php?
topic=383.0- Make a subdirectory under src: locale/??/LC_MESSAGES(?? could be
anything really, "en" or your language 2-letter code)- Put your .po file there-
Open it with poedit- In poedit, Catalog->Update from sourcesThe key is that the src
directory with the sourcefiles needs to be 3 directories up from the .po file./nRe:
Website and software translations

Bitcointalk

2010-07-15 18:43:54 UTC - Original Post

Quote from: SmokeTooMuch on July 13, 2010, 06:55:55 PMI recommend to remove the
download links at the bottom of the main page.As you can see the links on the
English page points to the new 0.3 release, but the other languages only contain
links for the old 0.2 version.There's a download box with the current releases on
the right anyway, so why not remove the links from the translated pages.I updated
them to 0.3.0.I am tempted to remove the download links from the other languages
and only keep it on English.They will need to be updated for 0.3.1 soon. Perhaps
there's a way for someone to manage the updating of the translated drupal
pages./nRe: Website and software translations

Bitcointalk

2010-07-15 19:12:14 UTC - Original Post

Thanks for the Spanish and French translations! The edited and updated .po
files are attached.I uploaded these to the SVN./nRe: 0.3.1 release candidate,
please test

Bitcointalk

2010-07-15 21:40:34 UTC - Original Post

Quote from: knightmb on July 15, 2010, 07:37:10 PMOn 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?/nBitcoin open source implementation of P2P currency

P2P Foundation

2009-02-15 16:42:00 UTC - Original Post

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./nRe: A few suggestions

Bitcointalk

2009-12-12 18:17:10 UTC - Original Post

Quote from: madhatter2 on December 12, 2009, 06:34:21 AMI 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.QuoteI 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./nRe: 0.3.1 release candidate, please test

Bitcointalk

2010-07-15 22:07:35 UTC - Original Post

Quote from: knightmb on July 15, 2010, 08:15:46 PMOn 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!http://www.bitcoin.org/download/bitcoin-0.3.1.rc2-linux.tar.gz/nRe:
0.3.1 release candidate, please test

Bitcointalk

2010-07-15 22:10:19 UTC - Original Post

Quote from: db on July 15, 2010, 08:39:08 PMThe listreceivedbyaddress and
getreceivedbyaddress commands are duplicated in bincoind help. (Same in 0.3.0.)Yes
a bug. It'll have to be fixed in the next version./nRe: "SetIcons(): icon bundle
doesn't contain any suitable icon"

Bitcointalk

2010-07-15 22:18:26 UTC - Original Post

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?/nRe: Runaway CPU usage for 64bit BitCoin (Linux Client)

Bitcointalk

2010-07-15 22:22:30 UTC - Original Post

The fix for the thread priority level on linux is available in the 0.3.1 release
candidate here:http://bitcointalk.org/index.php?topic=383.msg3198#msg3198/nRe:
0.3.1 release candidate, please test

Bitcointalk

2010-07-15 23:23:04 UTC - Original Post

Quote from: RHorning on July 15, 2010, 10:29:28 PMI 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./nRe: "SetIcons():
icon bundle doesn't contain any suitable icon"

Bitcointalk

2010-07-15 23:41:23 UTC - Original Post

Quote from: bdonlan on July 15, 2010, 11:27:14 PMin 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./nRe: 0.3.1 release candidate,
please test

Bitcointalk

2010-07-16 00:44:32 UTC - Original Post

Run it with the undocumented switch -minimizetotray and the option is available
in the options menu.I don't know how to fix it. It's something wrong deep inside
wxWidgets or GTK or Gnome./nRe: Donations to freebitcoins.appspot.com needed!

Bitcointalk

2010-07-16 02:02:07 UTC - Original Post

5 BTC seems like a lot these days, maybe the normal amount should be 1 or 2
BTC.This is an important service so new users can at least get something if
generating is too hard./nRe: "SetIcons(): icon bundle doesn't contain any suitable
icon"

Bitcointalk

2010-07-16 02:43:29 UTC - Original Post

That must be it then.It must be looking for a larger icon like 20x20 but we don't
have one./nRe: Proof-of-work difficulty increasing

Bitcointalk

2010-07-16 14:46:12 UTC - Original Post

The proof-of-work difficulty is currently 45.38. (see
http://www.alloscomp.com/bitcoin/calculator.php)Â 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./nRe: A few suggestions

Bitcointalk

2009-12-13 16:51:25 UTC - Original Post

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./nRe:
Assertion Failure - Ubuntu Lucid

Bitcointalk

2010-07-16 14:52:04 UTC - Original Post

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?/nRe: Fedora 13 libcrypto

Bitcointalk
 2010-07-16 14:55:23 UTC - Original Post
Please try the 0.3.1 release candidate, it should at least resolve the libcrypto
dependency:http://bitcointalk.org/index.php?topic=383.0Let me know if that
works./nRe: Resending transaction

Bitcointalk

2010-07-16 15:01:33 UTC - Original Post

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./nRe: 0.3.1 release candidate, please test

Bitcointalk

2010-07-16 15:09:59 UTC - Original Post

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./nRe:
Source code documentation

Bitcointalk

2010-07-16 15:37:00 UTC - Original Post

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.Sorry to be a
wet blanket./nRe: Hash() function not secure

Bitcointalk

2010-07-16 16:13:53 UTC - Original Post

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./nRe:
Request: expected bitcoins per day display

Bitcointalk

2010-07-16 16:47:14 UTC - Original Post

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./nRe: Proof-of-work
difficulty increasing

Bitcointalk

2010-07-16 16:56:54 UTC - Original Post

It adjusted to 181.54 a few minutes ago. Typical time to get a block is about a
week now.The difficulty can adjust down as well as up.The network should be
generating close to 6 blocks per hour now./nRe: Source code documentation

Bitcointalk

2010-07-16 17:15:47 UTC - Original Post

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./nRe: 0.3.1 release candidate,
please test

Bitcointalk

2010-07-16 17:26:17 UTC - Original Post

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./nRe: A few suggestions

Bitcointalk

2009-12-14 17:15:56 UTC - Original Post

Quote from: madhatter2 on December 14, 2009, 03:01:39 PMCan anyone shed some
light here?g++ -c -O0 -Wno-invalid-offsetof -Wformat -g -D__WXMAC__ -DNOPCH -
DBUILD_MACOSX -I"/usr/include" -I"/usr/local/include/wx-2.8" -I"/usr/local/include"
-I"/usr/local/boost_1_41_0" -I"/sw/include/db4" -I"/usr/local/ssl/include"
-I"/usr/local/lib/wx/include/mac-ansi-release-2.8" -o headers.h.gch
headers.h...ui.h:430: error: no matching function for call to
'wxTextCtrl::SetValue(const std::basic_string<char, std::char_traits<char>,
std::allocator<char> >&)'/usr/local/include/wx-2.8/wx/textctrl.h:303: note:
candidates are: virtual void wxTextCtrlBase::SetValue(const wxString&)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)http://docs.wxwidgets.org/stable/wx_cppconst.html"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__"/nRe: Proof-of-work difficulty
increasing

Bitcointalk

2010-07-16 17:29:28 UTC - Original Post

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. /nRe: bitcoin trademark?

Bitcointalk

2010-07-16 17:47:05 UTC - Original Post

No, not related at all./nRe: The dollar cost of bitmining energy

Bitcointalk

2010-07-16 17:58:44 UTC - Original Post

Neat chart.Difficulty just increased by 4 times, so now your cost is
US$0.02/BTC./nRe: Website integration for bitcoin

Bitcointalk

2010-07-16 18:23:04 UTC - Original Post

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./nRe: Proof-of-work difficulty increasing

Bitcointalk

2010-07-16 18:43:51 UTC - Original Post

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:http://nullvoid.org/bitcoin/statistix.php/nSample account system using JSON-
RPC needed

Bitcointalk

2010-07-16 19:45:10 UTC - Original Post

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 <username>). 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 <username> 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.vekja.net is an example of a site like this./nRe: Bitcoin 0.3.1
released

Bitcointalk

2010-07-16 21:06:57 UTC - Original Post

I uploaded windows 0.3.1 rc1 and linux 0.3.1 rc2 to SourceForge and updated the
links on the homepage.You don't need to update to 0.3.1 unless you had one of the
problems listed in the first post. If you've got it working already, stay with
0.3.0./nRe: A New Currency System for the World

Bitcointalk

2010-07-16 22:20:09 UTC - Original Post

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./nRe: BUG Report: Rounding glitch

Bitcointalk

2010-07-17 16:06:12 UTC - Original Post

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
or1.140000001.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)/nRe: Privacy versus Safety: handling
change

Bitcointalk

2010-07-17 16:27:39 UTC - Original Post

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./nRe: A few suggestions

Bitcointalk

2009-12-15 20:37:32 UTC - Original Post

Quote from: madhatter2 on December 15, 2009, 05:21:09 AMIt 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.QuoteOne 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?/nRe:
Nenolod, the guy that wants to prove Bitcoin doesn't work.

Bitcointalk

2010-07-17 16:56:06 UTC - Original Post

0.3.2 has some security safeguards to lock in the block chain up to this point
and limit the damage a little if someone gets 50%.But if someone has 50%+ of the
CPU power and malicious intent, they can prove what it already says in the design
document./nBitcoin 0.3.2 released

Bitcointalk

2010-07-17 21:35:51 UTC - Original Post

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./nRe: Bitcoin snack machine (fast transaction problem)

Bitcointalk

2010-07-17 22:29:13 UTC - Original Post

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 Â Â Â Â 04 Â Â
  116     464     1680%    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./nRe: Assertion Failure -
Ubuntu Lucid

Bitcointalk

2010-07-17 22:37:06 UTC - Original Post

Quote from: singpolyma on July 17, 2010, 10:19:48 PMMy coins disappeared, but I
assume they'll come back when it's up to current?Right, they'll re-appear when it's
finished downloading all the blocks. /nRe: Bitcoin 0.3.2 released

Bitcointalk

2010-07-17 22:54:24 UTC - Original Post

Quote from: llama on July 17, 2010, 09:56:25 PMHowever, 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 PMAlso, 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./nRe: Source code
documentation

Bitcointalk

2010-07-17 23:18:30 UTC - Original Post

I didn't realize you were going to document all the intentionally undocumented
commands. They're unsupported and not intended to be used by users.All the user-
facing commands are listed in the -? help./nRe: Network Size

Bitcointalk

2010-07-17 23:25:16 UTC - Original Post

Quote from: NewLibertyStandard on July 17, 2010, 10:22:09 PMVersion 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.Please upgrade to 0.3.2, it's
available now./nRe: Bitcoin snack machine (fast transaction problem)

Bitcointalk

2010-07-18 01:59:15 UTC - Original Post

Quote from: llama on July 18, 2010, 12:03:29 AMThis 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./nRe: Source code documentation

Bitcointalk

2010-07-18 15:12:54 UTC - Original Post

They're only intended for intrepid programmers who read the sourcecode./nRe: URI-
scheme for bitcoin
 Bitcointalk

2010-07-18 16:06:16 UTC - Original Post

Quote from: lachesis on June 16, 2010, 06:14:05 AMI 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 AMYeah, 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.I'll get started on
adding the password field./nBitcoin 0.2 released!

Bitcointalk

2009-12-16 22:45:36 UTC - Original Post

Bitcoin version 0.2 is here!Download
links:http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32-
setup.exe/downloadhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-
0.2.0-win32.zip/downloadhttp://sourceforge.net/projects/bitcoin/files/Bitcoin/
bitcoin-0.2.0-linux.tar.gz/downloadNew FeaturesMartti 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 downloadMajor 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./nRe: Bitcoin 0.3.2
released

Bitcointalk

2010-07-18 18:58:21 UTC - Original Post

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./nJSON-RPC password

Bitcointalk

2010-07-18 20:49:22 UTC - Original Post

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=<password>, which
is also used with bitcoind.bitcoin -rpcpw=<password> Â Â -- runs with JSON-RPC
port openbitcoind -rpcpw=<password> Â -- daemon with passwordIf 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?1) 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.2) 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:getaddressesbylabel <pw> <label>getbalance <pw>getblockcount
<pw>getblocknumber <pw>getconnectioncount <pw>getdifficulty <pw>getgenerate
<pw>getinfo <pw>getlabel <pw> <bitcoinaddress>getnewaddress <pw>
[label]getreceivedbyaddress <pw> <bitcoinaddress> [minconf=1]getreceivedbylabel
<pw> <label> [minconf=1]help <pw>listreceivedbyaddress <pw> [minconf=1]
[includeempty=false]listreceivedbylabel <pw> [minconf=1]
[includeempty=false]sendtoaddress <pw> <bitcoinaddress> <amount> [comment]
[comment-to]setgenerate <pw> <generate> [genproclimit]setlabel <pw>
<bitcoinaddress> <label>stop <pw>/nRe: MSVC build & SHA-256

Bitcointalk

2010-07-18 21:24:09 UTC - Original Post

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)/nRe: Nenolod, the guy that wants to prove
Bitcoin doesn't work.

Bitcointalk

2010-07-18 21:56:18 UTC - Original Post

Typically, over 25,000 BTC./nRe: Did block generation crawl to a halt?

Bitcointalk

2010-07-18 23:35:27 UTC - Original Post

Nice graph! Â A moving average to smooth it out would be
nice.http://nullvoid.org/bitcoin/statistix.php says 212 blocks in the last 24
hours, or 8.8 per hour./nRe: JSON-RPC password

Bitcointalk
 2010-07-19 04:43:13 UTC - Original Post
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?)/nWarning: don't use -server or bitcoind where you
web browse (v0.3.2 and lower)

Bitcointalk

2010-07-19 16:01:38 UTC - Original Post

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./nRe: JSON-RPC password

Bitcointalk

2010-07-19 16:20:50 UTC - Original Post

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 PMI 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?/nRe: They want to delete the Wikipedia
article

Bitcointalk

2010-07-20 18:38:28 UTC - Original Post

Bitcoin is an implementation of Wei Dai's b-money proposal
http://weidai.com/bmoney.txt on Cypherpunks
http://en.wikipedia.org/wiki/Cypherpunks in 1998 and Nick Szabo's Bitgold proposal
http://unenumerated.blogspot.com/2005/12/bit-gold.htmlThe 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)/nRe: JSON-RPC password

Bitcointalk

2010-07-21 00:05:20 UTC - Original Post

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:# commentsetting=valueIs 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./nRe: A few
suggestions

Bitcointalk

2009-12-17 18:38:06 UTC - Original Post

That's good, is it running fine on FreeBSD?I committed the changes to
headers.h. For consistency, I used __BSD__. The complete list of defines is at
http://docs.wxwidgets.org/stable/wx_cppconst.html#ifdef __BSD__#include
<netinet/in.h>#endifmalloc.h is only needed on windows, I'll move that into the
__WXMSW__ section before it causes any more trouble./nRe: JSON-RPC password

Bitcointalk

2010-07-21 05:51:34 UTC - Original Post

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:1) No comments! Â How can you have a config file where you
can't comment out a line to disable it?2) 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 bothBoost 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:# commentkey :
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:#
commentkey : value/nRe: JSON-RPC password

Bitcointalk

2010-07-21 16:07:57 UTC - Original Post

Quote from: gavinandresen on July 21, 2010, 12:11:10 PMI 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
clearkey some full sentence with spaces in it. # than thisAllright then, lets go
with self-parsed mapConfig, syntax:# commentkey=valuefile 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      = valuekey   Â
 = valuelongerkey =  this sentence would be this  # "this sentence would be
this"    key = value  # guess this is ok too nextkey = value  Â
right = justifiedThe normal syntax should be "key=value", but you can't blame
people for the occasional "key = value"./nRe: JSON-RPC password

Bitcointalk

2010-07-21 17:31:09 UTC - Original Post

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./nRe: JSON-RPC password

Bitcointalk

2010-07-22 02:34:23 UTC - Original Post

Quote from: gavinandresen on July 22, 2010, 01:11:26 AMTODO: dialog box or
debug.log warning if no rpc.user/rpc.password is set, explaining how to set.In many
of the contexts of this RPC stuff, you can print to the console with
fprintf(stdout, like this:#if defined(__WXMSW__) && wxUSE_GUIÂ Â Â Â
MyMessageBox("Warning: rpc password is blank, use -rpcpw=<password>\n", "Bitcoin",
wxOK | wxICON_EXCLAMATION);#else    fprintf(stdout, "Warning: rpc password
is blank, use -rpcpw=<password>\n");#endif/nRe: JSON-RPC password

Bitcointalk

2010-07-23 17:07:40 UTC - Original Post

Quote from: gavinandresen on July 23, 2010, 03:11:45 PMQuestion 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./nRe: JSON-RPC
password

Bitcointalk

2010-07-23 17:14:31 UTC - Original Post

Gavin's changes look good. I think everything is complete. Here's a test
build, please test it!http://www.bitcoin.org/download/bitcoin-0.3.2.5-
win32.ziphttp://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gz/nRe: bitcoind
not responding to RPC

Bitcointalk

2010-07-23 17:23:47 UTC - Original Post

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"}./nFaster initial block
download (5x faster)

Bitcointalk

2010-07-23 18:24:56 UTC - Original Post

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:http://www.bitcoin.org/download/bitcoin-0.3.2.5-win32.ziphttp://
www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gzThese 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./nRe: Faster initial block download

Bitcointalk

2010-07-23 20:13:27 UTC - Original Post

Quote from: knightmb on July 23, 2010, 07:32:58 PMIs there a safety reason to
stop within the last 2000 blocks or can it be tweaked to stop at remaining 500
blocks for example?Not really. I'll change it to 1000 next time./nRe: JSON-RPC
password

Bitcointalk

2010-07-23 20:39:03 UTC - Original Post

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,
withrpcpassword= Â # fill in a password hereThere 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?/nRe: A few suggestions

Bitcointalk

2009-12-18 17:37:48 UTC - Original Post

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=<directory>" switch. Â I know someone is already doing that to put it on a
TrueCrypt USB drive./nRe: JSON-RPC Multiple Invocations

Bitcointalk

2010-07-24 00:59:08 UTC - Original Post

Obviously it's a bug that it repeats the header.I was trying to follow the 1.0
spec: http://json-rpc.org/wiki/specification  It called for multiple
invocation.I think they mean it's like this, but I'm not sure:Post:{"method":
"postMessage", "params": ["Hello all!"], "id": 99}{"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./nRe: bitcoind not responding to RPC

Bitcointalk

2010-07-24 01:15:58 UTC - Original Post

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)/nRe: Warning: don't use -server or
bitcoind on a machine where you web browse

Bitcointalk

2010-07-24 02:29:09 UTC - Original Post

The JSON-RPC HTTP authentication feature in 0.3.3 solves this problem./nVersion
0.3.2.5 -- please test!

Bitcointalk

2010-07-24 03:32:52 UTC - Original Post

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
minutesDownload here:http://www.bitcoin.org/download/bitcoin-0.3.2.5-
win32.ziphttp://www.bitcoin.org/download/bitcoin-0.3.2.5-linux.tar.gzThanks!/nRe:
Reading/Writing Blocks and FLATDATA

Bitcointalk

2010-07-24 04:04:20 UTC - Original Post

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./nRe: a simple traffic load test run

Bitcointalk

2010-07-25 14:46:33 UTC - Original Post

Was that on the test network?http://bitcointalk.org/index.php?topic=363.0/nRe: a
simple traffic load test run

Bitcointalk

2010-07-25 15:29:52 UTC - Original Post

Please do these tests on the test network. That's what it's for.
 Thanks./nBitcoin 0.3.3 released -- PLEASE UPGRADE

Bitcointalk

2010-07-25 16:55:09 UTC - Original Post

Please upgrade to 0.3.3! Important security improvements were made in 0.3.2 and
0.3.3.New features:- Gavin Andresen's HTTP authentication to secure JSON-RPC- 5x
faster initial block download, under 30 minutes/nRe: Stealing Coins

Bitcointalk

2010-07-25 17:45:22 UTC - Original Post

It's best if you tell it to me privately so it can be fixed first.I just e-mailed
you my e-mail address. (or you could PM me here)/nRe: Stealing Coins

Bitcointalk

2010-07-25 19:06:23 UTC - Original Post

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./nRe: Is my second Transaction
working correctly? +Transfer Question

Bitcointalk

2010-01-05 20:00:46 UTC - Original Post

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 AMQuoteHowever,
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/unconfirmed3/unconfirmed4/unconfirmed5/unconfirmed6 confirmations7
confirmations8 confirmationsEach block essentially means another node has confirmed
that it agrees with all transactions up to that point./nRe: Stealing Coins

Bitcointalk

2010-07-25 20:01:40 UTC - Original Post

Quote from: knightmb on July 25, 2010, 07:44:02 PMIf I figure out that Public Key
123456 generates Hash ABCDandPublic Key 654321 also generates Hash ABCDI'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./nRe: Stealing Coins

Bitcointalk

2010-07-25 20:48:01 UTC - Original Post

QuoteHere 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 2^160/2^20 =
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./nRe: JSON-RPC password

Bitcointalk

2010-07-25 21:34:29 UTC - Original Post

Quote from: lachesis on July 25, 2010, 07:52:35 PMI 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:Code:...Authorization:
Basic
YWJiYWJiYWFiYmE6aGVsbG93b3JsZGhlbGxvd29ybGRoZWxsb3dvcmxkaGVsbG93b3JsZGhlbGxvd29ybGR
oZWxsb3dvcmxkIt 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 '\r's) from result at the end of the Base64Encode
function:Code:result.erase(std::remove(result.begin(), result.end(), '\n'),
result.end());result.erase(std::remove(result.begin(), result.end(), '\r'),
result.end());+1 to you for having such a long password that you found this
bug.Uploaded to SVN as rev 110./nRe: JSON-RPC password

Bitcointalk

2010-07-25 21:44:16 UTC - Original Post

Quote from: BitLex on July 25, 2010, 08:45:38 PMi 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. /nRe: JSON-RPC password

Bitcointalk

2010-07-25 21:51:31 UTC - Original Post

Quote from: gavinandresen on July 25, 2010, 09:38:19 PMGreat catch! Â Simpler fix
is to specify the BIO_FLAGS_BASE64_NO_NL in the rpc.cpp/EncodeBase64 functionSVN
rev 111/nRe: md5?

Bitcointalk

2010-07-25 22:06:57 UTC - Original Post

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.http://www.bitcoin.org/Satoshi_Nakamoto.asc/nRe: Stealing Coins

Bitcointalk

2010-07-25 22:27:36 UTC - Original Post

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./nbitcoind without wxWidgets

Bitcointalk

2010-07-26 17:23:33 UTC - Original Post

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./nRe: Bitcoin x64 for
Windows

Bitcointalk

2010-07-26 18:41:31 UTC - Original Post

Quote from: Olipro on July 26, 2010, 06:39:17 AMCredit 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./nRe: Bitcoin x86 for Windows

Bitcointalk
 2010-07-27 01:29:42 UTC - Original Post
Quote from: Olipro on July 26, 2010, 01:04:41 PMCrypto++ 5.6.0:
http://www.cryptopp.com/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?/nRe: 64bit
support

Bitcointalk

2010-01-14 20:17:20 UTC - Original Post

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./nRe: Proof-of-work
difficulty increasing

Bitcointalk

2010-07-27 03:04:58 UTC - Original Post

New difficulty factor 244.213223092+35%I updated the first post.date, difficulty
factor, % change2009Â Â Â Â Â 1.0030/12/2009Â Â 1.18Â Â +18%11/01/2010Â Â
1.31Â Â +11%25/01/2010Â Â 1.34Â Â +2%04/02/2010Â Â 1.82Â Â +36%14/02/2010Â
 2.53  +39%24/02/2010  3.78  +49%08/03/2010  4.53Â
 +20%21/03/2010  4.57  +9%01/04/2010  6.09  +33%12/04/2010 Â
7.82Â Â +28%21/04/2010Â Â 11.46Â Â +47%04/05/2010Â Â 12.85Â Â +12%19/05/2010Â
 11.85  -8%29/05/2010  16.62  +40%11/06/2010  17.38 Â
+5%24/06/2010Â Â 19.41Â Â +12%06/07/2010Â Â 23.50Â Â +21%13/07/2010Â Â 45.38Â
 +93%16/07/2010 181.54 +300%27/07/2010 244.21  +35%/nRe: Bitcoin x86 for
Windows

Bitcointalk

2010-07-27 18:27:30 UTC - Original Post

Quote from: BlackEye on July 25, 2010, 10:12:23 PMI 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.This is SVN rev 114./nRe: Bitcoin x86
for Windows

Bitcointalk
 2010-07-27 19:47:42 UTC - Original Post
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./nRe: Having problems specifing -datadir

Bitcointalk

2010-07-28 20:58:26 UTC - Original Post

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./nRe: Build
error SVN r115 on my Mac: workaround

Bitcointalk

2010-07-28 21:23:23 UTC - Original Post

Was that the only thing I broke in the OSX build?! Â Does it actually work after
just that one change?I had to do that for makefile.vc also. Â It compiled, but SHA-
256 didn't work correctly; it returned the same incorrect hash each time.We'll
disable it now, and if anyone figures out how to fix it, we can re-enable it then.
 It's still 1.7x faster from the midstate optimisation.The Crypto++ ASM SHA-256
works with GCC on Linux and Windows (MinGW).I uploaded this makefile.osx change to
SVN. Â (let me know if that compiles now)/nRe: Difficulty

Bitcointalk

2010-07-29 01:16:23 UTC - Original Post

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./nRe: Scalability and transaction rate

Bitcointalk

2010-07-29 02:00:38 UTC - Original Post

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 PMBesides, 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.http://bitcointalk.org/index.php?topic=423.msg3819#msg3819/nRe: wiki
registration email?
 Bitcointalk

2010-07-29 02:10:46 UTC - Original Post

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. /n*** ALERT ***
Upgrade to 0.3.6

Bitcointalk

2010-07-29 19:13:06 UTC - Original Post

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.Also in 0.3.6, faster hashing:- midstate cache optimisation thanks to tcatm-
Crypto++ ASM SHA-256 thanks to BlackEyeTotal generating speedup 2.4x
faster.Download:http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-
0.3.6/Windows and Linux users: if you got 0.3.5 you still need to upgrade to
0.3.6./nRe: *** ALERT *** version 0.3.6

Bitcointalk

2010-07-29 19:55:51 UTC - Original Post

Haven't had time to update the SVN yet. Â Wait for 0.3.6, I'm building it now.
 You can shut down your node in the meantime.  /nRe: Number of connections?

Bitcointalk

2010-01-20 20:07:15 UTC - Original Post

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./nRe: *** ALERT *** version 0.3.6

Bitcointalk

2010-07-29 20:30:15 UTC - Original Post

SVN is updated with version 0.3.6.Uploading Windows build of 0.3.6 to Sourceforge
now, then will rebuild linux./nRe: *** ALERT *** Upgrade to 0.3.6 ASAP!

Bitcointalk

2010-07-29 21:20:38 UTC - Original Post

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./nRe: *** ALERT ***
Upgrade to 0.3.6 ASAP!

Bitcointalk

2010-07-29 21:43:15 UTC - Original Post

"./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./nRe: Implementation bug prior to 0.3.6

Bitcointalk

2010-07-29 22:04:15 UTC - Original Post

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./nRe: Transaction disappeared in the
void...

Bitcointalk

2010-07-29 22:08:31 UTC - Original Post

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./nRe: Linux
distribution download

Bitcointalk

2010-07-29 22:17:24 UTC - Original Post

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./nRe: *** ALERT *** Upgrade to 0.3.6
ASAP!

Bitcointalk

2010-07-29 23:12:12 UTC - Original Post

Quote from: lachesis on July 29, 2010, 10:14:36 PMOn Debian testing 32-bit, I get
a few build errors, all resembling:Code:script.cpp:114: error: ‘OP_NOP1’ was
not declared in this scopeI 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./nRe: Bug: "Immature"
coins lost in wallet.dat during transaction

Bitcointalk

2010-07-30 19:19:05 UTC - Original Post

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?/nRe: [PATCH] implement 'listtransactions'

Bitcointalk

2010-07-30 19:40:54 UTC - Original Post

 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./nRe: *** ALERT *** Upgrade to 0.3.6 ASAP!

Bitcointalk

2010-07-30 19:53:06 UTC - Original Post

Quote from: knightmb on July 30, 2010, 07:24:07 PMI 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:Dependencies------------sudo apt-get
install build-essentialsudo apt-get install libgtk2.0-devsudo apt-get install
libssl-devsudo apt-get install libdb4.7-devsudo apt-get install libdb4.7++-devsudo
apt-get install libboost-all-dev (or libboost1.37-dev)wxWidgets---------cd
/usr/localtar -xzvf wxWidgets-2.9.0.tar.gzcd /usr/local/wxWidgets-2.9.0mkdir
buildgtkcd buildgtk../configure --with-gtk --enable-debug --disable-shared --
enable-monolithicmakesudo sumake installldconfigadded a comment in makefile.unix:#
for boost 1.37, add -mt to the boost librariesLIBS= \Â -Wl,-Bstatic \Â Â -l
boost_system \Â Â -l boost_filesystem \Â Â -l boost_program_options \Â Â -l
boost_thread \Â Â -l db_cxx \Â Â -l crypto \Â -Wl,-Bdynamic \Â Â -l gthread-
2.0/nBitcoin open source implementation of P2P currency

P2P Foundation

2009-02-18 20:50:00 UTC - Original Post

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 yearsYou 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./nRe:
TOR and I2P
 Bitcointalk

2010-01-20 22:05:28 UTC - Original Post

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./nRe: *** ALERT *** Upgrade to 0.3.6 ASAP!

Bitcointalk

2010-07-30 21:44:04 UTC - Original Post

Quote from: knightmb on July 30, 2010, 08:04:19 PMSo that last command should
simply besudo apt-get install libboost1.37-devExcept that wouldn't work for boost
1.40+ (on Ubuntu 10.04), where you need to get libboost-all-dev.Seems they changed
everything around in Boost recently, "-mt" and all that, makes it hard.BTW, I tried
Boost 1.34 but it didn't have the boost.interprocess stuff.Mac OSX version is
available now. Â See bitcoin.org or the SourceForge link./nRe: 4 hashes parallel on
SSE2 CPUs for 0.3.6

Bitcointalk

2010-07-31 00:29:20 UTC - Original Post

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./nWebpage
idea: Next predicted difficulty change

Bitcointalk

2010-07-31 01:32:08 UTC - Original Post

It would be neat if someone had a page (like that handy calculator at
http://www.alloscomp.com/bitcoin/calculator.php) that projects what the next
difficulty adjustment will be.projected difficulty adjustment multiplier =
 blocks_since_last_adjustment / 2016 ------------------------------------
 time_since_last_adjustment / 14_daysFor instance, if it already got half way to
the next adjustment in only 3.5 days instead of 7, we would expect difficulty to
double:Â (1008/2016) / (3.5/14) = 0.5/0.25 = 2.0Also, it could show the predicted
time when the next adjustment will occur, and tell when the last adjustment was and
how much it changed./nRe: Linux distribution download

Bitcointalk

2010-07-31 14:38:52 UTC - Original Post

It can be built with Boost 1.37 or later./nRe: Linux version => No GUI after
upgrade. WTF?

Bitcointalk

2010-08-02 17:39:27 UTC - Original Post

Did it print anything to the console? Are you sure you didn't run "bitcoind"?
Try version 0.3.7./nRe: Mac Client Problems Outlined...

Bitcointalk

2010-08-02 18:02:20 UTC - Original Post

"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./nRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Bitcointalk

2010-08-02 19:02:46 UTC - Original Post

Is it 2x fast on AMD and 1/2 fast on Intel?Quote from: tcatm on July 31, 2010,
10:12:38 AMBtw. Why are you using this alignup<16> function when __attribute__
((aligned (16))) will tell the compiler to align at compiletime?Tried that, but it
doesn't work for things on the stack. I ran some tests.It doesn't even cause an
error, it just doesn't align it./nRe: Protocol Buffers for Bitcoin

Bitcointalk

2010-08-02 20:22:08 UTC - Original Post

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./nRe: Builds for Ubuntu?

Bitcointalk

2010-08-03 20:56:11 UTC - Original Post

Quote from: nimnul on August 03, 2010, 05:51:15 PMIs satoshi noWx patch in 0.3.7
already? Before that bitcoind required wx, and I never seen Satoshi announcing that
it's in trunkYes, 0.3.7 has it. It was in rev 112./nRe: Bitcoind x86 binary for
CentOS

Bitcointalk

2010-08-03 21:05:08 UTC - Original Post

Quote from: sgtstein on August 03, 2010, 05:30:37 PMI have successfully built it
with 4.8, 4.7 never would but with 4.8 bitcoind locks up whenever it dumps the
initial block download to disk. I urge you not to use BDB 4.8. The
database/log0000* files will be incompatible if anyone uses your build and then
goes back to the official build./nRe: Bitcoin crash when sending coins

Bitcointalk

2010-01-27 21:52:27 UTC - Original Post

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./nRe: Content-
Length header and 500 (was Re: Authentication, JSON RPC and Python)

Bitcointalk

2010-08-03 21:26:26 UTC - Original Post

Quote from: gavinandresen on August 03, 2010, 06:56:44 PMQuote from: jgarzik on
August 03, 2010, 06:09:08 PMbitcoin 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./nRe: What happens when network is split for prolonged time and
reconnected?

Bitcointalk

2010-08-03 22:45:07 UTC - Original Post

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 PMQuote from:
gavinandresen on August 03, 2010, 06:38:44 PMOr 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 PMIf 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./nPlease upgrade to 0.3.8!

Bitcointalk

2010-08-03 23:40:18 UTC - Original Post

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.Download:http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-
0.3.8//nRe: Bitcoind x86 binary for CentOS

Bitcointalk

2010-08-04 00:09:32 UTC - Original Post

Quote from: knightmb on August 03, 2010, 11:46:46 PMThere 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./nRe: Please upgrade to
0.3.8!

Bitcointalk

2010-08-04 00:29:37 UTC - Original Post

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.Edit: SourceForge is updated now./nRe:
Building initial transaction trust through "coin ripping"

Bitcointalk

2010-08-04 00:40:40 UTC - Original Post

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./nRe: Flood attack 0.00000001 BC

Bitcointalk

2010-08-04 16:25:36 UTC - Original Post

Quote from: Insti on August 04, 2010, 02:58:31 PMIt 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. /nRe: Flood attack 0.00000001 BC

Bitcointalk

2010-08-05 16:03:21 UTC - Original Post

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 PMDoes including
more slow down your hashing rate? Â No, not at all./nRe: Flood attack 0.00000001 BC

Bitcointalk

2010-08-05 16:30:20 UTC - Original Post

Quote from: bytemasterPayments 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./nRe: Flood attack 0.00000001 BC

Bitcointalk

2010-08-05 16:39:58 UTC - Original Post

Quote from: bytemaster on August 05, 2010, 03:39:19 PMThe 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?/nRe: A newb's
test - anyone want to buy a picture for $1?

Bitcointalk

2010-01-28 01:01:48 UTC - Original Post

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./nRe: Who's the Spanish jerk draining the
Faucet?

Bitcointalk

2010-08-05 17:06:03 UTC - Original Post

Silently failing would look bad.Quote from: gavinandresen on August 04, 2010,
08:40:55 PM1. Rate limit based on the first byte of the IP address (79. or 81. in
this case).Definitely needed. Â What rate are you thinking of? Â Ultimately, it's
better to rate limit it than to let it all drain out.Quote from: gavinandresen on
August 04, 2010, 08:40:55 PM3. Rate limit based on last two domains of reverse DNS
lookup of the IP address (rima-tde.net in this case).That might work surprisingly
well. Â If it works, it keeps them from hitting the rate limit, but the rate limit
is there as the last line of defence. Quote from: gavinandresen on August 04, 2010,
08:40:55 PM4. Make the standard amount given away 0.5 Bitcoins (Bitcoins have gone
up 10 times in value since I started the Faucet).Definitely time to lower it. /nRe:
bitcoind transaction to ip address

Bitcointalk

2010-08-05 17:28:40 UTC - Original Post

It's not implemented.It turned out nobody liked that mode of transfer anyway, so
it hasn't had much development attention./nRe: Transaction Overload Solution

Bitcointalk

2010-08-05 17:38:21 UTC - Original Post

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?/nRe: Flood attack 0.00000001 BC

Bitcointalk

2010-08-05 17:49:43 UTC - Original Post

Quote from: bytemaster on August 05, 2010, 04:46:52 PMRight 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./nRe: A proposal for a semi-automated Escrow mechanism

Bitcointalk

2010-08-05 18:08:30 UTC - Original Post

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./nRe: latency and locality

Bitcointalk

2010-08-07 16:28:17 UTC - Original Post

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?/nRe: Bitcoin minting is thermodynamically perverse

Bitcointalk

2010-08-07 17:46:09 UTC - Original Post

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 PMAs 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./nRe: A proposal for a semi-automated Escrow mechanism

Bitcointalk

2010-08-07 20:04:59 UTC - Original Post

Quote from: jgarzik on August 05, 2010, 07:00:30 PMDue 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.)/nEscrow

Bitcointalk

2010-08-07 20:13:52 UTC - Original Post

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./nRe: 4 hashes parallel on SSE2 CPUs for 0.3.6

Bitcointalk

2010-08-07 21:16:01 UTC - Original Post

Quote from: impossible7 on August 06, 2010, 11:37:20 AMCRITICAL_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./nRe: Blocks never stop generating?

Bitcointalk

2010-01-28 01:08:33 UTC - Original Post

Where it says "# blocks" in the status column I'm changing it to say "#
confirmations". That might be clearer.If you doubleclick on the transaction you
get a little more information./nRe: bitcoin generation broken in 0.3.8?

Bitcointalk

2010-08-09 18:50:41 UTC - Original Post

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./nVersion 0.3.8.1 update for
Linux 64-bit

Bitcointalk

2010-08-09 19:46:58 UTC - Original Post

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.Download:http://sourceforge.net/projects/bitcoin/files/Bitcoin/
bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/downloadFuture versions after 0.3.8 will
probably require SSE2. Anyone have Pentium 3 or older where this would be a
problem?/nRe: What could be the transition plan to Y2038 compliant Bitcoin?

Bitcointalk
 2010-08-09 20:13:26 UTC - Original Post
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./nRe: bitcoin generation broken in 0.3.8? (64-bit)

Bitcointalk

2010-08-09 20:34:06 UTC - Original Post

I uploaded 0.3.8.1 for Linux with re-built 64-bit. I ran a difficulty 1 test
with it and it has generated blocks.http://bitcointalk.org/index.php?
topic=765.0Download:http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-
0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download/nRe: Version 0.3.8.1 update for Linux
64-bit

Bitcointalk

2010-08-09 20:55:06 UTC - Original Post

That's a good point, I believe you could run with generation off if you don't
have SSE2.How about add to the top of cryptopp/config.h:#if !defined(_M_X64) && !
defined(__x86_64__)#define CRYPTOPP_DISABLE_SSE2 Â 1#endifthat would disable SSE2
for 32-bit builds. Â (at least with GCC or MSVC)/nConnection limits

Bitcointalk

2010-08-09 20:58:45 UTC - Original Post

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?/nRe: Bitcoin minting is thermodynamically perverse

Bitcointalk

2010-08-09 21:28:39 UTC - Original Post

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./nRe: Version 0.3.8.1 update for
Linux 64-bit

Bitcointalk

2010-08-10 23:46:00 UTC - Original Post

SVN rev 128: disable SSE2 on 32-bit. This may only disable it for MSVC and GCC.
 Other compilers might have different 64-bit defines./nRe: Not a suggestion

Bitcointalk

2010-08-11 00:14:22 UTC - Original Post

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./nRe: Escrow

Bitcointalk

2010-08-11 01:30:02 UTC - Original Post

Quote from: jgarzik on August 10, 2010, 06:53:57 PMAsk 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 PMBut
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./nRe:
Bitcoin crash when sending coins

Bitcointalk

2010-01-28 23:08:02 UTC - Original Post

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./nRe: Compile error in SVN r127

Bitcointalk

2010-08-11 01:42:30 UTC - Original Post

Updated SVN. Thanks.There's little hope of not repeatedly stumbling over that
in the future. Â It doesn't break the compile for me./nRe: Not a suggestion

Bitcointalk
 2010-08-11 21:07:59 UTC - Original Post
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 transactionThe 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./nRe: Lost large number of bitcoins

Bitcointalk

2010-08-11 21:46:51 UTC - Original Post

Quote from: sirius-m on August 11, 2010, 02:01:53 AMI 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 PMWait, 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./nRe: Where is the separate discussion devoted to possible Bitcoin
weaknesses.

Bitcointalk