Satoshi Posts

A time capsule of Bitcoin golden age. Randomly selected classic posts. Join us in exploring Bitcoin Roots!

Public Key

npub1km3kxykvt4u4d8twn2mhhdfyd6z8e5kmkdtjc8rxqm0em0tunzjscl6khs

NIP-57 Address

wastebomb60@walletofsatoshi.com

Profile Code

nprofile1qqstdcmrztx9672kn4hf4dmmk5jxapru6tdmx4evr3nqdhuah47f3fgppamhxue69uhkummnw3ezumt0d5qs6amnwvaz7tmwdaejumr0ds5rdcp9

Publishing to

nostr.mom

nos.lol

Author Public Key

npub1km3kxykvt4u4d8twn2mhhdfyd6z8e5kmkdtjc8rxqm0em0tunzjscl6khs

Show more details

Last Notes

2025-04-21 08:18:09

Re: Memory leak
You're connecting to yourself. All 21 connection attempts were to a node with version 31300 (0.3.13). Not everyone has 0.3.13 yet.
IRC seems to be working. It ought to have other nodes to try.
There may be something I need to do to make sure it doesn't try to connect to itself again right away after disconnecting. I can't see how it's happening though, it should be resetting nLastTry which would put it to the back of the queue, but the log doesn't show it.
You can try moving addr.dat aside. Maybe there's something wrong in it.
Are you using -addnode?
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/481/

2025-04-17 19:05:44

Re: a simple traffic load test run
Was that on the test network?
http://bitcointalk.org/index.php?topic=363.0
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/266/

2025-04-16 14:15:30

Re: 28 days without generation, i have 4200khash/s
Search debug.log for "proof-of-work found". If you find any, then check for any errors right after that.
Quote from: davidonpda on August 19, 2010, 07:43:01 PM
How big of a margin on the time is allowed for things to work right.
The margin is 2 hours.
This should be solved in SVN rev 141 and the next release (0.3.11+). It'll pop up a message box alerting you if your clock is off by more than an hour.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/407/

2025-04-15 12:05:38

Re: Scalability
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.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/188/

2025-04-14 09:14:21

Re: 4 hashes parallel on SSE2 CPUs for 0.3.6
On both MinGW GCC 4.4.1 and 4.5.0 I have it working with test.cpp but SIGSEGV when called by BitcoinMiner. So now it doesn't look like it's the version of GCC, it's something else, maybe just the luck of how the stack is aligned.
I have it working fine on GCC 4.3.3 on Ubuntu 32-bit.
I found the problem with Crypto++ on MinGW 4.5.0. Here's the patch for that:
Code:
--- \old\sha.cpp
Mon Jul 26 13:31:11 2010
+++
ew\sha.cpp
Sat Aug 14 20:21:08 2010
@@ -336,7 +336,7 @@
ROUND(14, 0, eax, ecx, edi, edx)
ROUND(15, 0, ecx, eax, edx, edi)
-
ASL(1)
+ ASL(label1) // Bitcoin: fix for MinGW GCC 4.5
AS2(add WORD_REG(si), 4*16)
ROUND(0, 1, eax, ecx, edi, edx)
ROUND(1, 1, ecx, eax, edx, edi)
@@ -355,7 +355,7 @@
ROUND(14, 1, eax, ecx, edi, edx)
ROUND(15, 1, ecx, eax, edx, edi)
AS2(
cmp
WORD_REG(si), K_END)
-
ASJ(
jne,
1, b)
+ ASJ( jne, label1, ) // Bitcoin: fix for MinGW GCC 4.5
AS2(
mov
WORD_REG(dx), DATA_SAVE)
AS2(
add
WORD_REG(dx), 64)
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/362/

2025-04-13 13:26:11

Re: Always pay transaction fee?
Another option is to reduce the number of free transactions allowed per block before transaction fees are required. Nodes only take so many KB of free transactions per block before they start requiring at least 0.01 transaction fee.
The threshold should probably be lower than it currently is.
I don't think the threshold should ever be 0. We should always allow at least some free transactions.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/439/

2025-04-11 09:30:11

Re: Did block generation crawl to a halt?
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.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/245/

2025-04-10 08:04:23

Re: Reading/Writing Blocks and FLATDATA
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.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/265/

2025-04-08 19:22:47

Re: UI improvements
Quote from: Xunie on February 23, 2010, 12:28:27 PM
/etc/init.d/gdm start
and it will start gdm!
Ah yes, there we go, back to normal again.
The ctrl+alt+F[1-8] thing never worked on this computer. The screen just goes haywire.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/70/

2025-04-07 14:48:23

