Kicking the Hornet's Nest - part 12
Kicking the Hornet’s Nest - third edition - part 12
All links, digital (pdf, txt, docx, md) and book in print, can be found at https://hive.blog/@crrdlx/satoshi
Edited by crrdlx, npub:
npub1qpdufhjpel94srm3ett2azgf49m9dp3n5nm2j0rt0l2mlmc3ux3qza082j
Kicking the Hornet’s Nest pages 250 - 275
Martii Malmi (AKA Sirius) “COPA trial” email #180
Date: Wed, 03 Mar 2010 03:54:52 +0000
From: Satoshi Nakamoto satoshin@gmx.com
Subject: Re: Bitcoind
To: mmalmi@cc.hut.fi
That narrows it down a lot. It didn’t print any IRC activity in
debug.log, so I guess it couldn’t have gotten past the RecvUntil.
Eyeballing it I don’t see anything obvious. I guess it would have to be
either in ConnectSocket or RecvUntil.
Try it with the attached irc.cpp and net.cpp and send me the debug.log.
Or you could run it in gdb and step through ThreadIRCSeed
gdb –args bitcoin [switches]
b ThreadIRCSeed
run
step
or u to step over and up out of routines.
_mmalmi@cc.hut.fi wrote:_
> I get the error regardless of the getinfo. Commenting out ThreadIRCSeed
> fixed the problem.
>
BitcoinTalk
Re: Money Transfer Regulations
2010-03-03 04:28:56 UTC - -
When there’s enough scale, maybe there can be an exchange site that doesn’t do transfers, just matches up buyers and sellers to exchange with each other directly, similar to how e-bay works.
To make it safer, the exchange site could act as an escrow for the bitcoin side of the payment. The seller puts the bitcoin payment in escrow, and the buyer sends the conventional payment directly to the seller. The exchange service doesn’t handle any real world money.
This would be a step better than e-bay. E-bay manages to work fine even though shipped goods can’t be recovered if payment falls through.
Martii Malmi (AKA Sirius) “COPA trial” email #182
Date: Wed, 03 Mar 2010 17:15:28 +0000
From: Satoshi Nakamoto satoshin@gmx.com
Subject: Re: Bitcoind
To: mmalmi@cc.hut.fi
It’s in RecvUntil, but I still can’t see anything wrong with it. The
only thing I can think of is if the socket is receiving a spew of
characters.
Try this irc.cpp. debug.log may grow rapidly so be ready to kill it.
_mmalmi@cc.hut.fi wrote:_
> debug.log attached
>
Martii Malmi (AKA Sirius) “COPA trial” email #185
Date: Fri, 05 Mar 2010 00:42:16 +0000
From: Satoshi Nakamoto satoshin@gmx.com
Subject: Re: Bitcoind
To: mmalmi@cc.hut.fi
It’s in util.c ParseString. I’m guessing the problem is incompatibility
between the type “unsigned int” and the type of str.npos, which is
size_type.
Try changing the two “unsigned int”s to “size_type”.
old:
void ParseString(const string& str, char c, vector
{
unsigned int i1 = 0;
unsigned int i2;
do
{
i2 = str.find(c, i1);
v.push_back(str.substr(i1, i2-i1));
i1 = i2+1;
}
while (i2 != str.npos);
}
new:
void ParseString(const string& str, char c, vector
{
size_type i1 = 0;
size_type i2;
do
{
i2 = str.find(c, i1);
v.push_back(str.substr(i1, i2-i1));
i1 = i2+1;
}
while (i2 != str.npos);
}
_mmalmi@cc.hut.fi wrote:_
> Here’s another test run debug.log I got when debugging with gdb. The
> program started eating memory after the debug line “irc 8” and within a
> few seconds crashed with “terminate called after throwing an instance of
> ‘std::bad_alloc’“.
>
Martii Malmi (AKA Sirius) “COPA trial” email #186
Date: Fri, 05 Mar 2010 00:54:40 +0000
From: Satoshi Nakamoto satoshin@gmx.com
Subject: Re: Bitcoind
To: mmalmi@cc.hut.fi
Actually, please try this instead, this is more correct:
void ParseString(const string& str, char c, vector
{
string::size_type i1 = 0;
string::size_type i2;
loop
{
i2 = str.find(c, i1);
if (i2 == str.npos)
{
v.push_back(str.substr(i1));
return;
}
v.push_back(str.substr(i1, i2-i1));
i1 = i2+1;
}
}
Martii Malmi (AKA Sirius) “COPA trial” email #188
Date: Fri, 05 Mar 2010 01:42:00 +0000
From: Satoshi Nakamoto satoshin@gmx.com
Subject: Re: Bitcoind
To: mmalmi@cc.hut.fi
I confirmed that ParseString has this problem, and uploaded the fixed
util.cpp to SVN.
string::npos == -1
Comparing unsigned int -1 (0xffffffff) with long unsigned int -1
(0xffffffffffffffff) results in the unsigned int being promoted to
64-bit, which is 0x00000000ffffffff != 0xffffffffffffffff.
_mmalmi@cc.hut.fi wrote:_
> Here’s another test run debug.log I got when debugging with gdb. The
> program started eating memory after the debug line “irc 8” and within a
> few seconds crashed with “terminate called after throwing an instance of
> ‘std::bad_alloc’“.
>
BitcoinTalk
Re: Command Line and JSON-RPC
2010-03-05 01:46:25 UTC - -
Quote from: sirius-m on February 24, 2010, 06:17:35 PM
This is strange… When I start Bitcoin as a daemon on my 64 bit Linux server, it eats up all the 250MB of remaining RAM, 700MB of swap and eventually crashes. On my 32 bit Ubuntu desktop, it works fine and stays at 15MB of memory usage. The server is running a 64 bit build of Bitcoin. Maybe there’s something wrong with the build or something.
sirius-m debugged this, it was 64-bit related.
The fix is now available on SVN, file util.cpp.
Martii Malmi (AKA Sirius) “COPA trial” email #189
Date: Sat, 06 Mar 2010 06:39:53 +0000
From: Satoshi Nakamoto satoshin@gmx.com
Subject: Blog
To: Martti Malmi mmalmi@cc.hut.fi
There’s a blog writer who wants to write a story about Bitcoin, but I
don’t have time right now to answer his questions. Would you be
interested in answering his questions if I refer him to you? We might
get a good link out of it.
The blog is
http://themonetaryfuture.blogspot.com
BitcoinTalk
Re: bitcoin auto-renice-ing
2010-03-15 18:44:12 UTC - -
It sets different priorities for each thread. The generate threads run at PRIO_MIN. The other threads rarely take any CPU and run at normal.
#define THREAD_PRIORITY_LOWEST PRIO_MIN
#define THREAD_PRIORITY_BELOW_NORMAL 2
#define THREAD_PRIORITY_NORMAL 0
The priorities converted from Windows priorities were probably from a table like this:
“The following table shows the mapping between nice values and Win32 priorities. Refer to the Win32 documentation for SetThreadPriority() for more information on Win32 priority issues.
nice value Win32 Priority
-20 to -16 THREAD_PRIORITY_HIGHEST
-15 to -6 THREAD_PRIORITY_ABOVE_NORMAL
-5 to +4 THREAD_PRIORITY_NORMAL
+5 to +14 THREAD_PRIORITY_BELOW_NORMAL
+15 to +19 THREAD_PRIORITY_LOWEST“
If you have better values, suggestions welcome.
Also, there was some advice on the web that PRIO_PROCESS is used on Linux because threads are processes. If that’s not true, maybe it accounts for unexpectedly setting the priority of the whole app.
// threads are processes on linux, so PRIO_PROCESS affects just the one thread
setpriority(PRIO_PROCESS, getpid(), nPriority);
BitcoinTalk
Idea for file hosting and proxy services
2010-03-15 19:16:56 UTC - -
When you want to upload an image to embed in a forum post, there are services like imageshack, but because they’re free, they limit the number of views. It’s a minuscule amount of bandwidth cost, but they can’t just give it away for free, there has to be something in it for them. It would be nice to be able to pay for the bandwidth and avoid the limits, but conventional payments are too inconvenient for such a minor thing.
It’s worse if you want to upload a file for others to download. There are services like rapidshare, but they require the downloaders to go through extra steps and delays to make them look at advertising or encourage upgrading to a paid subscription, and they limit it to 10 or so downloads.
It would be nice if we made some free PHP code for an image and file hosting service that charges Bitcoins. Anyone with some extra bandwidth quota could throw it on their webserver and run it. Users could finally pay the minor fee to cover bandwidth cost and avoid the limits and hassles. Ideally, it should be MIT license or public domain.
Services like this would be great for anonymous users, who have trouble paying for things.
BitcoinTalk
Re: On IRC bootstrapping
2010-03-16 19:48:47 UTC - -
Thanks soultcer for talking with the Freenode staffer. Good to know it’s OK at the current size, and now they know who we are. They’re supportive of projects like TOR so I hope they would probably be friendly to us. We don’t want to overstay our welcome. If we get too big, then by the same token, we’re big enough that we don’t need IRC anymore and we’ll get off.
We only needed IRC because nobody had a static IP. In the early days there were some steady supporters, but they all had pool-allocated IPs that change every few days. IRC was only intended as a temporary solution. Bitcoin’s built-in addr system is the main solution.
Bitcoin can get the list of IPs from any bitcoin node. In that sense, every node serves as a directory server.
When there are enough static IP nodes to have a good chance that at least one will still be running by the time the current version goes out of use, we can preprogram a seed list.
How do you think we should compile the seed list? Would it be OK to create it from the currently connected IPs that have been static for a while?
BTW, if we want to supplement by deploying separate directory server software, may I suggest IRC? IRC is a good directory server (I’ve heard it has other uses too), and there are mature IRC server implementations available that anyone can run. 
Bitcoin’s IRC client implementation is already thoroughly tested.
BitcoinTalk
Re: Idea for file hosting service
2010-03-16 20:17:34 UTC - -
That’s a great idea. There’s a thriving business in those services, but I’ve always thought the standard payment methods are at odds with privacy minded customers.
Would you consider making your software freely available so anyone could easily set one up? I know for competitive reasons the inclination is to keep it to yourself, but it could get an order of magnitude more use if anyone could give proxy access to their country just by putting the software on a server.
I wonder if there are other kinds of web application servers where we would only have to tack on the payment mechanism to an already existing system?
BitcoinTalk
Re: who is bitcoin.com
2010-03-23 15:22:41 UTC - -
It’s unrelated. There wasn’t anything there when I started.
The price of .com registrations is lower than it should be, therefore any good name you might think of is always already taken by some domain name speculator. Fortunately, it’s standard for open source projects to be .org.
BitcoinTalk
Re: Exchange Methods
2010-03-23 17:35:34 UTC - -
LR and Pecunix have many established exchanges to paper currencies by various payment methods, and a number of vendors accept them as payment, so an exchange link between Bitcoin and LR/Pecunix would give us 2nd-hop access to all that. The possibility to cash out through them would help support the value of bitcoins.
Bitcoin has unique properties that would be complementary. LR/Pecunix are easy to spend anonymously, but hard to buy anonymously and not worth the trouble to buy in small amounts. Bitcoin, on the other hand, is easy to get in small amounts anonymously. It would be convenient to buy LR/Pecunix with bitcoins rather than through conventional payment methods.
Most customers who convert to LR to buy something would probably ask the seller first if they accept Bitcoin, encouraging them to start accepting it.
BitcoinTalk
Re: Idea for file hosting and proxy services
2010-03-24 18:01:57 UTC - -
Title changed.
It helps that we have someone with actual experience running a proxy service. Do you think Psiphon is the best one currently? (sometimes the one you run was the best when you started but you found better ones later)
BitcoinTalk
Re: Idea for file hosting and proxy services
2010-03-24 18:02:55 UTC - -
Mihalism Multi Host is a popular open source PHP file hosting server.
It’s geared toward image hosting, but I think by increasing the file size limit and liberalising the allowed file extensions, it could just as easily be used for general file upload hosting. They need the limits to keep it reasonable as a free service, but if we bolt on a Bitcoin payment mechanism, the limits could be relaxed.
It doesn’t have a bunch of client side scripting or anti-embedding junk to rip out. It generates standard links that work normally.
There’s a turnover churn in these free hosting sites. Small sites can give free image hosting, but once one starts getting popular, it gets too swamped with moochers using them for free bandwidth. Any site that gets well known has to become more aggressively pay-naggy to cover bandwidth costs. It’s a perfect example of a service where the needed price point is in the no-man’s-land between just a little too expensive to be free, but too cheap for most users to take the trouble of a conventional payment. It’s in the gap between 0 and 19.95. The best they can do is try to maybe get 1 out of 1000 users to pay 9.95, but that has 999/1000 users treated like freeloaders. It can’t really be advertising supported because the images are embedded in other sites and downloaded without going to the hosting site.
An example of a site running the software:
http://www.imagez.ws/
Forum:
http://www.mihalism.net/
Download:
http://code.google.com/p/mihalismmh/
What do you think? If I made a Bitcoin payment integration for this, would anyone be interested in running it? It might be the first fully automated service available to buy with Bitcoins. The advantage it could offer over the free services is general file upload hosting of large files without making downloading users go to the upload site and jump through hoops. It would give a normal link directly to the file.
Martii Malmi (AKA Sirius) “COPA trial” email #192
Date: Sun, 16 May 2010 20:12:21 +0100
From: Satoshi Nakamoto satoshin@gmx.com
Subject: Re: Status update
To: mmalmi@cc.hut.fi
I’ve also been busy with other things for the last month and a half. I
just now downloaded my e-mail since the beginning of April. I mostly
have things sorted and should be back to Bitcoin shortly. Glad that
you’ve been handling things in my absence. Congrats on your first
transaction!
As I recall, the code was nearly ready for a 0.3 release. I think all
it needed was a little testing time and to install the new icon xpm.
The JSON API functions are complete. I wanted to take another fresh
look at them in case I think of any better function names before
committing. I ought to write some sample code showing the proper way to
use them, particularly with polling for received transactions. When I
left off, I was thinking about bolting a payment mechanism onto a free
upload server software as an example. It would make sense to actually
build one practical application with the API before releasing it. You
don’t realise the problems with an API until you actually try to use it.
_mmalmi@cc.hut.fi wrote:_
> Hi!
>
> How are you doing? Haven’t seen you around in a while.
>
> I’ve been at full-time work lately, and will be until the end of June,
> so I haven’t had that much time to work with Bitcoin or my exchange
> service. I have a working beta of my service though, and a few weeks ago
> made my first transaction: sold 10,000 btc for 20 euros via EU bank
> transfer. Maybe I can make it public soon.
>
> I divided the forum into 6 boards, which are Bitcoin Discussion,
> Development & Technical Discussion, Technical support, Economics,
> Marketplace and Trading Discussion. Hope this is ok?
>
> I also added a page “Trade” on the bitcoin.org site, where btc-accepting
> services are listed. It’s nice to see that there are already useful
> services that accept btc.
>
> The community has been growing nicely. We’ve had around 10-20 people and
> active discussion at #bitcoin-dev lately.
>
> It would be nice to get the daemon-able binaries to SF.net. We have some
> skilled programmers in the community now, so maybe we can finish the
> JSON API functions if you don’t have time to.
>
> Best regards.
>
BitcoinTalk
Re: Could the bitcoin network be destroyed by someone generating endless bitcoin add
2010-05-16 21:01:44 UTC - -
When you generate a new bitcoin address, it only takes disk space on your own computer (like 500 bytes). It’s like generating a new PGP private key, but less CPU intensive because it’s ECC. The address space is effectively unlimited. It doesn’t hurt anyone, so generate all you want.
BitcoinTalk
Re: For a website taking payments with bitcoins, better: IP or bitcoin addresses?
2010-05-16 21:37:36 UTC - -
Quote from: Xunie on May 14, 2010, 09:52:53 PM
I suggest we disable IP transactions while the user uses a Proxy!
Just to be on the safe side.
That’s a good idea. At the very least a warning dialog explaining that it’ll connect to the IP and send the information cleartext, giving the chance to cancel.
BitcoinTalk
Re: Exception: 9key_error error
2010-05-16 22:53:59 UTC - -
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.
BitcoinTalk
Re: removing bitcoin addresses
2010-05-16 23:34:40 UTC - -
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.
BitcoinTalk
Re: Setting up multiple bitcoin machines behind NAT
2010-05-16 23:56:03 UTC - -
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.
BitcoinTalk
Re: Is there a way to automate bitcoin payments for a website?
2010-05-18 02:58:11 UTC - -
A little late, but in case anyone else has the same issue. The compile dump had 2 warnings (that were 20 lines long) and 2 link errors. The errors were:
Quote
_obj/nogui/init.o(.gnu.linkonce.t._ZNK13wxArrayString4ItemEm+0x13): In function wxArrayString::Item(unsigned long) const': /usr/local/include/wx-2.9/wx/buffer.h:42: undefined reference to wxTheAssertHandler’
obj/nogui/init.o(.gnu.linkonce.t.ZNK13wxArrayString4ItemEm+0x45): In function wxArrayString::Item(unsigned long) const': /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.
BitcoinTalk
Re: Ummmm… where did my bitcoins go?
2010-05-18 20:06:46 UTC - -
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.
BitcoinTalk
Re: We accept Bitcoins
2010-05-20 21:43:42 UTC - -
Quote from: DataWraith on May 19, 2010, 07:52:42 PM
Can I just butt in with a question on why that is? To me it seems that if Bitcoin uses public-key cryptography to transfer ownership of the coins, it should be a trivial matter to include a short message that is only readable by the recipient.
Almost but not quite. Bitcoin uses EC-DSA, which can only do digital signing, not encryption. RSA can do both, but I didn’t use it because it’s an order of magnitude bigger and would have been impractical.
BitcoinTalk
JSON-RPC programming tips using labels
2010-05-26 18:27:25 UTC - -
I added label related functions to help with managing multiple addresses per user. New or renamed functions are:
getreceivedbyaddress – amount received on a single address
getreceivedbylabel – amount received by all addresses with this label
listreceivedbyaddress – list addresses and amounts they’ve received
listreceivedbylabel – list labels and amounts they’ve received
setlabel – misc label functions for completeness
getlabel
getaddressesbylabel
For consistency I renamed getamountreceived->getreceivedbyaddress and getallreceived->listreceivedbyaddress. The old names are still there so as not to break existing code, but they’re deprecated.
The idea is that if you give the username whenever you call getnewaddress, you can get the user’s total received across all their addresses using the “bylabel” functions. You can freely change their address without worrying about tracking all their old addresses.
A good way to automate changing the user’s receiving address: just before displaying their current address, check if it has been used to receive anything, if it has then replace it with a new one:
// Get a new address whenever the current one has received anything
if (strAddr == “” || getreceivedbyaddress(strAddr) > 0)
strAddr = getnewaddress(strUsername); // Label the address with username
Display(strAddr); // Display their current receiving address
// Get total received by all the user’s addresses
getreceivedbylabel(strUsername, 0) // unconfirmed
getreceivedbylabel(strUsername, 1) // available balance
If you’re just getting one particular user’s balance, such as in response to a page request by that user, use getreceivedbylabel, but if you’re scanning over all users, it’s better to use listreceivedbylabel to get the complete list and scan against the result. Scanning users with getreceivedbylabel would be n-squared, using listreceivedbylabel is n-log-n (or n linear).
You should only really need to scan all users if you’re polling in order to spontaneously take action in response to money received, rather than the user going to a webpage, seeing their balance and telling you what to do with it. It’s not necessary to poll very frequently. If you require 1 confirmation, that’ll take an average of 10 minutes anyway, so there’s no point in polling more often than every few minutes.
If you’re selling digital goods and services, where you don’t lose much if someone gets a free access, and it can’t be resold for profit, I think you’re fine to accept 0 confirmations.
It’s mostly only if you were selling gold or currency that you’d need multiple confirmations.
BitcoinTalk
Re: Tracing a coin’s lineage
2010-05-26 18:51:04 UTC - -
Quote from: Xunie on May 26, 2010, 12:50:04 AM
Can’t we force a user to use a new address for receiving payments?
Every time a payment is received display another Bitcoin address in the address bar. (only transactions via Bitcoin addresses, NOT IPs of course, since that’d be useless, right?)
The actual key would still be kept to ensure that the user would still receive payments of people sending to the same address.
This is on my list. I will soon make the “Your Bitcoin Address:” window automatically change whenever you receive anything to the address displayed.
I’m also recommending this approach for the implementation of web apps. I just posted some sample code showing a suggested way of implementing this.
Versions on SVN since 0.2.4 already have a “New…” button next to the address bar to encourage changing it manually too.
@theymos: If nothing else, we can fall back on that solution in the future.
BitcoinTalk
Re: CLI bitcoin generation
2010-05-26 20:09:34 UTC - -
Quote from: molybdenum on May 22, 2010, 06:44:20 PM
An optional parameter to specify the minimum number of blocks after that transaction (getallreceived 1 for current behavior, or just getallreceived, getallreceived 5 for the paranoid, getallreceived 0 for instant confirms)?
Yeah, that actually is what it is. getallreceived 0 should do what you want. (now it’s renamed to listreceivedbyaddress 0) The default is 1 confirmation, but I think in reality most digital goods and services can be 0 confirmations. Like you say, if you need more than 0 confirmations, you could show two numbers, unconfirmed and available balance, so they immediately see their transaction went through.
listreceivedbyaddress [minconf=1] [includeempty=false]
[minconf] is the minimum number of confirmations before payments are included.
[includeempty] whether to include addresses that haven’t received any payments.
Returns an array of objects containing:
“address” : receiving address
“label” : the label of the receiving address
“amount” : total amount received by the address
“confirmations” : number of confirmations of the most recent transaction included
or listreceivedbylabel if you’re labelling addresses with their username.
So far I’ve concentrated on functions for web merchants, not so much on stuff for remote management of headless coin generators yet.
BitcoinTalk
Re: Share database blocks ?
2010-05-26 20:34:34 UTC - -
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?
BitcoinTalk
Re: Website translations
2010-05-26 21:16:34 UTC - -
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
BitcoinTalk
Re: Odd amount of generated coins
2010-05-26 21:34:32 UTC - -
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 “
BitcoinTalk
Re: Website translations
2010-05-27 14:18:22 UTC - -
Hurray! We have our first language. I uploaded it to SVN to go in with the 0.3 release.
BitcoinTalk
Re: Hostnames instead of IP Addresses
2010-06-02 18:18:15 UTC - -
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
or
1auaDZCFYqaGx4FKS5WenNfurk2SkoDu4h
I need suggestions for the separator character. “:” is a candidate, but IPv6 has : in it and that might get confusing. Something that’s allowed in url parameters would be nice.
I want to use SSL for the connection, using the bitcoin address’ public key as the cert. You would be certain you’re connected to who you thought, and safely encrypted. The bitcoin address would not be used for the transaction, only for authentication. A new generated bitcoin address would be sent through the SSL connection.
Since it’s authenticated, it would then be safe to allow the IP address to be a domain name. Some care taken that if a proxy is used, it uses socks4a instead of DNS lookup.
BitcoinTalk
Re: Proof-of-work difficulty increasing
2010-06-02 18:45:38 UTC - -
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.
BitcoinTalk
Re: Website translations
2010-06-02 22:18:09 UTC - -
I uploaded the 93% complete Dutch translation to SVN. Thanks!
BitcoinTalk
Re: On IRC bootstrapping
2010-06-14 18:13:21 UTC - -
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?
BitcoinTalk
Re: Hostnames instead of IP Addresses
2010-06-14 19:53:44 UTC - -
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.
BitcoinTalk
Re: Dealing with SHA-256 Collisions
2010-06-14 20:39:50 UTC - -
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.
BitcoinTalk
Re: Technical clarifications
2010-06-14 22:21:55 UTC - -
- Nothing, if sending by bitcoin address
- It is decentralised. After you have connected to the network the first time, you no longer need IRC.
BitcoinTalk
Re: Can’t Build r80 from SVN
2010-06-14 22:40:14 UTC - -
Sorry, I didn’t test compile on linux the last few revisions.
Reverted makefile.unix.
BitcoinTalk
Re: What is the incentive to collect transactions?
2010-06-15 23:41:29 UTC - -
Quote from: theymos on June 05, 2010, 04:26:09 PM
Adding transactions to the block you’re working on will slow down your generation rate
The premise is false. Adding more transactions to the block you’re working on does NOT slow down your generation rate. When generate is scanning hashes, it only hashes the header of the block, which is constant size. The header contains a hash of the transactions (the Merkle root) and is only updated occasionally.
If necessary I can write code to make nodes prefer not to use a block if it doesn’t contain enough of the transactions they know about. A discouraged block would almost always fail to be included in the main chain, but would be accepted if it did get in. I doubt this will be necessary, since there’s no real advantage for nodes not to include all transactions.
BitcoinTalk
Re: URI-scheme for bitcoin
2010-06-16 00:15:47 UTC - -
http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345
or
http://127.0.0.1:8330/?to=
But as long as the link is already doing the typing for you, I don’t see much benefit in using a domain address instead of bitcoin address. With a bitcoin address, the user can’t send an unidentified payment. They can’t send payment until they’ve been given a correct bitcoin address to send to.
What would be nice about sending by domain is you could visually verify who it’s going to.
A more crucial issue is what if the browser isn’t allowed to connect to 127.0.0.1:
http://BitcoinTalk.org/index.php?topic=63.msg1589#msg1589
and if that’s true, then what about that example freenet link that had 127.0.0.1 in it?
BitcoinTalk
Re: Website translations
2010-06-16 16:53:34 UTC - -
Thanks DataWraith! The German translation is uploaded to SVN.
This is great, we’ve already got 3 major languages.
BitcoinTalk
Re: new binary release?
2010-06-17 17:07:56 UTC - -
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!).
BitcoinTalk
Re: Transactions and Scripts: DUP HASH160 … EQUALVERIFY CHECKSIG
2010-06-17 18:46:08 UTC - -
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.