Re: URI-scheme for bitcoin
Quote from: Karmicads on May 01, 2010, 06:06:53 AM
A freenet URI is like this:
http://127.0.0.1:8888/USK@oshw3DxmJUt7q4ThF4dCez5IXbc9hCGcv0VuwLRCmeQ,ckeXv20F1gBzkqssB4RXHZ2nB1YRT8Pb8KYZk8wj-bs,AQACAAE/occamsrazor/6/f.pdf
There you go, we could easily do it the same way, like:
http://127.0.0.1:8330/?to=
<bitcoinaddress>;amount=<amount>
Bitcoin can answer port 8330 on local loopback just as it does for JSON-RPC on 8332. It would give an HTTP answer.
Quote from: DataWraith on May 02, 2010, 11:13:09 AM
A bitcoin-link should be more like mailto: than magnet: IMHO.
I think we can do that.
Although it would be possible for Bitcoin to take care of business in the HTTP response by presenting HTML UI to the user, as a user I would wonder if some website is trying to trick me or if I'm really talking to my own Bitcoin server.
The HTTP response could simply be HTML with the JavaScript equivalent of the back button, sending it back to the page. Bitcoin then pops up the Send Bitcoins dialog with the destination bitcoin address and amount already filled in. It would work just like a mailto: link that pops up a new email with the address filled in.
127.0.0.1 loopback is accessible by any user on the machine, it doesn't have per-user separation, but it's OK because it would only serve the convenience function of pre-filling the fields in a dialog. You'd still have to press Send. We'd have to make sure the Send button is not selected so it couldn't jump into the foreground while you're typing a space or enter.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/100/

2025-04-05 09:15:39

Re: Command Line and JSON-RPC
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.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/89/

2025-04-04 10:50:29

Bitcoin 0.3.1 released
This is a bugfix maintenance release. It is now uploaded to SourceForge. Mac OS X didn't need any fixes so we don't really need to update it, 0.3.0 is still good.
The download links are on bitcoin.org
Changes:
- Added Portuguese translation by Tiago Faria
Windows
- Fix for 22DbRunRecoveryException if your username has non-ascii characters in it
Linux
- Laszlo's fix for lowering generate thread to lowest priority
- Fix for if you're having trouble with libcrypto linkage
- Gavin Andresen's implementation of "start on windowing system startup" option
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/193/

2025-04-03 07:19:25

2025-04-02 13:11:51

Re: Proof-of-work difficulty increasing
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.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/218/

2025-04-01 07:49:22

Re: Proof-of-work difficulty increasing
The automatic adjustment happened earlier today.
24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000
24/02/2010 3.78 +49%
I updated the first post.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/78/

2025-03-31 19:56:19

Re: overflow bug SERIOUS
The bad chain is also slowed down as more nodes upgrade.
We've already generated 14 blocks since 74638. The builds of 0.3.10 were uploaded about 2 and 3 hours ago. Of the nodes I'm connected to, more than half are already 0.3.10. I would say we probably already have more power than the bad chain.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/382/

2025-03-31 08:46:24

Re: Website and software translations
poedit reorganised the file for some reason. I re-ran update from sources and it put it back in the original order so it's fine now. Did you run it on a drive where files aren't sorted alphabetically, like a FAT drive or USB flash drive?
Strings aren't added or changed very often. It's months before enough changes build up.
I uploaded the changes.
This Windows build has the Russian translation in it:
http://www.bitcoin.org/download/bitcoin-0.3.13.2-win32-setup.exe
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/486/

2025-03-29 15:56:56

Bitcoin 0.3.3 released -- PLEASE UPGRADE
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
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/268/

2025-03-28 09:39:27

Re: Bitcoin clients getting k-lined from the IRC bootstrapping channel
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
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/150/

2025-03-27 19:03:48

2025-03-27 09:26:41

Re: Where is the separate discussion devoted to possible Bitcoin weaknesses.
It doesn't have to be such a breaking change. New nodes could accept old transactions for a long time until most nodes have already upgraded before starting to refuse transactions without PoW. Or, they could always accept old transactions, but only a limited number per time period.
I've thought about PoW on transactions many times, but usually I end up thinking a 0.01 transaction fee is essentially similar and better. 0.01 is basically a proof of work, but not wasted. But if the problem is validating loads of transactions, then PoW could be checked faster.
A more general umbrella partial solution would be to implement the idea where an unlikely dropoff in blocks received is detected. Then an attacker would still need a substantial portion of the network's power to benefit from a DoS attack.
Quote from: gavinandresen on August 11, 2010, 04:10:56 PM
Bitcoin's p2p network is subject to various kinds of denial of service attacks.
There, I said it.
+1
Any demonstration tests at this point would only show what we already know, and divert dev time from strengthening the system to operational fire fighting.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/344/

2025-03-26 12:36:44

Re: Bitcoin Address Collisions
Quote from: NewLibertyStandard on February 23, 2010, 07:04:47 PM
Are generated bitcoins encrypted with whichever address is currently displayed in the main Bitcoin window?
No, each generated transaction uses a new, single-use address.
Nothing uses the address in the main window, it's just there for convenience for you to copy. 0.2.5 has a "New..." button next to it to make it easy to change each time you use it.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/72/

2025-03-25 20:31:43

Re: Request: expected bitcoins per day display
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.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/217/

2025-03-24 15:56:32

Re: 0.3.10.1 Question on where block should be
For now, can some people running 0.3.10 with static IP who can receive incoming connections post their IP? Then we can -addnode= them and make sure to connect to at least one 0.3.10 node.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/378/

2025-03-23 08:23:40

Re: URI-scheme for bitcoin
http://127.0.0.1:8330/?to=domain.com&amount=200.00&comment=order_12345
or
http://127.0.0.1:8330/?to=
<bitcoinaddress><separatorchar>1.2.3.4&amount=200.00
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?
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/123/

2025-03-21 11:37:00

Re: JSON-RPC password
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?)
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/246/

2025-03-20 10:34:19

Re: Version 0.3.11 with upgrade alerts
Quote from: torservers on August 28, 2010, 01:00:37 PM
The "About" dialog still shows 0.3.10.1 beta.
What OS? I ran the Windows and 64-bit Linux version and checked the about dialog.
The Mac version is still 0.3.10.1.
Quote from: pavelo on August 28, 2010, 07:36:07 AM
iirc, it is possible to specify -march on a per-function basis using some gcc __attribute__. That way, only the function in question would be optimized, and if the user doesn't specify -4way, everything else should be ok.
I updated the first post to be more specific. Only the -4way code is compiled this way.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/431/

2025-03-19 17:32:18

Re: Source code documentation
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.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/219/

2025-03-18 21:19:03

Re: Repost: Bitcoin Maturation
It's important to have network connectivity while you're trying to generate a coin (block) and at the moment it is successfully generated.
1) During generation (when the status bar says "Generating" and you're using CPU to find a proof-of-work), you must constantly keep in contact with the network to receive the latest block. If your block does not link to the latest block, it may not be accepted.
2) When you successfully generate a block, it is immediately broadcast to the network. Other nodes must receive it and link to it for it to be accepted as the new latest block.
Think of it as a cooperative effort to make a chain. When you add a link, you must first find the current end of the chain. If you were to locate the last link, then go off for an hour and forge your link, come back and link it to the link that was the end an hour ago, others may have added several links since then and they're not going to want to use your link that now branches off the middle.
After a block is created, the maturation time of 120 blocks is to make absolutely sure the block is part of the main chain before it can be spent. Your node isn't doing anything with the block during that time, just waiting for other blocks to be added after yours. You don't have to be online during that time.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/8/

2025-03-18 09:14:53

2025-03-17 11:25:19

Re: Hash() function not secure
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.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/216/

2025-03-16 18:50:08

Added some DoS limits, removed safe mode (0.3.19)
There's more work to do on DoS, but I'm doing a quick build of what I have so far in case it's needed, before venturing into more complex ideas. The build for this is version 0.3.19.
- Added some DoS controls
As Gavin and I have said clearly before, the software is not at all resistant to DoS attack. This is one improvement, but there are still more ways to attack than I can count.
I'm leaving the -limitfreerelay part as a switch for now and it's there if you need it.
- Removed "safe mode" alerts
"safe mode" alerts was a temporary measure after the 0.3.9 overflow bug. We can say all we want that users can just run with "-disablesafemode", but it's better just not to have it for the sake of appearances. It was never intended as a long term feature. Safe mode can still be triggered by seeing a longer (greater total PoW) invalid block chain.
Builds:
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.19/
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/543/

2025-03-15 09:39:42

Re: 28 days without generation, i have 4200khash/s
Make sure your computer's date and time are correct.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/403/

2025-03-15 01:16:39

Re: 0.3 almost ready
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?
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/141/

2025-03-14 20:16:02

Re: IPv6, headless client, and more
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.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/158/

2025-03-14 10:23:32

Re: Feature Request: Limiting Connections
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.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/165/

2025-03-13 18:53:46

Re: Proof-of-work difficulty increasing
The formula is based on the time it takes to generate 2016 blocks. The difficulty is multiplied by 14/(actual days taken). For instance, this time it took 9.4 days, so the calculation was 14/9.4 = 1.49. Previous difficulty 2.53 * 1.49 = 3.78, a 49% increase.
I don't know what you're talking about accepting easier difficulties.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/81/

2025-03-13 09:46:51

Re: Proof-of-work difficulty increasing
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.
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/221/

2025-03-12 20:51:06

0.3.13 RC1 for Windows, please test
0.3.13 release candidate, to be released soon so please test:
http://www.bitcoin.org/download/bitcoin-0.3.13-rc1-win32-setup.exe
- don't count or spend payments until they have 1 confirmation
http://bitcointalk.org/index.php?topic=1306.0
- internal version number from 312 to 31300
- only accept transactions sent by IP address if -allowreceivebyip is specified
- dropped DB_PRIVATE Berkeley DB flag
- fix problem sending the last cent with sub-cent fractional change
- auto-detect whether to use 128-bit 4-way SSE2 on Linux
Gavin Andresen:
- option -rpcallowip= to accept json-rpc connections from another machine
- clean shutdown on SIGTERM on Linux
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/466/

2025-03-12 09:51:59

Re: overflow bug SERIOUS
It looks like we overtook the bad chain somewhere around 74689. 0.3.9 and lower nodes have been responding with the current block number for some hours now.
That means it's no longer necessary to delete blk*.dat before upgrading. You can just upgrade and it'll reorg away the bad block chain.
Thanks to everyone for the quick response!
Fonte: https://satoshi.nakamotoinstitute.org/posts/bitcointalk/387/