#

include

(8 articles)

narr +webkit2 web-based RSS 阅读nostr长文

## 什么是narr？ 今天翻 fiatjaf 仓库 竟然发现了这个宝贝 narr和我最进做的 nostrbook.com有交集。 >? 交集在哪里呢？ narr (not another rss reader) is a web-based RSS and Nostr long-form feed aggregator which can be used both as a desktop application and a personal self-hosted server. 1. long-form ,也就是30023. 2. desktop application 这两点足够对我有吸引力。 下载，运行 界面不错。 继续！ ![图片](https://cdn.nostrcheck.me/fd06f542bc6c06a39881810de917e6c5d277dfb51689a568ad7b7a548d6d54cd/62a4e0375a7a718581aea182dd196be7b3898718d11bcb0f2edd4fe4b11eef78.webp){.user-img} 不过这个是需要 自己通过浏览器浏览的。并没有独立打包成一个app。那么问题来了，不够阿。 顺着他的介绍，The app is a single binary with an embedded database (SQLite), it is based on yarr. ## yarr 我去看了看yarr 是可支持gui的，不过Linux支持的不够，我平时基本就是Linux。 怎么办？ ## webkit 用webkit套一个吧。 ```go package main /* #cgo linux pkg-config: webkit2gtk-4.1 gtk+-3.0 #include <gtk/gtk.h> #include <webkit2/webkit2.h> static void initAndShow(GtkWidget **window, const char *url) { // 必须初始化 GTK gtk_init(NULL, NULL); *window = gtk_window_new(GTK_WINDOW_TOPLEVEL); gtk_window_set_title(GTK_WINDOW(*window), "nostrbook.com"); gtk_window_set_default_size(GTK_WINDOW(*window), 1024, 600); // 创建 WebView GtkWidget *webview = webkit_web_view_new(); gtk_container_add(GTK_CONTAINER(*window), webview); webkit_web_view_load_uri(WEBKIT_WEB_VIEW(webview), url); // 显示窗口 gtk_widget_show_all(*window); } */ import "C" import ( "unsafe" ) func main() { var window *C.GtkWidget url := C.CString("http://127.0.0.1:7049") defer C.free(unsafe.Pointer(url)) // 调用 C 函数初始化 C.initAndShow(&window, url) // 进入 GTK 主循环 C.gtk_main() } ``` ## 什么是下一步呢？ 继续研究吧，看看go + webkit 能不能打包 这个 http server ？ 再看看 有没有可以编辑的 md ide 用simple 也可以的。 等等看吧。

nostrblogcgoinclude

Linking a C Library with Android Using JNI

If you need to use a C/C++ library in your Android app, you will need to use the Java Native Interface (JNI). This was my experience integrating a C blockchain library called "libqaeda" ,into an Android application we are working on with lash. Many thanks to [lash ](https://github.com/nolash) for advising on using this platform , and who wrote the C library. **Libqaeda and What it does** libqaeda is a cryptographic library designed to enable bi-lateral countersigning of chains of promises and statements. At its core, the library provides a robust framework for creating verifiable certificates that require dual signatures - one from the requester and one from the responder. The library excels at establishing cryptographic proof chains that can be used for: * Verifying authenticity and proof-of-ownership of certificates * Tracking credit or commitments between individuals * Creating chains of trust where each link requires mutual agreement What makes libqaeda particularly flexible is its modular design. It offers customizable components for cryptography implementations, data storage backends, and trust management - allowing developers to adapt it to various environments from servers to mobile devices. While currently in alpha development status and not safe in any way, libqaeda shows promise as a foundation for applications requiring strong cryptographic verification of bilateral agreements. **Java Native Interface** JNI makes it possible to interact with native code( code written in C , C++ , Assembly). It is useful in the following cases: 1. Reusing existing native libraries in your java app 2. Accessing low-level system APIs. 3. Implementing JVM into a native application. 4. Performance critical tasks such as gaming. **How JNI Works** 1. Java calls the native methods which are declared with the native keyword. 2. The native code is compiled into a shared library (.so on Linux/Android, .dll on WIndows) 3. JVM loads the library at runtime and executes native functions. **The Challenge** We wanted to use the C library in the Android app, but we faced a few challenges: * The library was originally built for desktop systems, not Android * Android needs code compiled for specific CPU architectures like arm64-v8a * There were dependencies on specific C libraries not available in Android **Step 1: Define the Java Interface** First, I created a Java class that declares the native methods I wanted to use: ``` package org.defalsified.android.badged.services; public class LibQaeda { static { System.loadLibrary("qaeda"); } public native long createDummyStore(); public native String dummyContentGet(int payloadType, long storePtr, byte[] key); } ``` The static block loads our native library, and the native methods t![![]()]()ell Java these functions are implemented in C. **Step 2: Create the JNI Function Implementations** Next, I created a C file that implements the Java native methods: ``` #include <jni.h> #include <stdlib.h> #include "libqaeda/src/lq/store.h" #include "libqaeda/src/lq/err.h" #include <hex.h> // Functions from the library extern int lq_dummy_content_get(enum payload_e typ, LQStore *store, const char *key, size_t key_len, char *value, size_t *value_len); extern struct lq_store_t LQDummyContent; // JNI implementation JNIEXPORT jlong JNICALL Java_org_defalsified_android_badged_services_LibQaeda_createDummyStore (JNIEnv *env, jobject thiz) { LQStore *store = (LQStore*)malloc(sizeof(LQStore)); *store = LQDummyContent; return (jlong)store; } JNIEXPORT jstring JNICALL Java_org_defalsified_android_badged_services_LibQaeda_dummyContentGet (JNIEnv *env, jobject thiz, jint payloadType, jlong storePtr, jbyteArray key) { LQStore *store = (LQStore*)storePtr; jbyte *keyBytes = (*env)->GetByteArrayElements(env, key, NULL); jsize keyLength = (*env)->GetArrayLength(env, key); char value[4096] = {0}; size_t valueLen = sizeof(value); int result = lq_dummy_content_get( (enum payload_e)payloadType, store, (const char*)keyBytes, (size_t)keyLength, value, &valueLen ); (*env)->ReleaseByteArrayElements(env, key, keyBytes, JNI_ABORT); if (result != 0) { return NULL; } return (*env)->NewStringUTF(env, value); } ``` The function names must match the Java class and method names, prefixed with Java_ and using underscores for package separators. **Step 3: Set Up CMake to Build the Native Library** The key step was creating a CMakeLists.txt file to build our native library. Initially, I tried to use the pre-built library, but it was incompatible with Android. So I decided to directly compile the necessary source files: ``` cmake_minimum_required(VERSION 3.10) project(badged_app) set(LIBQAEDA_DIR ${CMAKE_CURRENT_SOURCE_DIR}/libqaeda) set(LIBQAEDA_SRC_DIR ${LIBQAEDA_DIR}/src) include_directories( ${CMAKE_CURRENT_SOURCE_DIR} ${LIBQAEDA_SRC_DIR} ${LIBQAEDA_SRC_DIR}/aux/include ${LIBQAEDA_SRC_DIR}/aux/liblash/src ${LIBQAEDA_SRC_DIR}/aux/liblash/src/hex ${LIBQAEDA_SRC_DIR}/aux/liblash/src/rerr ) # Create qaeda library with all required source files add_library(qaeda SHARED ${CMAKE_CURRENT_SOURCE_DIR}/org_defalsified_android_badged_services_LibQaeda.c ${LIBQAEDA_SRC_DIR}/store/dummy.c ${LIBQAEDA_SRC_DIR}/aux/liblash/src/hex/hex.c ${LIBQAEDA_SRC_DIR}/aux/liblash/src/rerr/rerr.c ) # Link against Android libraries target_link_libraries(qaeda android log atomic m ) # Create main app library add_library(badged SHARED native-lib.cpp ) # Link app against our JNI wrapper target_link_libraries(badged qaeda android log ) ``` Instead of trying to use a pre-built library, I included just the specific source files we needed for our minimal implementation. **Step 4: Configure the Android Project** In the app's build.gradle file, I added the CMake configuration: ``` android { // Other settings... externalNativeBuild { cmake { path = file("src/main/cpp/CMakeLists.txt") version = "3.22.1" } } // Specify the NDK version to use ndkVersion = "25.1.8937393" // Configure for multiple architectures defaultConfig { ndk { abiFilters.addAll(listOf("armeabi-v7a", "arm64-v8a", "x86", "x86_64")) } } } ``` **Step 5: Use the Library in Your Android Activity** Finally, I used the library in my app: ``` public class MainActivity extends AppCompatActivity { private static final String TAG = "MainActivity"; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); TextView textView = new TextView(this); textView.setText("Welcome to Badges!"); try { LibQaeda libQaeda = new LibQaeda(); long storePtr = libQaeda.createDummyStore(); byte[] key = "test_key".getBytes(); String result = libQaeda.dummyContentGet(1, storePtr, key); textView.append("\n\nLibQaeda Test:\n" + result); } catch (Exception e) { textView.append("\n\nLibQaeda Test Error:\n" + e.getMessage()); } setContentView(textView); } } ``` **Key Lessons Learned** 1. Be careful with pre-built libraries for Android: Pre-built libraries need to be compiled specifically for Android's architectures (arm64-v8a, armeabi-v7a, x86, x86_64). If a library was built for desktop systems (like x86_64 Linux), it won't work on Android devices with different architectures. 2. Consider direct compilation when needed: If you have access to the library's source code and encounter compatibility issues with pre-built versions, compiling the source files directly for Android can solve architecture incompatibility problems. 3. Use Android NDK tools for cross-compilation: When you do need pre-built libraries, use the Android NDK's toolchain to properly cross-compile them for all target Android architectures. 4. Be selective about which files to include: Only include the specific source files you need, which can reduce complexity and potential issues. 5. Handle dependencies carefully: Make sure to include any header files and source code required by your library functions. **Conclusion** In this project, we successfully integrated a C library with an Android application using JNI. While this approach of directly compiling the necessary source files worked well for our immediate needs, there are other paths we could explore in the future. We may need to create an arm64 static library instead, but having the code running is an important first step. The JNI bridge provides a powerful way to leverage existing C/C++ code in Android applications. Whether you're working with algorithms, legacy systems, or performance-critical components, understanding how to connect Java and native code opens up many possibilities for Android development. By following the steps outlined in this blog post, you should now have the knowledge to integrate your own C libraries into Android applications, adapting the approach to your specific requirements. Adios!

include

てすてす

code snipet ``` #include <stdio.h> int main(void) { printf("moge\n"); return 0; } ```

include

Kicking the Hornet's Nest - part 17

# Kicking the Hornet's Nest - third edition - part 17 All links, digital (pdf, txt, docx, md) and book in print, can be found at https://hive.blog/@crrdlx/satoshi Edited by [crrdlx](nostr:nprofile1qyv8wumn8ghj7mn0wdj8y6tkv5hxzurs9aex2mrp0yq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqzqqzmcn0yrn7ttq8hrjkk46ysn2tk26rr8f8k4y7xkl74hlh3rcdzm9d3t8), npub: ``` npub1qpdufhjpel94srm3ett2azgf49m9dp3n5nm2j0rt0l2mlmc3ux3qza082j ``` ---- ### Kicking the Hornet's Nest pages 375 - 400 ---- ##### BitcoinTalk #### Re: Bitcoin minting is thermodynamically perverse ##### _2010-08-07 17:46:09 UTC_ - [-](https://bitcointalk.org/index.php?topic=721.msg8114#msg8114) It's the same situation as gold and gold mining. The marginal cost of gold mining tends to stay near the price of gold. Gold mining is a waste, but that waste is far less than the utility of having gold available as a medium of exchange. I think the case will be the same for Bitcoin. The utility of the exchanges made possible by Bitcoin will far exceed the cost of electricity used. Therefore, _not_having Bitcoin would be the net waste. [_**Quote from: gridecon on August 06, 2010, 04:48:00 PM**_](https://bitcointalk.org/index.php?topic=721.msg7889#msg7889) _As an overall point, I also do not agree with the idea that the very high computational burden of coin generation is in fact a necessity of the current system. As I understand it, currency creation is fundamentally metered by TIME - and if that is the fundamental controlling variable, what is the need for everyone to "roll as many dice as posible" within that given time period? The "chain of proof" for coin ownership and transactions doesn't depend on the method for spawning coins._ Each node's influence on the network is proportional to its CPU power. The only way to show the network how much CPU power you have is to actually use it. If there's something else each person has a finite amount of that we could count for one-person-one-vote, I can't think of it. IP addresses... much easier to get lots of them than CPUs. I suppose it might be possible to measure CPU power _at certain times_. For instance, if the CPU power challenge was only run for an average of 1 minute every 10 minutes. You could still prove your total power at given times without running it all the time. I'm not sure how that could be implemented though. There's no way for a node that wasn't present at the time to know that a past chain was actually generated in a duty cycle with 9 minute breaks, not back to back. Proof-of-work has the nice property that it can be relayed through untrusted middlemen. We don't have to worry about a chain of custody of communication. It doesn't matter who tells you a longest chain, the proof-of-work speaks for itself. ##### BitcoinTalk #### Re: A proposal for a semi-automated Escrow mechanism ##### _2010-08-07 20:04:59 UTC_ - [-](https://bitcointalk.org/index.php?topic=645.msg8137#msg8137) [_**Quote from: jgarzik on August 05, 2010, 07:00:30 PM**_](https://bitcointalk.org/index.php?topic=645.msg7723#msg7723) _Due to that recourse, it is unlikely to be used as an escrow mechanism_ ![](file:///tmp/lu30467eu8.tmp/lu30468nv5_tmp_b56eb9f04b2623cd.gif) 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.) ##### BitcoinTalk #### Escrow ##### _2010-08-07 20:13:52 UTC_ - [-](https://bitcointalk.org/index.php?topic=750.msg8140#msg8140) 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. ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-07 21:16:01 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg8145#msg8145) [_**Quote from: impossible7 on August 06, 2010, 11:37:20 AM**_](https://bitcointalk.org/index.php?topic=648.msg7838#msg7838) _CRITICAL_BLOCK is a macro that contains a for loop. The assertion failure indicates that break has been called inside the body of the loop. The only break statement in this block is in line 2762. In the original source file, there is no break statement in this critical block. I think you must remove lines 2759-2762. The is nothing like that in the original main.cpp._ Sorry about that. CRITICAL_BLOCK isn't perfect. You have to be careful not to break or continue out of it. There's an assert that catches and warns about break. I can be criticized for using it, but the syntax would be so much more bloated and error prone without it. Is there a chance the SSE2 code is slow on Intel because of some quirk that could be worked around? For instance, if something works but is slow if it's not aligned, or thrashing the cache, or one type of instruction that's really slow? I'm not sure how available it is, but I think Intel used to have a profiler for profiling on a per instruction level. I guess if tcatm doesn't have a system with the slow processor to test with, there's not much hope. But it would be really nice if this was working on most CPUs. ##### BitcoinTalk #### Re: bitcoin generation broken in 0.3.8? ##### _2010-08-09 18:50:41 UTC_ - [-](https://bitcointalk.org/index.php?topic=753.msg8388#msg8388) 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. ##### BitcoinTalk #### Version 0.3.8.1 update for Linux 64-bit ##### _2010-08-09 19:46:58 UTC_ - [-](https://bitcointalk.org/index.php?topic=765.msg8402#msg8402) 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/download](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download) Future versions after 0.3.8 will probably require SSE2. Anyone have Pentium 3 or older where this would be a problem? ##### BitcoinTalk #### Re: What could be the transition plan to Y2038 compliant Bitcoin? ##### _2010-08-09 20:13:26 UTC_ - [-](https://bitcointalk.org/index.php?topic=760.msg8413#msg8413) **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. ##### BitcoinTalk #### Re: bitcoin generation broken in 0.3.8? (64-bit) ##### _2010-08-09 20:34:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=753.msg8417#msg8417) 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.0](http://bitcointalk.org/index.php?topic=765.0) Download: [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.3.8/bitcoin-0.3.8.1-linux.tar.gz/download) ##### BitcoinTalk #### Re: Version 0.3.8.1 update for Linux 64-bit ##### _2010-08-09 20:55:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=765.msg8422#msg8422) 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 #endif that would disable SSE2 for 32-bit builds. (at least with GCC or MSVC) ##### BitcoinTalk #### Connection limits ##### _2010-08-09 20:58:45 UTC_ - [-](https://bitcointalk.org/index.php?topic=766.msg8424#msg8424) 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? ##### BitcoinTalk #### Re: Bitcoin minting is thermodynamically perverse ##### _2010-08-09 21:28:39 UTC_ - [-](https://bitcointalk.org/index.php?topic=721.msg8431#msg8431) 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. ##### BitcoinTalk #### Re: Version 0.3.8.1 update for Linux 64-bit ##### _2010-08-10 23:46:00 UTC_ - [-](https://bitcointalk.org/index.php?topic=765.msg8628#msg8628) 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. ##### BitcoinTalk #### Re: Not a suggestion ##### _2010-08-11 00:14:22 UTC_ - [-](https://bitcointalk.org/index.php?topic=770.msg8637#msg8637) 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. ##### BitcoinTalk #### Re: Escrow ##### _2010-08-11 01:30:02 UTC_ - [-](https://bitcointalk.org/index.php?topic=750.msg8649#msg8649) [_**Quote from: jgarzik on August 10, 2010, 06:53:57 PM**_](https://bitcointalk.org/index.php?topic=750.msg8566#msg8566) _Ask some real-world business owners if they want to tell their customers about the chance of the money being lost forever, unrecoverable by either party._ That makes it sound like it might somehow get lost and the parties can't get it even if they want to cooperate. When you pay for something up front, you can't get it back either. Consumers seem comfortable with that. It's no worse than that. Either party always has the option to release it to the other. [_**Quote from: nelisky on August 10, 2010, 08:20:36 PM**_](https://bitcointalk.org/index.php?topic=750.msg8585#msg8585) _But the money burning solution, while great at preventing economically viable fraud, does nothing to prevent revenge and actually makes everyone loose if one side is dishonest. I would certainly not endorse that._ Then you must also be against the common system of payment up front, where the customer loses. Payment up front: customer loses, and the thief gets the money. Simple escrow: customer loses, but the thief doesn't get the money either. Are you guys saying payment up front is better, because at least the thief gets the money, so at least someone gets it? Imagine someone stole something from you. You can't get it back, but if you could, if it had a kill switch that could be remote triggered, would you do it? Would it be a good thing for thieves to know that everything you own has a kill switch and if they steal it, it'll be useless to them, although you still lose it too? If they give it back, you can re-activate it. Imagine if gold turned to lead when stolen. If the thief gives it back, it turns to gold again. It still seems to me the problem may be one of presenting it the right way. For one thing, not being so blunt about "money burning" for the purposes of game theory discussion. The money is never truly burned. You have the option to release it at any time forever. ##### BitcoinTalk #### Re: Compile error in SVN r127 ##### _2010-08-11 01:42:30 UTC_ - [-](https://bitcointalk.org/index.php?topic=784.msg8651#msg8651) Updated SVN. Thanks. There's little hope of not repeatedly stumbling over that in the future. It doesn't break the compile for me. **Martii Malmi (AKA Sirius) “COPA trial” email #228** **Date: Wed, 11 Aug 2010 02:54:27 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: [Fwd: Forum e-mail notifications and PBL blacklist and wiki registration]** **To: mmalmi@cc.hut.fi** Are PM notifications still disabled? (All we really need is disable the forum's access to the mail server) _> Does it work correctly now? I had made some forum code changes to_ _> disable PM email notification, but just reverted most of them as_ _> unnecessary._ ##### BitcoinTalk #### Re: Not a suggestion ##### _2010-08-11 21:07:59 UTC_ - [-](https://bitcointalk.org/index.php?topic=770.msg8798#msg8798) Still thinking this idea through... The only job the network needs to do is to tell whether a spend of an outpoint is the first or not. If we're willing to have clients keep the history for their own money, then some of the information may not need to be stored by the network, such as: - the value - the association of inpoints and outpoints in one transaction The network would track a bunch of independent outpoints. It doesn't know what transactions or amounts they belong to. A client can find out if an outpoint has been spent, and it can submit a satisfying inpoint to mark it spent. The network keeps the outpoint and the first valid inpoint that proves it spent. The inpoint signs a hash of its associated next outpoint and a salt, so it can privately be shown that the signature signs a particular next outpoint if you know the salt, but publicly the network doesn't know what the next outpoint is. I believe the clients would have to keep the entire history back to the original generated coins. Someone sending a payment would have to send data to the recipient, as well as still communicating with the network to mark outpoints spent and check that the spend is the first spend. Maybe the data transfer could be done as an e-mail attachment. The fact that clients have to keep the entire history reduces the privacy benefit. Someone handling a lot of money still gets to see a lot of transaction history. The way it retrospectively fans out, they might end up seeing a majority of the history. Denominations could be made granular to limit fan-out, but a business handling a lot of money might still end up seeing a lot of the history. **Martii Malmi (AKA Sirius) “COPA trial” email #230** **Date: Wed, 11 Aug 2010 21:00:13 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: [Fwd: Forum e-mail notifications and PBL blacklist and wiki registration]** **To: mmalmi@cc.hut.fi** Right, forgot about that. Hopefully theymos was right that the PBL is the source of the problem. mmalmi@cc.hut.fi wrote: > Yes, they're still disabled. Disabling the access to the mail server > would be easy, but we probably want to keep the password recovery by email. > ##### BitcoinTalk #### Re: Lost large number of bitcoins ##### _2010-08-11 21:46:51 UTC_ - [-](https://bitcointalk.org/index.php?topic=782.msg8803#msg8803) [_**Quote from: sirius-m on August 11, 2010, 02:01:53 AM**_](https://bitcointalk.org/index.php?topic=782.msg8657#msg8657) _I added to the FAQ the warning to back up after each transaction. Is it necessary btw to stop the client before making a backup? That's a bit inconvenient. Automatic backups would be useful indeed._ You can get away with backing up without stopping the client if you don't do anything or receive a payment within a few seconds before the backup. (like 5 seconds) [_**Quote from: gridecon on August 11, 2010, 08:46:08 PM**_](https://bitcointalk.org/index.php?topic=782.msg8795#msg8795) _Wait, I'm confused again. I thought the essence of the surprise was that Bitcoin is programmed to "empty your wallet" for EACH transaction._ No, it doesn't usually empty your wallet with each transaction. It uses the smallest set of coins it can find to add up to near the amount. In this case, unfortunately, his wallet had a single 9000 BTC bill in it, and it had to break it to get 1 BTC and 8999 BTC change. ##### BitcoinTalk #### Re: Where is the separate discussion devoted to possible Bitcoin weaknesses. ##### _2010-08-11 22:40:25 UTC_ - [-](https://bitcointalk.org/index.php?topic=788.msg8804#msg8804) 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**_](https://bitcointalk.org/index.php?topic=788.msg8761#msg8761) _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. ##### BitcoinTalk #### Re: Flood attack 0.00000001 BC ##### _2010-08-11 23:28:50 UTC_ - [-](https://bitcointalk.org/index.php?topic=287.msg8810#msg8810) It would be nice to keep the blk*.dat files small as long as we can. The eventual solution will be to not care how big it gets. But for now, while it's still small, it's nice to keep it small so new users can get going faster. When I eventually implement client-only mode, that won't matter much anymore. There's more work to do on transaction fees. In the event of a flood, you would still be able to jump the queue and get your transactions into the next block by paying a 0.01 transaction fee. However, I haven't had time yet to add that option to the UI. Scale or not, the test network will react in the same ways, but with much less wasted bandwidth and annoyance. ##### BitcoinTalk #### Re: BSD detection ##### _2010-08-12 00:02:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=790.msg8814#msg8814) [_**Quote from: dkaparis on August 11, 2010, 11:00:16 PM**_](https://bitcointalk.org/index.php?topic=790.msg8807#msg8807) _There is this piece of code in headers.h: __#ifdef __WXMAC_OSX____#define __WXMAC__ 1__#define __WXOSX__ 1__#define __BSD__ 1__#endif__#endif_ That code was a bad idea anyway, I'm deleting it. Any Mac code should only use __WXMAC_OSX__, not __WXMAC__ or __WXOSX__, and we should stop using __BSD__. _**Quote**_ _#if (defined(__unix__) || defined(unix)) && !defined(USG)__#include <sys/param.h>__#endif_ Will that definitely cause BSD to be defined on Mac? ##### BitcoinTalk #### Re: Not a suggestion ##### _2010-08-12 02:46:56 UTC_ - [-](https://bitcointalk.org/index.php?topic=770.msg8836#msg8836) [_**Quote from: Red on August 12, 2010, 01:10:19 AM**_](https://bitcointalk.org/index.php?topic=770.msg8824#msg8824) [**Quote from: satoshi on August 11, 2010, 09:07:59 PM**](https://bitcointalk.org/index.php?topic=770.msg8798#msg8798) I believe the clients would have to keep the entire history back to the original generated coins. The fact that clients have to keep the entire history reduces the privacy benefit. _ I thought this too at first. But then I convinced myself otherwise._ Are you back to talking about the existing Bitcoin system here? I was talking about in the hypothetical system I was describing, if the network doesn't know the values and lineage of the transactions, then it can't verify them and vouch for them, so the clients would have to keep the history all the way back. If a client wasn't present until recently, the two ways to convince it that a transaction has a valid past is: 1) Show it the entire history back to the original generated coin. 2) Show it a history back to a thoroughly deep block, then trust that if so many nodes all said the history up to then was correct then it must be true. But if the network didn't know all the values and lineage of the transactions, it couldn't do 2), I don't think. ##### BitcoinTalk #### Re: BSD detection ##### _2010-08-12 21:14:20 UTC_ - [-](https://bitcointalk.org/index.php?topic=790.msg8919#msg8919) This is in SVN rev 130. Check that it compiles right. **Code:** #if (defined(__unix__) || defined(unix)) && !defined(USG) #include <sys/param.h> // to get BSD define #endif #ifdef __WXMAC_OSX__ #ifndef BSD #define BSD 1 #endif #endif ##### BitcoinTalk #### Bugfixes in SVN rev 130 ##### _2010-08-12 21:20:31 UTC_ - [-](https://bitcointalk.org/index.php?topic=795.msg8920#msg8920) Misc bugfixes in rev 130: fix -datadir with relative path autostart is now off by default except on windows fix occasional "vector iterator not dereferencable" assertion when compiled with msvc fix readlink compile warning on linux build use sys/param.h and BSD define instead of __BSD__ -paytxfee switch, e.g. -paytxfee=0.01 ##### BitcoinTalk #### Re: Bitcoin Watchdog Service ##### _2010-08-12 21:34:44 UTC_ - [-](https://bitcointalk.org/index.php?topic=691.msg8922#msg8922) True, there would probably be someone with a dial-up modem or satellite dish internet. Rarer would be someone who has both that and the wired internet that has the outage, but if it's a big enough segment to matter, out of a million people there's bound to be a multi-home geek. ISP network cuts are just your local area. If you still have communication with the rest of your area, it would probably be something like 1/1000 of the world or less. Block generation in the segment would take several hours per block. I favour the plan to monitor if the frequency of blocks received drops too slow. That covers a large range of possibilities. ##### BitcoinTalk #### Re: Having problems specifing -datadir ##### _2010-08-12 21:43:29 UTC_ - [-](https://bitcointalk.org/index.php?topic=601.msg8924#msg8924) Fixed in SVN rev 130. ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-12 22:07:23 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg8929#msg8929) That big of a difference in speed, by a factor of 4 or 6, feels like it's likely to be some quirky weak spot or instruction that the old chip is slow with. Unless it's a touted feature of the i5 that they made SSE2 six times faster. A quick summary: Xeon Quad 41% slower Core 2 Duo 55% slower Core 2 Duo same (vess) Core 2 Quad 50% slower Core i5 200% faster (nelisky) Core i5 100% faster (vess) AMD Opteron 105% faster aceat64: My system went from ~7100 to ~4200. This particular system has dual Intel Xeon Quad-Core CPUs (E5335) @ 2.00GHz. impossible7: on an Intel Core 2 Duo T7300 running x86_64 linux it was 55% slower compared to the stock version (r121) nelisky: My Core2Quad (Q6600) slowed down 50%, my i5 improved ~200%, impossible7: on an AMD Opteron 2374 HE running x86_64 linux I got a 105% improvement (!) ##### BitcoinTalk #### Re: Bugfixes in SVN rev 130 ##### _2010-08-13 03:15:23 UTC_ - [-](https://bitcointalk.org/index.php?topic=795.msg8960#msg8960) No, that's not what it is. -paytxfee allows you to include a transaction fee with your transactions. If transaction confirmations become slow, you can get priority by using "-paytxfee=0.01". Any transactions you send would cost an extra 0.01. There's no reason to use more than 0.01. It's just there in case we need it. It probably won't be needed, and it can be explained more if we do. ##### BitcoinTalk #### Re: Bitcoin Watchdog Service ##### _2010-08-13 17:09:27 UTC_ - [-](https://bitcointalk.org/index.php?topic=691.msg9041#msg9041) _**Quote**_ _But there will be no irc server to bootstrap from._ Which doesn't matter because you can't access sourceforge to download the software either. If you've ever been connected before, you don't need IRC to bootstrap anymore. Even if you haven't, you can bootstrap from seed nodes. IRC is completely redundant since 0.3.0. ##### BitcoinTalk #### Version 0.3.9 rc1, please test ##### _2010-08-13 17:40:00 UTC_ - [-](https://bitcointalk.org/index.php?topic=806.msg9046#msg9046) Here's a test build if you'd like to help test before 0.3.9 is released. (or if you'd rather get upgrading out of the way now instead of waiting) Downloads: (binaries only) [http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-win32.zip](http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-win32.zip) ([http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-linux.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.9.rc1-linux.tar.gz)) SHA1 a36ea00cce27b4b083755df73a3d1e5e5729884e bitcoin-0.3.9.rc1-win32.zip SHA1 bbb333b0ea57302740ad1bb9948520d00f884f9d bitcoin-0.3.9.rc1-linux.tar.gz Edit: Linux please test rc2 instead. This adds a -4way switch for tcatm's 4-way SSE2. This will only be for Linux: [http://www.bitcoin.org/download/bitcoin-0.3.9.rc2-linux.tar.gz](http://www.bitcoin.org/download/bitcoin-0.3.9.rc2-linux.tar.gz) SHA1 47d9998f7d15fe81234a5c89a542da9d0664df40 bitcoin-0.3.9.rc2-linux.tar.gz Please report back your results [http://BitcoinTalk.org/index.php?topic=820](http://bitcointalk.org/index.php?topic=820) ##### BitcoinTalk #### Re: Not a suggestion ##### _2010-08-13 19:28:47 UTC_ - [-](https://bitcointalk.org/index.php?topic=770.msg9074#msg9074) I'm not grasping your idea yet. Does it hide any information from the public network? What is the advantage? If at least 50% of nodes validated transactions enough that old transactions can be discarded, then everyone saw everything and could keep a record of it. Can public nodes see the values of transactions? Can they see which previous transaction the value came from? If they can, then they know everything. If they can't, then they couldn't verify that the value came from a valid source, so you couldn't take their generated chain as verification of it. Does it hide the bitcoin addresses? Is that it? OK, maybe now I see, if that's it. Crypto may offer a way to do "key blinding". I did some research and it was obscure, but there may be something there. "group signatures" may be related. There's something here in the general area: [http://www.users.zetnet.co.uk/hopwood/crypto/rh/](http://www.users.zetnet.co.uk/hopwood/crypto/rh/) What we need is a way to generate additional blinded variations of a public key. The blinded variations would have the same properties as the root public key, such that the private key could generate a signature for any one of them. Others could not tell if a blinded key is related to the root key, or other blinded keys from the same root key. These are the properties of blinding. Blinding, in a nutshell, is x = (x * large_random_int) mod m. When paying to a bitcoin address, you would generate a new blinded key for each use. Then you need to be able to sign a signature such that you can't tell that two signatures came from the same private key. I'm not sure if always signing a different blinded public key would already give you this property. If not, I think that's where group signatures comes in. With group signatures, it is possible for something to be signed but not know who signed it. As an example, say some unpopular military attack has to be ordered, but nobody wants to go down in history as the one who ordered it. If 10 leaders have private keys, one of them could sign the order and you wouldn't know who did it. ##### BitcoinTalk #### Re: Proposed change to sendtoaddress API call ##### _2010-08-13 23:39:14 UTC_ - [-](https://bitcointalk.org/index.php?topic=807.msg9134#msg9134) It's too soon to start junking up the API for backward compatibility at all costs. Just return "<txid>". ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-14 00:49:18 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg9145#msg9145) MinGW on Windows has trouble compiling it: g++ -c -mthreads -O2 -w -Wno-invalid-offsetof -Wformat -g -D__WXDEBUG__ -DWIN32 -D__WXMSW__ -D_WINDOWS -DNOPCH -I"/boost" -I"/db/build_unix" -I"/openssl/include" -I"/wxwidgets/lib/gcc_lib/mswud" -I"/wxwidgets/include" -msse2 -O3 -o obj/sha256.o sha256.cpp sha256.cpp: In function `long long int __vector__ Ch(long long int __vector__, long long int __vector__, long long int __vector__)': sha256.cpp:31: internal compiler error: in perform_integral_promotions, at cp/typeck.c:1454 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.mingw.org/bugs.shtml> for instructions. make: *** [obj/sha256.o] Error 1 ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-14 04:22:29 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg9159#msg9159) If you haven't already, try aligning thash. It might matter. Couldn't hurt. [_**Quote from: tcatm on August 14, 2010, 12:53:07 AM**_](https://bitcointalk.org/index.php?topic=648.msg9147#msg9147) _Looks like we're triggering a compiler bug in the tree optimizer. Can you try to compile it -O0?_ No help from -O0, same error. MinGW is GCC 3.4.5. Probably the problem. I'll see if I can get a newer version of MinGW. ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-14 17:55:37 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg9228#msg9228) Got the test working on 32-bit with MinGW GCC 4.5. Exactly 50% slower than stock with Core 2. ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-14 22:06:13 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg9278#msg9278) MinGW GCC 4.5.0: Crypto++ doesn't work, X86_SHA256_HashBlocks() never returns I only got 4-way working with test.cpp but not when called by BitcoinMiner MinGW GCC 4.4.1: Crypto++ works 4-way SIGSEGV GCC is definitely not aligning __m128i. Even if we align our own __m128i variables, the compiler may decide to use a __m128i behind the scenes as a temporary variable. By making our __m128i variables aligned and changing these inlines to defines, I was able to get it to work on 4.4.1 with -O0 only: #define Ch(b, c, d) ((b & c) ^ (~b & d)) #define Maj(b, c, d) ((b & c) ^ (b & d) ^ (c & d)) #define ROTR(x, n) (_mm_srli_epi32(x, n) | _mm_slli_epi32(x, 32 - n)) #define SHR(x, n) _mm_srli_epi32(x, n) But that's with -O0. ##### BitcoinTalk #### Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 ##### _2010-08-15 03:40:29 UTC_ - [-](https://bitcointalk.org/index.php?topic=648.msg9359#msg9359) 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) ##### BitcoinTalk #### tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10 ##### _2010-08-15 15:52:09 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg9452#msg9452) 0.3.10 has tcatm's 4-way SSE2 as an option switch. Use the switch "-4way" to turn it on. Without the switch you get Crypto++ ASM SHA-256. I could only get this working with Linux. Download: Get 0.3.10 from [http://BitcoinTalk.org/index.php?topic=827.0](http://bitcointalk.org/index.php?topic=827.0) Please report back your CPU and results! I think it's pretty clear that Core 2 and lower are slower, i5 faster. I don't think we've heard any i7 results yet. We need to know about the different models of AMD or other less common CPUs. ##### BitcoinTalk #### Re: Potential disaster scenario ##### _2010-08-15 16:37:16 UTC_ - [-](https://bitcointalk.org/index.php?topic=813.msg9454#msg9454) Some places where generation will gravitate to: 1) places where it's cheapest or free 2) people who want to help for idealogical reasons 3) people who want to get some coins without the inconvenience of doing a transaction to buy them There are legitimate places where it's free. Generation is basically free anywhere that has electric heat, since your computer's heat is offsetting your baseboard electric heating. Many small flats have electric heat out of convenience. How expensive is heating oil? With the price of oil so high, if it's actually more expensive than electric, then generating would have negative cost. There's also kids putting it on their parent's power bill, employees their employer, botnets, etc. Case 3 comes into play for small amounts. The overhead of doing an exchange doesn't make sense if you just need a small bit of pocket change for incidental micropayments. I think this is a nice advantage vs fiat currency, instead of all the seigniorage going to one big entity, let it go in convenience amounts to people who need to scrape up a small amount of change. ##### BitcoinTalk #### Re: Version 0.3.9 rc1, please test ##### _2010-08-15 18:11:41 UTC_ - [-](https://bitcointalk.org/index.php?topic=806.msg9475#msg9475) [_**Quote from: jgarzik on August 15, 2010, 05:46:27 PM**_](https://bitcointalk.org/index.php?topic=806.msg9467#msg9467) _the extended-help might have been based on my idea, but the code was somewhat different._ The idea was the main part. When you posted your patch, I realized it should have been done that way instead of "-?". I always had reservations about "-?" because it intrudes on the possible parameter values, and the help response is based on the version of the caller instead of the server. ##### BitcoinTalk #### Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2 ##### _2010-08-15 18:23:26 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg9478#msg9478) I hope someone can test an i5 or AMD to check that I built it right. I don't have either to test with. I'm also curious if it performs much worse on 32-bit linux vs 64-bit. ##### BitcoinTalk #### Re: tcatm's 4-way SSE2 for Linux 32/64-bit 0.3.9 rc2 ##### _2010-08-15 18:43:27 UTC_ - [-](https://bitcointalk.org/index.php?topic=820.msg9483#msg9483) I just uploaded a quick build so testers can check if I built it right. (I don't have an i5 or AMD) If it checks out, I'll put together the full package and do all the release stuff. **bitcoin-list** [**bitcoin-list**] ALERT - we are investigating a problem _2010-08-15 20:38:33 UTC_ - [-](https://sourceforge.net/p/bitcoin/mailman/message/25954806/) *** WARNING *** We are investigating a problem. DO NOT TRUST ANY TRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638) until the issue is resolved. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-15 20:59:09 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9530#msg9530) Here's the preliminary change. Look right? I have more changes to make, this isn't all of it. Will SVN shortly. **Code:** bool CheckTransaction() const { // Basic checks that don't depend on any context if (vin.empty() || vout.empty()) return error("CTransaction::CheckTransaction() : vin or vout empty"); // Check for negative and overflow values int64 nTotal = 0; foreach(const CTxOut& txout, vout) { if (txout.nValue < 0) return error("CTransaction::CheckTransaction() : txout.nValue negative"); if (txout.nValue > 21000000 * COIN) return error("CTransaction::CheckTransaction() : txout.nValue too high"); nTotal += txout.nValue; if (nTotal > 21000000 * COIN) return error("CTransaction::CheckTransaction() : txout total too high"); } if (IsCoinBase()) { if (vin[0].scriptSig.size() < 2 || vin[0].scriptSig.size() > 100) return error("CTransaction::CheckTransaction() : coinbase script size"); } else { foreach(const CTxIn& txin, vin) if (txin.prevout.IsNull()) return error("CTransaction::CheckTransaction() : prevout is null"); } return true; } Don't sticky the topic, nobody looks up there. There'll be enough posts to bump. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-15 21:06:45 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9531#msg9531) It would help if people stop generating. We will probably need to re-do a branch around the current one, and the less you generate the faster that will be. A first patch will be in SVN rev 132. It's not uploaded yet. I'm pushing some other misc changes out of the way first, then I'll upload the patch for this. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-15 21:23:55 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9539#msg9539) Once you have an update, you could download knightmb's block chain. You'll want one that's old enough that it ends _before_ block 74000 so the most recent security lockin will check it. Can someone find the link for that? **Martii Malmi (AKA Sirius) “COPA trial” email #231** **Date: Sun, 15 Aug 2010 21:37:28 +0100** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: [bitcoin-list] ALERT - we are investigating a problem** **To: bitcoin-list@lists.sourceforge.net** *** WARNING *** We are investigating a problem. DO NOT TRUST ANY TRANSACTIONS THAT HAPPENED AFTER 15.08.2010 17:05 UTC (block 74638) until the issue is resolved. ##### BitcoinTalk #### Re: overflow bug SERIOUS ##### _2010-08-15 21:40:19 UTC_ - [-](https://bitcointalk.org/index.php?topic=823.msg9548#msg9548) Patch is uploaded to SVN rev 132! For now, recommended steps: 1) Shut down. 2) Download knightmb's blk files. (replace your blk0001.dat and blkindex.dat files) 3) Upgrade. 4) It should start out with less than 74000 blocks. Let it redownload the rest. If you don't want to use knightmb's files, you could just delete your blk*.dat files, but it's going to be a lot of load on the network if everyone is downloading the whole block index at once. I'll build releases shortly. ----

msg8114msg7889msg8137msg7723msg8140msg8145msg7838msg8388ifdefmsg8402msg8413msg8417msg8422ifdefineendifmsg8424msg8431msg8628msg8637msg8649msg8566msg8585msg8651228msg8798230msg8803msg8657msg8795msg8804msg8761msg8810msg8814msg8807endif__endif_includemsg8836msg8824msg8919ifndefmsg8920msg8922msg8924msg8929msg8960msg9041msg9046msg9074msg9134msg9145msg9159msg9147msg9228msg9278msg9359msg9452msg9454msg9475msg9467msg9478msg9483msg9530msg9531msg9539231msg9548

Kicking the Hornet's Nest - part 10

# Kicking the Hornet's Nest - third edition - part 10 All links, digital (pdf, txt, docx, md) and book in print, can be found at https://hive.blog/@crrdlx/satoshi Edited by [crrdlx](nostr:nprofile1qyv8wumn8ghj7mn0wdj8y6tkv5hxzurs9aex2mrp0yq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqzqqzmcn0yrn7ttq8hrjkk46ysn2tk26rr8f8k4y7xkl74hlh3rcdzm9d3t8), npub: ``` npub1qpdufhjpel94srm3ett2azgf49m9dp3n5nm2j0rt0l2mlmc3ux3qza082j ``` ---- ### Kicking the Hornet's Nest pages 200 - 225 ---- **Martii Malmi (AKA Sirius) “COPA trial” email #131** **Date: Wed, 16 Dec 2009 16:54:46 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Planned release announcement text** **To: Martti Malmi <mmalmi@cc.hut.fi>** Here's the planned release announcement text. Probably releasing shortly. Bitcoin version 0.2 is here! Download links: Windows Setup Program Windows Zip File Linux (tested on Ubuntu) New features Martti Malmi - Minimize to system tray option - Autostart on boot option so you can keep it running in the background automatically - New options dialog layout for future expansion - Setup program for Windows - Linux version Satoshi Nakamoto - Multi-processor support for coin generation - Proxy support for use with TOR - Fixed some slowdowns in the initial block download - Various refinements to keep the network running smoothly We also have a new forum at http://www.bitcoin.org/smf/ if you have any questions. Thanks to Martti Malmi (sirius-m) for his coding work and for hosting the new site and forum, and thanks to New Liberty Standard for testing the Linux version. Satoshi Nakamoto **BitcoinTalk** Bitcoin 0.2 released! _2009-12-16 22:45:36 UTC_ - [-](https://bitcointalk.org/index.php?topic=16.msg73#msg73) Bitcoin version 0.2 is here! Download links: [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32-setup.exe/download](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32-setup.exe/download) [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32.zip/download](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-win32.zip/download) [http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download](http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.2.0-linux.tar.gz/download) New Features Martti Malmi - Minimize to system tray option - Autostart on boot option so you can keep it running in the background automatically - New options dialog layout for future expansion - Setup program for Windows - Linux version (tested on Ubuntu) Satoshi Nakamoto - Multi-processor support for coin generation - Proxy support for use with TOR - Fixed some slowdowns in the initial block download Major thanks to Martti Malmi (sirius-m) for all his coding work and for hosting the new site and this forum, and New Liberty Standard for his help with testing the Linux version. **Martii Malmi (AKA Sirius) “COPA trial” email #132** **Date: Thu, 17 Dec 2009 06:49:02 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: [bitcoin-list] Bitcoin 0.2 released** **To: bitcoin-list@lists.sourceforge.net** Bitcoin 0.2 is here! Download (Windows, and now Linux version available) http://sourceforge.net/projects/bitcoin/files/ New Features Martti Malmi - Minimize to system tray option - Autostart on boot option so you can keep it running in the background automatically - New options dialog layout for future expansion - Setup program for Windows - Linux version (tested on Ubuntu) Satoshi Nakamoto - Multi-processor support for coin generation - Proxy support for use with TOR - Fixed some slowdowns in the initial block download We also have a new forum at http://www.bitcoin.org/smf/ Many thanks to Martti (sirius-m) for all his development work, and to New Liberty Standard for his help with testing the Linux version. Satoshi Nakamoto **bitcoin-list** [**bitcoin-list**] Bitcoin 0.2 released _2009-12-17 06:52:09 UTC_ - [-](https://sourceforge.net/p/bitcoin/mailman/message/24205662/) Bitcoin 0.2 is here! Download (Windows, and now Linux version available) http://sourceforge.net/projects/bitcoin/files/ New Features Martti Malmi - Minimize to system tray option - Autostart on boot option so you can keep it running in the background automatically - New options dialog layout for future expansion - Setup program for Windows - Linux version (tested on Ubuntu) Satoshi Nakamoto - Multi-processor support for coin generation - Proxy support for use with TOR - Fixed some slowdowns in the initial block download We also have a new forum at http://www.bitcoin.org/smf/ Many thanks to Martti (sirius-m) for all his development work, and to New Liberty Standard for his help with testing the Linux version. Satoshi Nakamoto **BitcoinTalk** Re: A few suggestions _2009-12-17 18:38:06 UTC_ - [-](https://bitcointalk.org/index.php?topic=12.msg77#msg77) That's good, is it running fine on FreeBSD? I committed the changes to headers.h.\u00a0 For consistency, I used __BSD__.\u00a0 The complete list of defines is at [http://docs.wxwidgets.org/stable/wx_cppconst.html](http://docs.wxwidgets.org/stable/wx_cppconst.html) #ifdef __BSD__ #include <netinet/in.h> #endif malloc.h is only needed on windows, I'll move that into the __WXMSW__ section before it causes any more trouble. **BitcoinTalk** Re: A few suggestions _2009-12-18 17:37:48 UTC_ - [-](https://bitcointalk.org/index.php?topic=12.msg79#msg79) What you can currently do is set "Minimize to the tray" in options, then run it as "bitcoin -min" so it starts minimized. \u00a0The only visible part will be a small (20x20) icon on the tray, which can be doubleclicked if you want to access the UI. \u00a0Note: 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. \u00a0I figured Linux people wouldn't mind doing that manually anyway. \u00a0I 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. \u00a0I know someone is already doing that to put it on a TrueCrypt USB drive. **Martii Malmi (AKA Sirius) “COPA trial” email #134** **Date: Tue, 22 Dec 2009 19:00:41 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin stuff** **To: mmalmi@cc.hut.fi** Thanks for creating the maintenance account, it would have been impossible to do all that without it. I'm really always going to need it. OK, I changed the password to a 20 character random password. That's a good domain. People rarely type domain names anymore, they use autocomplete or click links on search engines. I need to make a way for you to programmatically get new generated bitcoin addresses. Either that or you could have them send to your IP address, but then you have to rely on them to put the order number in the comment. When generating the new address, there can be an option to add an entry to the address book associated with the address, so the received transaction will be labelled. I kinda hid the labels after early users found them confusing, but it would be very helpful for this application. You have to widen up the comment column to see them. Are you going to manually review and enter orders, at least to begin with? I sure would. I'm thinking I should move the UI in the direction of having the user ask for their bitcoin address when they want one. "give me a bitcoin to receive a payment with". I suppose next to the send button, there would by a receive button, you press it and it says "here's a new address to use, here's the button to copy it to the clipboard, do you want to label it?" and maybe some explanation about why you shouldn't reuse addresses. Or maybe just a "New Address" button next to the address box that you should hit each time to change it. _mmalmi@cc.hut.fi wrote:_ _> I have registered the domain name bitcoinexchange.com and will start_ _> coding the service sometime soon as a nice leisure activity. I'm_ _> envisioning a simple Google-like interface with no registration and only_ _> two texts fields on the front page, where you insert the amount of money_ _> you wish to trade, and either your PayPal address to buy dollars or_ _> bitcoin address to buy bitcoins. On the next page you'll get a new_ _> bitcoin address for sending the coins or a check code for the PayPal_ _> transaction text._ _>_ _> PayPal is good for the beginning - it's simple and has no startup costs,_ _> but later on I might accept credit cards also._ _>_ _> Do you still need the maintenance account? It's ok if you do, but change_ _> the password to something else._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #136** **Date: Wed, 23 Dec 2009 17:53:18 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin stuff** **To: mmalmi@cc.hut.fi** _mmalmi@cc.hut.fi wrote:_ _> I'd also need at least the command line tools to check if coins have_ _> been received and to send coins. It would require some way to_ _> communicate with the Bitcoin process running in the background. I don't_ _> know how that should be done, maybe with something RPC related._ _>_ _> It would also be great if the background process was non-graphical - the_ _> VPS on the current service level doesn't have enough memory to run the X_ _> Windowing environment, unless I come up with some ways to free memory._ I had been wondering why everyone keeps harping on no-UI, when already you can run it with only a small icon on the tray, which is common for server services on Windows. So I guess this is why. I had chalked it up to unix snobbery if they couldn't abide a tiny little icon on a desktop they never see. Not opening any windows is easy, but it may fail because the gtk libraries aren't there. wxWidgets has __WXBASE__ for "Only wxBase, no GUI features". You could try building for that instead of __WXGTK__ and see what happens. It would be preferable if there's any way to do it as a command line switch on the same executable, rather than yet another build variation to release. How much memory do you have to work with? Bitcoin necessarily takes a fair bit of memory; about 75MB on Windows. Is that a problem? Command line control is one of the next things on the list. I want to design the API carefully. Receiving payments is the part that has a lot of design choices to be made. The caller needs to identify the transactions of interest, that's where the one-bitcoin-address-per-transaction model helps. Searching the comments text for an order number is another possibility. There's polled, asking what has been received to the given bitcoin address, and event driven. I guess in event driven, bitcoin would be told to run a command line when a certain amount is received to a certain bitcoin address. **Martii Malmi (AKA Sirius) “COPA trial” email #138** **Date: Fri, 25 Dec 2009 16:11:14 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin stuff** **To: mmalmi@cc.hut.fi** You're right, I was looking at a test run with 250,000 blocks... duh. A normal one shows 17MB memory usage and 10MB VM size. _mmalmi@cc.hut.fi wrote:_ _>> How much memory do you have to work with?_ _> The VPS has 320MB RAM, 50MB of which is currently free. There's also_ _> 500MB swap space._ _>_ _>> Bitcoin necessarily takes a_ _>> fair bit of memory; about 75MB on Windows. Is that a problem?_ _>_ _> Sure about that? Windows task manager shows about 13MB memory usage here._ _>_ **BitcoinTalk** Re: Is my second Transaction working correctly? +Transfer Question _2010-01-05 20:00:46 UTC_ - [-](https://bitcointalk.org/index.php?topic=17.msg85#msg85) The transfer is immediate if you send by IP address. If you send by bitcoin address and the recipient isn't online at the time, it might take 30 minutes or more to see it. Also, the recipient needs to be synced up with the block chain before it'll see the received transaction. That means the status bar at the bottom needs to say at least 33000 blocks, like "x connections 33200 blocks x transactions". [_**Quote from: sirius-m on January 05, 2010, 01:20:06 AM**_](https://bitcointalk.org/index.php?topic=17.msg84#msg84) _**Quote**_ _However, once that transaction was complete, a new transaction hasn't started. Or maybe it has. There's only one transaction in the list but I'm up to 131 Blocks under "Status". Is this the way it's supposed to happen? Does it keep processing on the same transaction and generating coins every 120 blocks or so? Or is it supposed to start a new transaction?_ _ The number of blocks of a transaction is the amount of new blocks that have been generated by the whole network after the transaction. Each new block in the chain means new coins to its creator. One "generated" -transaction in your transaction list means that you have generated one block. You're not the first one to find the concept of a "block" a bit confusing on the first sight._ Would it be clearer if the status said "x confirmations", like: 2/unconfirmed 3/unconfirmed 4/unconfirmed 5/unconfirmed 6 confirmations 7 confirmations 8 confirmations Each block essentially means another node has confirmed that it agrees with all transactions up to that point. **BitcoinTalk** Re: 64bit support _2010-01-14 20:17:20 UTC_ - [-](https://bitcointalk.org/index.php?topic=18.msg97#msg97) 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. **BitcoinTalk** Re: Number of connections? _2010-01-20 20:07:15 UTC_ - [-](https://bitcointalk.org/index.php?topic=21.msg112#msg112) 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. **BitcoinTalk** Re: TOR and I2P _2010-01-20 22:05:28 UTC_ - [-](https://bitcointalk.org/index.php?topic=22.msg113#msg113) 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. **BitcoinTalk** Re: Bitcoin crash when sending coins _2010-01-27 21:52:27 UTC_ - [-](https://bitcointalk.org/index.php?topic=27.msg156#msg156) 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. **BitcoinTalk** Re: A newb's test - anyone want to buy a picture for $1? _2010-01-28 01:01:48 UTC_ - [-](https://bitcointalk.org/index.php?topic=25.msg159#msg159) 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. **BitcoinTalk** Re: 64bit support _2010-01-29 00:42:49 UTC_ - [-](https://bitcointalk.org/index.php?topic=18.msg174#msg174) I committed a fix for 64-bit compile and some fixes to support wxWidgets 2.9.0. There was one compile error in serialize.h with min(sizeof()) that I fixed for 64-bit. The rest of the 64-bit compile errors I was getting were in wxWidgets 2.8.9, so I started working on supporting wxWidgets 2.9.0. wxWidgets 2.9.0 is UTF-8. We've been using the ANSI version of wxWidgets 2.8.9 in anticipation of wxWidgets UTF-8 support. I compiled and ran on 64-bit Ubuntu 9.10 Karmic. I think the only bug left is where the status number is mashed up. I'm not sure why, I have to suspect it's a UTF-8 thing, but no idea how that could happen. Haven't looked into it. build-unix.txt is updated and two makefiles on SVN: makefile.unix.wx2.8 makefile.unix.wx2.9 Unfortunately there's still no debian package for either version of wxWidgets we use. They only have the wchar ("unicode") version of wxWidgets 2.8, which is a disaster because wchar wxString doesn't convert to std::string. We use either ANSI wxWidgets 2.8, or wxWidgets 2.9. So you still have to get it and build it yourself. **Martii Malmi (AKA Sirius) “COPA trial” email #143** _Editor’s note: this email appears timestamped PRIOR to emails #141 and #142, however it was listed AFTER emails #141 and #142 in Martii Malmi’s COPA trial email documents._ **Date: Wed, 03 Feb 2010 20:25:53 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin API** **To: mmalmi@cc.hut.fi** Is there any way to find out what the missing shared libraries are? It would help to know. It probably needs the gtk libraries, in which case you'll have the same problem with the 64-bit version. I would like to have a single executable that can also run on a UI-less system, but I'm not sure how on linux to link to things but still be able to run and not use them if the library is not present. Maybe we should statically link the GTK. Licensewise, it's LGPL, but since it's only used on unix, that would be OK. (we can't link LGPL stuff on windows because we provide the OpenSSL DLL, but on linux OpenSSL comes with the OS) My 64-bit (debug stripped) executable is attached. It includes untested changes that are not in SVN yet: UI changes and the wallet fSpent flag resync stuff. I've been researching options for interprocess calling. I want something that will be easy for a variety of server side languages to call, particularly PHP. Cross-platform to windows is a plus. I'm not sure if I want it to be something that can be accessed across the network. That would introduce security issues. If it can only be accessed on the local system, then local security authentication covers it, and it is incapable of being hacked remotely. At surface level, not looking into any details yet, the current front runners are: D-Bus: local system only used by qt, gnome and skype bindings: c, python, java, c++, php listed as "in progress" .net listed as unmaintained not sure how ready it is on windows XML-RPC: widely used, built in libraries on PHP it's more for web clients to talk to server, transport is http, so its a security question Is it possible to open a socket that can only be accessed locally? _mmalmi@cc.hut.fi wrote:_ _> Have you decided upon the inter-process calling method of the Bitcoin_ _> API yet? An easy solution would be the socket interface provided by_ _> wxWidgets: http://docs.wxwidgets.org/trunk/overview_ipc.html. The_ _> Bitcoin program running a wxServer could be then accessed by calling the_ _> bitcoin executable from the command line or by coding your own wxClient_ _> app._ _>_ _> Another option would be to just use the plain BSD sockets._ _>_ _> Can you send me a 64-bit Linux binary of Bitcoin if you have one? I_ _> tried compiling on the VPS, but it ran out of memory. Tried the 32-bit_ _> version (with ia32-libs) also, but it didn't find the shared libraries._ _>_ **BitcoinTalk** Re: Bitcoin crash when sending coins _2010-02-03 23:29:57 UTC_ - [-](https://bitcointalk.org/index.php?topic=27.msg219#msg219) I uploaded this fix to the SVN. It watches for spent coins and updates your wallet on load and also continuously as blocks come in. I also put a better error message, but it should never hit it because it always finds spent coins ahead of time, unless you spent the same money at the same time on two computers at once. If you want to try it, PM or e-mail me your e-mail address where I can send it as an attachment and also what OS (win, linux 32-bit, linux 64-bit). **BitcoinTalk** Re: Win32 CPU Cycles vs 'Live Protection' Engines ? _2010-02-03 23:36:54 UTC_ - [-](https://bitcointalk.org/index.php?topic=35.msg220#msg220) Thanks for that. Which version of Windows? **BitcoinTalk** Re: Questions about Addresses _2010-02-04 00:07:07 UTC_ - [-](https://bitcointalk.org/index.php?topic=34.msg222#msg222) Port forwarding forwards a port to one computer. It tells the router which computer handles connections to that port. So that's the computer receiving. If you didn't set up port forwarding, then incoming connections won't go to any computer, and attempts to send to that IP would just say it couldn't connect to the recipient and nothing is sent. When sending by IP, you still send to a bitcoin address, but your computer connects to that IP, gets a new bitcoin address from it, gives the transaction directly to the them and confirms that it was received and accepted. Someone should post their static IP so people can try out sending by IP and also give that user free money. There's a 32-bit checksum in bitcoin addresses so you can't accidentally type an invalid address. If 4) you send to a recipient who has abandoned or lost their wallet.dat, then the money is lost. A subtle point can be made that since there is then less total money in circulation, everyone's remaining money is worth slightly more, aka "natural deflation". **BitcoinTalk** Re: TOR and I2P _2010-02-04 00:30:50 UTC_ - [-](https://bitcointalk.org/index.php?topic=22.msg223#msg223) When using proxy port 9050, it will only make one attempt to connect to IRC, then give up, since it knows it will probably always fail because IRC servers ban all the TOR exit nodes. If you're using another port, it would assume it might be a regular old normal proxy and would keep retrying IRC at longer and longer intervals. You should not use Polipo or Privoxy as those are http filters and caches that would corrupt Bitcoin's messages if they make any changes. Bitcoin might be trying to overcome it by reconnecting. You should use port 9050. As riX says, the "is giving Tor only an IP address. Apps that do DNS..." warnings are nothing to worry about. Bitcoin doesn't use DNS at all in proxy mode. Since Bitcoin can't get through to IRC through Tor, it doesn't know which nodes are currently online, so it has to try all the recently seen nodes. It tries to conserve connection attempts as much as possible, but also people want it to connect quickly when they start it up and reconnect quickly if disconnected. It uses an algorithm where it tries an IP less and less frequently the longer ago it was successful connected. For example, for a node it saw 24 hours ago, it would wait 5 hours between connection attempts. Once it has at least 2 connections, it won't try anything over a week old, and 5 connections it won't try anything over 24 hours old. **Martii Malmi (AKA Sirius) “COPA trial” email #142** _Editor’s note: this email appears timestamped PRIOR to email #141, however it was listed AFTER email #141 in Martii Malmi’s COPA trial email documents._ **Date: Thu, 04 Feb 2010 01:32:50 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Exchange options** **To: Martti Malmi <mmalmi@cc.hut.fi>** Don't rush ahead and get yourself rejected from all the payment options before you've had time to see if there's a better approach. I suggest you wait before contacting any more payment processors. You may get ideas from things other users come up with and try. Just some random incomplete ideas: There may be a way to position it as an intermediate credit for micropayments for some virtual good or something. Or maybe if the payments are only in one direction. If you only buy bitcoins, then you're only sending money out not taking people's money, that would still be useful to peg the currency. That might be payment for computer time. Credit card is only one way. Don't even talk about the idea of returning money to customer's credit cards. Credit card companies hate that. In any case, any payment processor is going to expect you to be selling something real. Do you have electronic transfer or paper cheque in your country? (even if only within Europe) **Martii Malmi (AKA Sirius) “COPA trial” email #141** **Date: Thu, 04 Feb 2010 02:20:10 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Exchange ideas** **To: Martti Malmi <mmalmi@cc.hut.fi>** You could always exchange for Liberty Reserve. It's an online currency similar to e-Bullion, Pecunix or Webmoney that allows exchanges no questions asked and with privacy. LR and the others are hard to buy but easy to cash out. Hard to buy because exchangers are very cautious about getting ripped off by reversed payments, so they require more details and holding time. Cashing out is very easy. LR is non-reversible, so there are oodles of exchanges eager to turn LR into any kind of payment. Bitcoin is the reverse, in that it's easy to get Bitcoins just by generating them. It would be easy for customers to go bitcoin->LR->cash, bitcoin->LR->gold, bitcoin->LR->paypal or maybe they just want to save the money, then just bitcoin->LR. There's also the idea BTC2PSC had to sell paysafecards for bitcoins. Either online delivery by sending the card number by e-mail, or delivery of the unopened physical card in the mails. There are many variations of these cards. In some countries, they're called Gift Cards, and can be used wherever credit cards are accepted. I think they're used more by people who don't have the credit history to get a real credit card, so they buy gift cards themselves to pay for things that require a credit card. **Martii Malmi (AKA Sirius) “COPA trial” email #145** **Date: Thu, 04 Feb 2010 18:50:35 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin API** **To: mmalmi@cc.hut.fi** I must have accidentally typed j instead of z. It's bz2 format. Rename to .tar.bz2 or just do tar -jxvf _> The package doesn't open, it says "not in gzip format"._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #146** **Date: Thu, 04 Feb 2010 19:33:26 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: UTF-8 to ANSI hack in CAboutDialog** **To: Martti Malmi <mmalmi@cc.hut.fi>** What was the reason for this change? #if !wxUSE_UNICODE ... if (str.Find('Â') != wxNOT_FOUND) str.Remove(str.Find('Â'), 1); to: if (str.Find('�') != wxNOT_FOUND) str.Remove(str.Find('�'), 1); wxFormBuilder turns the (c) symbol into UTF-8 automatically. On wxWidgets-2.8.9 ansi, it shows as a copyright symbol with an extra trash character, which this hack fixes up for the non-unicode (ansi) case. **Martii Malmi (AKA Sirius) “COPA trial” email #147** Date: Thu, 04 Feb 2010 19:59:48 +0000 From: Satoshi Nakamoto <satoshin@gmx.com> Subject: Re: Bitcoin API To: mmalmi@cc.hut.fi Good, then no need to consider d-bus. Is there something like IPC sockets on Windows? I guess we could look how wx does it, or maybe the XML-RPC library will already know what to do. Windows has named pipes, maybe that's the best analogue. I don't think I want to invent my own RPC protocol, I want to use an existing standard. PHP, Java, Python or anything will be able to talk to the server directly the same way the command line commands do. I'm going to start reading on XML-RPC. It's coming up in searches as the most widely used protocol and widely supported. PHP includes it in its standard libraries. _>> Is it possible to open a socket that can only be accessed locally?_ _>_ _> Yes, you can use IPC sockets ("Unix domain sockets") which are local_ _> only. That's done in the wx-api by using a filename in place of a port_ _> number. I committed an example of how the wxServer-Client communication_ _> is used, you can revert if you want to. Now there's the -blockamount_ _> command line option which asks the running instance for the block chain_ _> length._ _>_ _> I think this command line method could already be used from PHP, but it_ _> might be lighter if php itself could call the socket server directly._ _> The wx's IPC overview mentions wxSocketEvent, wxSocketBase,_ _> wxSocketClient and wxSocketServer as being "Classes for the low-level_ _> TCP/IP API", which might be easier to use from php than what I used now_ _> (wxServer, wxClient, wxConnection). I'll look more into it._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #148** **Date: Fri, 05 Feb 2010 04:08:54 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Bitcoin API research status** **To: Martti Malmi <mmalmi@cc.hut.fi>** I noticed this in the docs for wxSocketServer::Accept(bool wait = true): "If wait is true and there are no pending connections to be accepted, it will wait for the next incoming connection to arrive. **Warning: This will block the GUI." wxWidgets is pathologically single-threaded. Not only single-threaded, but must-be-the-GUI-thread-ed. Even for something as non-UI as wxStandardPaths I got nailed. All this is fine for UI code, since this is the same constraint placed by Windows anyway, but for UI-less server daemon code, wx calls are uncertain. Status of my research currently: For PHP, Python, etc to access the server, we need to use regular sockets. I think we can make it local-only by binding to localhost only, so it can only be accessed through the loopback. They say it's also watertight to simply check the IP of connections received and disconnect anything not 127.0.0.1. May as well do both. XML-RPC is a bit fat. There are 4 libraries for C++ but they're all big and hard to build, dependencies, license issues. Some posters complain all the C++ and PHP XML-RPC libraries are buggy. JSON-RPC is a simpler more elegant standard. It's simple enough I could use a generic JSON parser. PHP, Python and Java all have good implementations of JSON-RPC. I'm currently leaning towards JSON-RPC. **Martii Malmi (AKA Sirius) “COPA trial” email #151** **Date: Fri, 05 Feb 2010 18:29:12 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: Exchange options** **To: mmalmi@cc.hut.fi** Maybe the current difficulty of buying LR is already the limit of how easy it can get in that direction. Every conventional payment method has refutability as their way to cope with their lack of passwords and crypto. The system is wide open to copying plaintext credit card numbers and account numbers, and they deal with it by reversing the transaction after the fact. The system works for physical goods that have to be delivered somewhere, and services which can't be resold. It's a problem when it interfaces with precious metals and currency conversion. The first step of being easy in one direction, bitcoin->LR or anything of established value, goes a long way. Even those who don't use the conversion still benefit from knowing that they could. Trading bitcoin becomes an easier way to trade the ability to claim LR, similar to how paper money was once the right to claim gold. Nobody has to ever actually claim the LR to get the benefit of having the option that they could if they wanted to. A lot of times you just need a minuscule amount of online currency. The hassle of buying the other online currencies is too much for buying a small amount. The ease of getting a small amount of bitcoin may help bootstrap an ecosystem of sellers of micropayment sized online goods selling to that market. If the sellers can get LR for bitcoins, they're happy, and that may be subsidized at first by investors who want to buy bc in large lots. The main thing holding online currencies back is the lack of an easy way to get a small amount of currency. Bitcoin opens that up. It'll be the only online currency that's both easy to cash out and easy to get a small amount. It'll just be the usual harder difficulty to buy a large amount. _mmalmi@cc.hut.fi wrote:_ _> Liberty Reserve sounds good. I could first make a service that only_ _> accepts LR, and add more options later. The weakness is that buying LR_ _> is an extra step of inconvenience when the customer just wants to get_ _> Bitcoins. But maybe I don't have too much choice here._ _>_ _>> Do you have electronic transfer or paper cheque in your country? (even_ _>> if only within Europe)_ _>_ _> Yes, electronic bank transfer is available. During 2010 most European_ _> countries will become a part of SEPA (Single Euro Payments Area), which_ _> means that all payments within Europe are to be considered domestic._ _> Banks will have to apply the same fees and standards to all domestic_ _> transfers, so they'll probably all be free of charge and complete in one_ _> bank day. For international transfers there's the SWIFT/IBAN system,_ _> which usually costs some extra._ _>_ _> A longer term project for my exchange service would be to see what kinds_ _> of integration options the banks have to offer. Bank transfers would_ _> reach nearly as many customers as credit cards do._ _>_ **Martii Malmi (AKA Sirius) “COPA trial” email #152** **Date: Fri, 05 Feb 2010 18:39:18 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Re: UTF-8 to ANSI hack in CAboutDialog** **To: mmalmi@cc.hut.fi** Right, I'll change it to this so it doesn't get broken again: if (str.Find('\xC2') != wxNOT_FOUND) str.Remove(str.Find('\xC2'), 1); _mmalmi@cc.hut.fi wrote:_ _> I didn't change it knowingly, must have been some encoding problem._ _>_ _>> What was the reason for this change?_ _>>_ _>> #if !wxUSE_UNICODE_ _>> ..._ _>> if (str.Find('Â') != wxNOT_FOUND)_ _>> str.Remove(str.Find('Â'), 1);_ _>> to:_ _>> if (str.Find('�') != wxNOT_FOUND)_ _>> str.Remove(str.Find('�'), 1);_ _>>_ _>> wxFormBuilder turns the (c) symbol into UTF-8 automatically. On_ _>> wxWidgets-2.8.9 ansi, it shows as a copyright symbol with an extra_ _>> trash character, which this hack fixes up for the non-unicode (ansi)_ _>> case._ _>_ **BitcoinTalk** Proof-of-work difficulty increasing _2010-02-05 19:19:12 UTC_ - [-](https://bitcointalk.org/index.php?topic=43.msg249#msg249) We had our first automatic adjustment of the proof-of-work difficulty on 30 Dec 2009. The minimum difficulty is 32 zero bits, so even if only one person was running a node, the difficulty doesn't get any easier than that. For most of last year, we were hovering below the minimum. On 30 Dec we broke above it and the algorithm adjusted to more difficulty. It's been getting more difficult at each adjustment since then. The adjustment on 04 Feb took it up from 1.34 times last year's difficulty to 1.82 times more difficult than last year. That means you generate only 55% as many coins for the same amount of work. The difficulty adjusts proportionally to the total effort across the network. If the number of nodes doubles, the difficulty will also double, returning the total generated to the target rate. For those technically inclined, the proof-of-work difficulty can be seen by searching on "target:" in debug.log. It's a 256-bit unsigned hex number, which the SHA-256 value has to be less than to successfully generate a block. It gets adjusted every 2016 blocks, typically two weeks. That's when it prints "GetNextWorkRequired RETARGET" in debug.log. minimum 00000000ffff0000000000000000000000000000000000000000000000000000 30/12/2009 00000000d86a0000000000000000000000000000000000000000000000000000 11/01/2010 00000000c4280000000000000000000000000000000000000000000000000000 25/01/2010 00000000be710000000000000000000000000000000000000000000000000000 04/02/2010 000000008cc30000000000000000000000000000000000000000000000000000 14/02/2010 0000000065465700000000000000000000000000000000000000000000000000 24/02/2010 0000000043b3e500000000000000000000000000000000000000000000000000 08/03/2010 00000000387f6f00000000000000000000000000000000000000000000000000 21/03/2010 0000000038137500000000000000000000000000000000000000000000000000 01/04/2010 000000002a111500000000000000000000000000000000000000000000000000 12/04/2010 0000000020bca700000000000000000000000000000000000000000000000000 21/04/2010 0000000016546f00000000000000000000000000000000000000000000000000 04/05/2010 0000000013ec5300000000000000000000000000000000000000000000000000 19/05/2010 00000000159c2400000000000000000000000000000000000000000000000000 29/05/2010 000000000f675c00000000000000000000000000000000000000000000000000 11/06/2010 000000000eba6400000000000000000000000000000000000000000000000000 24/06/2010 000000000d314200000000000000000000000000000000000000000000000000 06/07/2010 000000000ae49300000000000000000000000000000000000000000000000000 13/07/2010 0000000005a3f400000000000000000000000000000000000000000000000000 16/07/2010 000000000168fd00000000000000000000000000000000000000000000000000 27/07/2010 00000000010c5a00000000000000000000000000000000000000000000000000 05/08/2010 0000000000ba1800000000000000000000000000000000000000000000000000 15/08/2010 0000000000800e00000000000000000000000000000000000000000000000000 26/08/2010 0000000000692000000000000000000000000000000000000000000000000000 date, difficulty factor, % change 2009 1.00 30/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% 05/08/2010 352.17 +44% 15/08/2010 511.77 +45% 26/08/2010 623.39 +22% **BitcoinTalk** Re: Questions about Addresses _2010-02-05 19:44:46 UTC_ - [-](https://bitcointalk.org/index.php?topic=34.msg250#msg250) [_**Quote from: Sabunir on February 05, 2010, 05:31:30 PM**_](https://bitcointalk.org/index.php?topic=34.msg246#msg246) _Perhaps there should be a feature against this? For instance, if a transaction isn't accepted by the recipient for a long period of time (a month?), the transaction will be canceled and the coins returned to the one who sent them?_ That's not possible. You've handed control of the money over to the recipient's keypair. Only that key can control it. It's similar to if you encrypt a file with AES and a strong password, and you lose the password. The data is lost. **BitcoinTalk** Re: Repost: Request: Make this anonymous? _2010-02-06 21:06:32 UTC_ - [-](https://bitcointalk.org/index.php?topic=7.msg264#msg264) When you send to a bitcoin address, you don't connect to the recipient. You send the transaction to the network the same way you relay transactions. There's no distinction between a transaction you originated and one you received from another node that you're relaying in a broadcast. With a very small network though, someone might still figure it out by process of elimination. It'll be better when the network is larger. If you send by IP, the recipient sees you because you connect to their IP. You could use TOR to mask that. You could use TOR if you don't want anyone to know you're even using Bitcoin. Bitcoin is still very new and has not been independently analysed. If you're serious about privacy, TOR is an advisable precaution. **BitcoinTalk** Re: How divisible are bitcoins and other market/economic questions _2010-02-06 23:25:53 UTC_ - [-](https://bitcointalk.org/index.php?topic=44.msg267#msg267) Eventually at most only 21 million coins for 6.8 billion people in the world if it really gets huge. But don't worry, there are another 6 decimal places that aren't shown, for a total of 8 decimal places internally. It shows 1.00 but internally it's 1.00000000. If there's massive deflation in the future, the software could show more decimal places. If it gets tiresome working with small numbers, we could change where the display shows the decimal point. Same amount of money, just different convention for where the ","'s and "."'s go. e.g. moving the decimal place 3 places would mean if you had 1.00000 before, now it shows it as 1,000.00. **Martii Malmi (AKA Sirius) “COPA trial” email #153** **Date: Sun, 07 Feb 2010 06:12:04 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: JSON-RPC status** **To: Martti Malmi <mmalmi@cc.hut.fi>** The JSON-RPC implementation is going well. I'm using boost::asio for sockets. JSON-RPC can be plain socket or HTTP, but it seems most other implementations are HTTP, so I made my own simple HTTP headers. For JSON parsing I'm using JSON Spirit, which makes full use of STL and has been really nice to use. It's header-only so it's no added build work, and small enough to just add it to our source tree. MIT license. This should all be working in a few more days. The forum sure is taking off. I didn't expect to have so much activity so fast. **BitcoinTalk** Re: Make your "we accept Bitcoin" logo _2010-02-08 01:22:29 UTC_ - [-](https://bitcointalk.org/index.php?topic=45.msg278#msg278) No, sorry. I've been meaning to redo it. The largest icon that still looks good is the 20x20 one which is used for the tray icon in GNOME. Any larger than that looks bad. The 16x16 and 20x20 ones have quite a bit of hand tweaking to get the pixels to work out right. If you just scale down a larger image, the pixels end up blurred and awkward in places where the lines in "BC" don't land square on a pixel. The best 16x16 with full alpha channel is in src/rc/bitcoin.ico. I don't like the 32x32 version. I'm attaching bitcoin20x20.png, the 20x20 version with full transparency. **BitcoinTalk** Bitcoin client and website translation _2010-02-08 01:27:02 UTC_ - [-](https://bitcointalk.org/index.php?topic=47.msg279#msg279) Thank you for the offer to help translate. That is probably the best way you could help. I will need to prepare the code for translation first. wxWidgets has locale support, and most strings are in generated code that is already wrapped, so it shouldn't be too hard. We also must finish upgrading to wxWidgets-2.9.0 to get UTF-8 support. I've done test builds with 2.9.0 and there is one bug left to fix. What operating system are you using? Windows, Linux 32-bit or 64 bit? Split from [another thread](https://www.bitcoin.org/smf/index.php?topic=44). sirius-m **Martii Malmi (AKA Sirius) “COPA trial” email #155** **Date: Mon, 08 Feb 2010 15:28:52 +0000** **From: Satoshi Nakamoto <satoshin@gmx.com>** **Subject: Translation** **To: Martti Malmi <mmalmi@cc.hut.fi>** Does Drupal have any special multi-language support, or do you just create copies of pages by hand? BlueSky offered to do translation on the forum. If you create a www.bitcoin.org/zh/ copy of the site and give him an account with just the ability to create new pages and edit text, he'll probably translate the site into Chinese for you and maybe maintain it. **BitcoinTalk** Bitcoin client and website translation _2010-02-08 16:10:37 UTC_ - [-](https://bitcointalk.org/index.php?topic=47.msg283#msg283) It's much easier to have a single binary and multiple .mo files. It's too much maintenance work to have lots of build variations. Once the software support is implemented, anyone could contribute translations. wxWidgets uses the gettext standard. You use the gettext tools or something like poedit to create a .po file by scanning the sourcefiles for strings and editing the translations into the .po file, then compile it into a .mo file. The program loads the .mo file at runtime and reskins all the strings. Additional languages can be added to an existing program by adding .mo files without recompiling the program. On Windows, the .mo files would go in a lang subdirectory in the directory where the EXE is located. Right now I'm working on JSON-RPC and command line support, but when I'm finished with that I hope to do this next. ----

131msg73132msg77ifdefincludeendifmsg79134136138msg85msg84msg97msg112msg113msg156msg159msg174143141142msg219msg220msg222msg223145146if147148151152msg249msg250msg246msg264msg267153msg278msg279155msg283

Kicking the Hornet's Next - part 2

# Kicking the Hornet's Nest - third edition - part 2 All links, digital (pdf, txt, docx, md) and book in print, can be found at https://hive.blog/@crrdlx/satoshi Edited by [crrdlx](nostr:nprofile1qyv8wumn8ghj7mn0wdj8y6tkv5hxzurs9aex2mrp0yq3wamnwvaz7tmjv4kxz7fwwpexjmtpdshxuet59uqzqqzmcn0yrn7ttq8hrjkk46ysn2tk26rr8f8k4y7xkl74hlh3rcdzm9d3t8), npub: ``` npub1qpdufhjpel94srm3ett2azgf49m9dp3n5nm2j0rt0l2mlmc3ux3qza082j ``` ---- ### Kicking the Hornet's Nest pages 12 - 24 ---- Satoshi Nakamoto’s PGP Key ``` -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.7 (MingW32) mQGiBEkJ+qcRBADKDTcZlYDRtP1Q7/ShuzBJzUh9hoVVowogf2W07U6G9BqKW24r piOxYmErjMFfvNtozNk+33cd/sq3gi05O1IMmZzg2rbF4ne5t3iplXnNuzNh+j+6 VxxA16GPhBRprvnng8r9GYALLUpo9Xk17KE429YYKFgVvtTPtEGUlpO1EwCg7FmW dBbRp4mn5GfxQNT1hzp9WgkD/3pZ0cB5m4enzfylOHXmRfJKBMF02ZDnsY1GqeHv /LjkhCusTp2qz4thLycYOFKGmAddpVnMsE/TYZLgpsxjrJsrEPNSdoXk3IgEStow mXjTfr9xNOrB20Qk0ZOO1mipOWMgse4PmIu02X24OapWtyhdHsX3oBLcwDdke8aE gAh8A/sHlK7fL1Bi8rFzx6hb+2yIlD/fazMBVZUe0r2uo7ldqEz5+GeEiBFignd5 HHhqjJw8rUJkfeZBoTKYlDKo7XDrTRxfyzNuZZPxBLTj+keY8WgYhQ5MWsSC2MX7 FZHaJddYa0pzUmFZmQh0ydulVUQnLKzRSunsjGOnmxiWBZwb6bQjU2F0b3NoaSBO YWthbW90byA8c2F0b3NoaW5AZ214LmNvbT6IYAQTEQIAIAUCSQn6pwIbAwYLCQgH AwIEFQIIAwQWAgMBAh4BAheAAAoJEBjAnoZeyUihXGMAnjiWJ0fvmSgSM3o6Tu3q RME9GN7QAKCGrFw9SUD0e9/YDcqhX1aPMrYue7kCDQRJCfqnEAgA9OTCjLa6Sj7t dZcQxNufsDSCSB+yznIGzFGXXpJk7GgKmX3H9Zl4E6zJTQGXL2GAV4klkSfNtvgs SGJKqCnebuZVwutyq1vXRNVFPQFvLVVo2jJCBHWjb03fmXmavIUtRCHoc8xgVJMQ LrwvS943GgsqSbdoKZWdTnfnEq+UaGo+Qfv66NpT3Yl0CXUiNBITZOJcJdjHDTBO XRqomX2WSguv+btYdhQGGQiaEx73XMftXNCxbOpqwsODQns7xTcl2ENru9BNIQME I7L9FYBQUiKHm1k6RrBy1as8XElS2jEos7GAmlfF1wShFUX+NF1VOPdbN3ZdFoWq sUjKk+QbrwADBQgA9DiD4+uuRhwk2B1TmtrXnwwhcdkE7ZbLHjxBfCsLPAZiPh8c ICfV3S418i4H1YCz2ItcnC8KAPoS6mipyS28AU1B7zJYPODBn8E7aPSPzHJfudMK MqiCHljVJrE23xsKTC0sIhhSKcr2G+6ARoG5lwuoqJqEyDrblVQQFpVxBNPHSTqu O5PoLXQc7PKgC5SyQuZbEALEkItl2SL2yBRRGOlVJLnvZ6eaovkAlgsbGdlieOr0 UwWuJCwzZuBDruMYAfyQBvYfXZun3Zm84rW7Jclp18mXITwGCVHg/P5n7QMbBfZQ A25ymkuj636Nqh+c4zRnSINfyrDcID7AcqEb6IhJBBgRAgAJBQJJCfqnAhsMAAoJ EBjAnoZeyUihPrcAniVWl5M44RuGctJe+IMNX4eVkC08AJ9v7cXsp5uDdQNo8q3R 8RHwN4Gk8w== =3FTe -----END PGP PUBLIC KEY BLOCK----- ``` ---- ### The Bitcoin Whitepaper Source: https://bitcoin.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash System Satoshi Nakamoto October 31, 2008 ##### Abstract A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. ##### 1. Introduction Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for non-reversible services. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party. What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers. In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes. ##### 2. Transactions We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership. ![](https://image.nostr.build/373abc735aa42e25bd5ee658a3ea671c8255d7ab87b463752b93d8acb21ae518.jpg) The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank. We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced[1], and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received. ##### 3. Timestamp Server The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post[2-5]. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it. ![](https://image.nostr.build/897993512909cb2241a52250e1204a996975035881090783c40450a8b0867cee.jpg) ##### 4. Proof-of-Work To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash[6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash. For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it. ![](https://image.nostr.build/dde7681f7ff7ab3a13a9d36f72d6e1cc293d89774feedfd5b15e1b2687294fbc.jpg) The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added. To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases. ##### 5. Network The steps to run the network are as follows: 1. New transactions are broadcast to all nodes. 2. Each node collects new transactions into a block. 3. Each node works on finding a difficult proof-of-work for its block. 4. When a node finds a proof-of-work, it broadcasts the block to all nodes. 5. Nodes accept the block only if all transactions in it are valid and not already spent. 6. Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash. Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one. New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will get into a block before long. Block broadcasts are also tolerant of dropped messages. If a node does not receive a block, it will request it when it receives the next block and realizes it missed one. ##### 6. Incentive By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them. The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended. The incentive can also be funded with transaction fees. If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free. The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth. ##### 7. Reclaiming Disk Space Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored. ![](https://image.nostr.build/9704331139070ab1267f473a827f0f52ff8b7d4058c25284446ec4c3b1117409.jpg) A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory. ##### 8. Simplified Payment Verification It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it. ![](https://image.nostr.build/7ca5e752ba154e609e3d61b11398589a83fe68e59ec3156845cbc5dd4b237618.jpg) As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification. ##### 9. Combining and Splitting Value Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender. ![](https://image.nostr.build/73eda67b80c47a9f0c331de63ed8a76362e33527cbd3409c06bfe249ab6e4c1a.jpg) It should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a problem here. There is never the need to extract a complete standalone copy of a transaction's history. ##### 10. Privacy The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the "tape", is made public, but without telling who the parties were. ![](https://image.nostr.build/cbd2a4403d19652370fce1882bcda76e9ef5ed95801e3a693f40baf8af39f35a.jpg) As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner. ##### 11. Calculations We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent. The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the gap by -1. The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven. We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows[8]: pqqz=== probability an honest node finds the next block probability the attacker finds the next block probability the attacker will ever catch up from z blocks behindp= probability an honest node finds the next blockq= probability the attacker finds the next blockqz= probability the attacker will ever catch up from z blocks behind qz={1(q/p)zifp≤qifp>q}qz={1ifp≤q(q/p)zifp>q} Given our assumption that p>qp>q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases. With the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind. We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late. The receiver generates a new key pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment. Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction. The recipient waits until the transaction has been added to a block and zz blocks have been linked after it. He doesn't know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a Poisson distribution with expected value: λ=zqpλ=zqp To get the probability the attacker could still catch up now, we multiply the Poisson density for each amount of progress he could have made by the probability he could catch up from that point: ∑k=0∞λke−λk!⋅{(q/p)(z−k)1ifk≤zifk>z}∑k=0∞λke−λk!⋅{(q/p)(z−k)ifk≤z1ifk>z} Rearranging to avoid summing the infinite tail of the distribution... 1−∑k=0zλke−λk!(1−(q/p)(z−k))1−∑k=0zλke−λk!(1−(q/p)(z−k)) Converting to C code... #include double AttackerSuccessProbability(double q, int z) { double p = 1.0 - q; double lambda = z * (q / p); double sum = 1.0; int i, k; for (k = 0; k <= z; k++) { double poisson = exp(-lambda); for (i = 1; i <= k; i++) poisson *= lambda / i; sum -= poisson * (1 - pow(q / p, z - k)); } return sum; } Running some results, we can see the probability drop off exponentially with zz. q=0.1 z=0 P=1.0000000 z=1 P=0.2045873 z=2 P=0.0509779 z=3 P=0.0131722 z=4 P=0.0034552 z=5 P=0.0009137 z=6 P=0.0002428 z=7 P=0.0000647 z=8 P=0.0000173 z=9 P=0.0000046 z=10 P=0.0000012 q=0.3 z=0 P=1.0000000 z=5 P=0.1773523 z=10 P=0.0416605 z=15 P=0.0101008 z=20 P=0.0024804 z=25 P=0.0006132 z=30 P=0.0001522 z=35 P=0.0000379 z=40 P=0.0000095 z=45 P=0.0000024 z=50 P=0.0000006 Solving for P less than 0.1%... P < 0.001 q=0.10 z=5 q=0.15 z=8 q=0.20 z=11 q=0.25 z=15 q=0.30 z=24 q=0.35 z=41 q=0.40 z=89 q=0.45 z=340 ##### 12. Conclusion We have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism. ##### References 1. W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998. ↩ 2. H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999. ↩ ↩ 3. S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991. ↩ 4. D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital time-stamping," In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993. ↩ 5. S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997. ↩ ↩ 6. A. Back, "Hashcash - a denial of service counter-measure,"http://www.hashcash.org/papers/hashcash.pdf, 2002. ↩ 7. R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980. ↩ 8. W. Feller, "An introduction to probability theory and its applications," 1957. ↩ ----

include

Kicking e3 part 2

# Kicking the Hornet's Nest - edition 3 - part 2 Go to Table of Contents Satoshi Nakamoto’s PGP Key ``` -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.4.7 (MingW32) mQGiBEkJ+qcRBADKDTcZlYDRtP1Q7/ShuzBJzUh9hoVVowogf2W07U6G9BqKW24r piOxYmErjMFfvNtozNk+33cd/sq3gi05O1IMmZzg2rbF4ne5t3iplXnNuzNh+j+6 VxxA16GPhBRprvnng8r9GYALLUpo9Xk17KE429YYKFgVvtTPtEGUlpO1EwCg7FmW dBbRp4mn5GfxQNT1hzp9WgkD/3pZ0cB5m4enzfylOHXmRfJKBMF02ZDnsY1GqeHv /LjkhCusTp2qz4thLycYOFKGmAddpVnMsE/TYZLgpsxjrJsrEPNSdoXk3IgEStow mXjTfr9xNOrB20Qk0ZOO1mipOWMgse4PmIu02X24OapWtyhdHsX3oBLcwDdke8aE gAh8A/sHlK7fL1Bi8rFzx6hb+2yIlD/fazMBVZUe0r2uo7ldqEz5+GeEiBFignd5 HHhqjJw8rUJkfeZBoTKYlDKo7XDrTRxfyzNuZZPxBLTj+keY8WgYhQ5MWsSC2MX7 FZHaJddYa0pzUmFZmQh0ydulVUQnLKzRSunsjGOnmxiWBZwb6bQjU2F0b3NoaSBO YWthbW90byA8c2F0b3NoaW5AZ214LmNvbT6IYAQTEQIAIAUCSQn6pwIbAwYLCQgH AwIEFQIIAwQWAgMBAh4BAheAAAoJEBjAnoZeyUihXGMAnjiWJ0fvmSgSM3o6Tu3q RME9GN7QAKCGrFw9SUD0e9/YDcqhX1aPMrYue7kCDQRJCfqnEAgA9OTCjLa6Sj7t dZcQxNufsDSCSB+yznIGzFGXXpJk7GgKmX3H9Zl4E6zJTQGXL2GAV4klkSfNtvgs SGJKqCnebuZVwutyq1vXRNVFPQFvLVVo2jJCBHWjb03fmXmavIUtRCHoc8xgVJMQ LrwvS943GgsqSbdoKZWdTnfnEq+UaGo+Qfv66NpT3Yl0CXUiNBITZOJcJdjHDTBO XRqomX2WSguv+btYdhQGGQiaEx73XMftXNCxbOpqwsODQns7xTcl2ENru9BNIQME I7L9FYBQUiKHm1k6RrBy1as8XElS2jEos7GAmlfF1wShFUX+NF1VOPdbN3ZdFoWq sUjKk+QbrwADBQgA9DiD4+uuRhwk2B1TmtrXnwwhcdkE7ZbLHjxBfCsLPAZiPh8c ICfV3S418i4H1YCz2ItcnC8KAPoS6mipyS28AU1B7zJYPODBn8E7aPSPzHJfudMK MqiCHljVJrE23xsKTC0sIhhSKcr2G+6ARoG5lwuoqJqEyDrblVQQFpVxBNPHSTqu O5PoLXQc7PKgC5SyQuZbEALEkItl2SL2yBRRGOlVJLnvZ6eaovkAlgsbGdlieOr0 UwWuJCwzZuBDruMYAfyQBvYfXZun3Zm84rW7Jclp18mXITwGCVHg/P5n7QMbBfZQ A25ymkuj636Nqh+c4zRnSINfyrDcID7AcqEb6IhJBBgRAgAJBQJJCfqnAhsMAAoJ EBjAnoZeyUihPrcAniVWl5M44RuGctJe+IMNX4eVkC08AJ9v7cXsp5uDdQNo8q3R 8RHwN4Gk8w== =3FTe -----END PGP PUBLIC KEY BLOCK----- ``` ---- ### The Bitcoin Whitepaper Source: https://bitcoin.org/bitcoin.pdf Bitcoin: A Peer-to-Peer Electronic Cash System Satoshi Nakamoto October 31, 2008 ##### Abstract A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone. ##### 1. Introduction Commerce on the Internet has come to rely almost exclusively on financial institutions serving as trusted third parties to process electronic payments. While the system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for non-reversible services. With the possibility of reversal, the need for trust spreads. Merchants must be wary of their customers, hassling them for more information than they would otherwise need. A certain percentage of fraud is accepted as unavoidable. These costs and payment uncertainties can be avoided in person by using physical currency, but no mechanism exists to make payments over a communications channel without a trusted party. What is needed is an electronic payment system based on cryptographic proof instead of trust, allowing any two willing parties to transact directly with each other without the need for a trusted third party. Transactions that are computationally impractical to reverse would protect sellers from fraud, and routine escrow mechanisms could easily be implemented to protect buyers. In this paper, we propose a solution to the double-spending problem using a peer-to-peer distributed timestamp server to generate computational proof of the chronological order of transactions. The system is secure as long as honest nodes collectively control more CPU power than any cooperating group of attacker nodes. ##### 2. Transactions We define an electronic coin as a chain of digital signatures. Each owner transfers the coin to the next by digitally signing a hash of the previous transaction and the public key of the next owner and adding these to the end of the coin. A payee can verify the signatures to verify the chain of ownership. ![](https://image.nostr.build/373abc735aa42e25bd5ee658a3ea671c8255d7ab87b463752b93d8acb21ae518.jpg) The problem of course is the payee can't verify that one of the owners did not double-spend the coin. A common solution is to introduce a trusted central authority, or mint, that checks every transaction for double spending. After each transaction, the coin must be returned to the mint to issue a new coin, and only coins issued directly from the mint are trusted not to be double-spent. The problem with this solution is that the fate of the entire money system depends on the company running the mint, with every transaction having to go through them, just like a bank. We need a way for the payee to know that the previous owners did not sign any earlier transactions. For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. The only way to confirm the absence of a transaction is to be aware of all transactions. In the mint based model, the mint was aware of all transactions and decided which arrived first. To accomplish this without a trusted party, transactions must be publicly announced[1], and we need a system for participants to agree on a single history of the order in which they were received. The payee needs proof that at the time of each transaction, the majority of nodes agreed it was the first received. ##### 3. Timestamp Server The solution we propose begins with a timestamp server. A timestamp server works by taking a hash of a block of items to be timestamped and widely publishing the hash, such as in a newspaper or Usenet post[2-5]. The timestamp proves that the data must have existed at the time, obviously, in order to get into the hash. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it. ![](https://image.nostr.build/897993512909cb2241a52250e1204a996975035881090783c40450a8b0867cee.jpg) ##### 4. Proof-of-Work To implement a distributed timestamp server on a peer-to-peer basis, we will need to use a proof-of-work system similar to Adam Back's Hashcash[6], rather than newspaper or Usenet posts. The proof-of-work involves scanning for a value that when hashed, such as with SHA-256, the hash begins with a number of zero bits. The average work required is exponential in the number of zero bits required and can be verified by executing a single hash. For our timestamp network, we implement the proof-of-work by incrementing a nonce in the block until a value is found that gives the block's hash the required zero bits. Once the CPU effort has been expended to make it satisfy the proof-of-work, the block cannot be changed without redoing the work. As later blocks are chained after it, the work to change the block would include redoing all the blocks after it. ![](https://image.nostr.build/dde7681f7ff7ab3a13a9d36f72d6e1cc293d89774feedfd5b15e1b2687294fbc.jpg) The proof-of-work also solves the problem of determining representation in majority decision making. If the majority were based on one-IP-address-one-vote, it could be subverted by anyone able to allocate many IPs. Proof-of-work is essentially one-CPU-one-vote. The majority decision is represented by the longest chain, which has the greatest proof-of-work effort invested in it. If a majority of CPU power is controlled by honest nodes, the honest chain will grow the fastest and outpace any competing chains. To modify a past block, an attacker would have to redo the proof-of-work of the block and all blocks after it and then catch up with and surpass the work of the honest nodes. We will show later that the probability of a slower attacker catching up diminishes exponentially as subsequent blocks are added. To compensate for increasing hardware speed and varying interest in running nodes over time, the proof-of-work difficulty is determined by a moving average targeting an average number of blocks per hour. If they're generated too fast, the difficulty increases. ##### 5. Network The steps to run the network are as follows: 1. New transactions are broadcast to all nodes. 2. Each node collects new transactions into a block. 3. Each node works on finding a difficult proof-of-work for its block. 4. When a node finds a proof-of-work, it broadcasts the block to all nodes. 5. Nodes accept the block only if all transactions in it are valid and not already spent. 6. Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash. Nodes always consider the longest chain to be the correct one and will keep working on extending it. If two nodes broadcast different versions of the next block simultaneously, some nodes may receive one or the other first. In that case, they work on the first one they received, but save the other branch in case it becomes longer. The tie will be broken when the next proof-of-work is found and one branch becomes longer; the nodes that were working on the other branch will then switch to the longer one. New transaction broadcasts do not necessarily need to reach all nodes. As long as they reach many nodes, they will get into a block before long. Block broadcasts are also tolerant of dropped messages. If a node does not receive a block, it will request it when it receives the next block and realizes it missed one. ##### 6. Incentive By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block. This adds an incentive for nodes to support the network, and provides a way to initially distribute coins into circulation, since there is no central authority to issue them. The steady addition of a constant of amount of new coins is analogous to gold miners expending resources to add gold to circulation. In our case, it is CPU time and electricity that is expended. The incentive can also be funded with transaction fees. If the output value of a transaction is less than its input value, the difference is a transaction fee that is added to the incentive value of the block containing the transaction. Once a predetermined number of coins have entered circulation, the incentive can transition entirely to transaction fees and be completely inflation free. The incentive may help encourage nodes to stay honest. If a greedy attacker is able to assemble more CPU power than all the honest nodes, he would have to choose between using it to defraud people by stealing back his payments, or using it to generate new coins. He ought to find it more profitable to play by the rules, such rules that favour him with more new coins than everyone else combined, than to undermine the system and the validity of his own wealth. ##### 7. Reclaiming Disk Space Once the latest transaction in a coin is buried under enough blocks, the spent transactions before it can be discarded to save disk space. To facilitate this without breaking the block's hash, transactions are hashed in a Merkle Tree [7][2][5], with only the root included in the block's hash. Old blocks can then be compacted by stubbing off branches of the tree. The interior hashes do not need to be stored. ![](https://image.nostr.build/9704331139070ab1267f473a827f0f52ff8b7d4058c25284446ec4c3b1117409.jpg) A block header with no transactions would be about 80 bytes. If we suppose blocks are generated every 10 minutes, 80 bytes * 6 * 24 * 365 = 4.2MB per year. With computer systems typically selling with 2GB of RAM as of 2008, and Moore's Law predicting current growth of 1.2GB per year, storage should not be a problem even if the block headers must be kept in memory. ##### 8. Simplified Payment Verification It is possible to verify payments without running a full network node. A user only needs to keep a copy of the block headers of the longest proof-of-work chain, which he can get by querying network nodes until he's convinced he has the longest chain, and obtain the Merkle branch linking the transaction to the block it's timestamped in. He can't check the transaction for himself, but by linking it to a place in the chain, he can see that a network node has accepted it, and blocks added after it further confirm the network has accepted it. ![](https://image.nostr.build/7ca5e752ba154e609e3d61b11398589a83fe68e59ec3156845cbc5dd4b237618.jpg) As such, the verification is reliable as long as honest nodes control the network, but is more vulnerable if the network is overpowered by an attacker. While network nodes can verify transactions for themselves, the simplified method can be fooled by an attacker's fabricated transactions for as long as the attacker can continue to overpower the network. One strategy to protect against this would be to accept alerts from network nodes when they detect an invalid block, prompting the user's software to download the full block and alerted transactions to confirm the inconsistency. Businesses that receive frequent payments will probably still want to run their own nodes for more independent security and quicker verification. ##### 9. Combining and Splitting Value Although it would be possible to handle coins individually, it would be unwieldy to make a separate transaction for every cent in a transfer. To allow value to be split and combined, transactions contain multiple inputs and outputs. Normally there will be either a single input from a larger previous transaction or multiple inputs combining smaller amounts, and at most two outputs: one for the payment, and one returning the change, if any, back to the sender. ![](https://image.nostr.build/73eda67b80c47a9f0c331de63ed8a76362e33527cbd3409c06bfe249ab6e4c1a.jpg) It should be noted that fan-out, where a transaction depends on several transactions, and those transactions depend on many more, is not a problem here. There is never the need to extract a complete standalone copy of a transaction's history. ##### 10. Privacy The traditional banking model achieves a level of privacy by limiting access to information to the parties involved and the trusted third party. The necessity to announce all transactions publicly precludes this method, but privacy can still be maintained by breaking the flow of information in another place: by keeping public keys anonymous. The public can see that someone is sending an amount to someone else, but without information linking the transaction to anyone. This is similar to the level of information released by stock exchanges, where the time and size of individual trades, the "tape", is made public, but without telling who the parties were. ![](https://image.nostr.build/cbd2a4403d19652370fce1882bcda76e9ef5ed95801e3a693f40baf8af39f35a.jpg) As an additional firewall, a new key pair should be used for each transaction to keep them from being linked to a common owner. Some linking is still unavoidable with multi-input transactions, which necessarily reveal that their inputs were owned by the same owner. The risk is that if the owner of a key is revealed, linking could reveal other transactions that belonged to the same owner. ##### 11. Calculations We consider the scenario of an attacker trying to generate an alternate chain faster than the honest chain. Even if this is accomplished, it does not throw the system open to arbitrary changes, such as creating value out of thin air or taking money that never belonged to the attacker. Nodes are not going to accept an invalid transaction as payment, and honest nodes will never accept a block containing them. An attacker can only try to change one of his own transactions to take back money he recently spent. The race between the honest chain and an attacker chain can be characterized as a Binomial Random Walk. The success event is the honest chain being extended by one block, increasing its lead by +1, and the failure event is the attacker's chain being extended by one block, reducing the gap by -1. The probability of an attacker catching up from a given deficit is analogous to a Gambler's Ruin problem. Suppose a gambler with unlimited credit starts at a deficit and plays potentially an infinite number of trials to try to reach breakeven. We can calculate the probability he ever reaches breakeven, or that an attacker ever catches up with the honest chain, as follows[8]: pqqz=== probability an honest node finds the next block probability the attacker finds the next block probability the attacker will ever catch up from z blocks behindp= probability an honest node finds the next blockq= probability the attacker finds the next blockqz= probability the attacker will ever catch up from z blocks behind qz={1(q/p)zifp≤qifp>q}qz={1ifp≤q(q/p)zifp>q} Given our assumption that p>qp>q, the probability drops exponentially as the number of blocks the attacker has to catch up with increases. With the odds against him, if he doesn't make a lucky lunge forward early on, his chances become vanishingly small as he falls further behind. We now consider how long the recipient of a new transaction needs to wait before being sufficiently certain the sender can't change the transaction. We assume the sender is an attacker who wants to make the recipient believe he paid him for a while, then switch it to pay back to himself after some time has passed. The receiver will be alerted when that happens, but the sender hopes it will be too late. The receiver generates a new key pair and gives the public key to the sender shortly before signing. This prevents the sender from preparing a chain of blocks ahead of time by working on it continuously until he is lucky enough to get far enough ahead, then executing the transaction at that moment. Once the transaction is sent, the dishonest sender starts working in secret on a parallel chain containing an alternate version of his transaction. The recipient waits until the transaction has been added to a block and zz blocks have been linked after it. He doesn't know the exact amount of progress the attacker has made, but assuming the honest blocks took the average expected time per block, the attacker's potential progress will be a Poisson distribution with expected value: λ=zqpλ=zqp To get the probability the attacker could still catch up now, we multiply the Poisson density for each amount of progress he could have made by the probability he could catch up from that point: ∑k=0∞λke−λk!⋅{(q/p)(z−k)1ifk≤zifk>z}∑k=0∞λke−λk!⋅{(q/p)(z−k)ifk≤z1ifk>z} Rearranging to avoid summing the infinite tail of the distribution... 1−∑k=0zλke−λk!(1−(q/p)(z−k))1−∑k=0zλke−λk!(1−(q/p)(z−k)) Converting to C code... #include double AttackerSuccessProbability(double q, int z) { double p = 1.0 - q; double lambda = z * (q / p); double sum = 1.0; int i, k; for (k = 0; k <= z; k++) { double poisson = exp(-lambda); for (i = 1; i <= k; i++) poisson *= lambda / i; sum -= poisson * (1 - pow(q / p, z - k)); } return sum; } Running some results, we can see the probability drop off exponentially with zz. q=0.1 z=0 P=1.0000000 z=1 P=0.2045873 z=2 P=0.0509779 z=3 P=0.0131722 z=4 P=0.0034552 z=5 P=0.0009137 z=6 P=0.0002428 z=7 P=0.0000647 z=8 P=0.0000173 z=9 P=0.0000046 z=10 P=0.0000012 q=0.3 z=0 P=1.0000000 z=5 P=0.1773523 z=10 P=0.0416605 z=15 P=0.0101008 z=20 P=0.0024804 z=25 P=0.0006132 z=30 P=0.0001522 z=35 P=0.0000379 z=40 P=0.0000095 z=45 P=0.0000024 z=50 P=0.0000006 Solving for P less than 0.1%... P < 0.001 q=0.10 z=5 q=0.15 z=8 q=0.20 z=11 q=0.25 z=15 q=0.30 z=24 q=0.35 z=41 q=0.40 z=89 q=0.45 z=340 ##### 12. Conclusion We have proposed a system for electronic transactions without relying on trust. We started with the usual framework of coins made from digital signatures, which provides strong control of ownership, but is incomplete without a way to prevent double-spending. To solve this, we proposed a peer-to-peer network using proof-of-work to record a public history of transactions that quickly becomes computationally impractical for an attacker to change if honest nodes control a majority of CPU power. The network is robust in its unstructured simplicity. Nodes work all at once with little coordination. They do not need to be identified, since messages are not routed to any particular place and only need to be delivered on a best effort basis. Nodes can leave and rejoin the network at will, accepting the proof-of-work chain as proof of what happened while they were gone. They vote with their CPU power, expressing their acceptance of valid blocks by working on extending them and rejecting invalid blocks by refusing to work on them. Any needed rules and incentives can be enforced with this consensus mechanism. ##### References 1. W. Dai, "b-money," http://www.weidai.com/bmoney.txt, 1998. ↩ 2. H. Massias, X.S. Avila, and J.-J. Quisquater, "Design of a secure timestamping service with minimal trust requirements," In 20th Symposium on Information Theory in the Benelux, May 1999. ↩ ↩ 3. S. Haber, W.S. Stornetta, "How to time-stamp a digital document," In Journal of Cryptology, vol 3, no 2, pages 99-111, 1991. ↩ 4. D. Bayer, S. Haber, W.S. Stornetta, "Improving the efficiency and reliability of digital time-stamping," In Sequences II: Methods in Communication, Security and Computer Science, pages 329-334, 1993. ↩ 5. S. Haber, W.S. Stornetta, "Secure names for bit-strings," In Proceedings of the 4th ACM Conference on Computer and Communications Security, pages 28-35, April 1997. ↩ ↩ 6. A. Back, "Hashcash - a denial of service counter-measure,"http://www.hashcash.org/papers/hashcash.pdf, 2002. ↩ 7. R.C. Merkle, "Protocols for public key cryptosystems," In Proc. 1980 Symposium on Security and Privacy, IEEE Computer Society, pages 122-133, April 1980. ↩ 8. W. Feller, "An introduction to probability theory and its applications," 1957. ↩ Forward to part 3 Back to part 1 Go to Table of Contents

include

Kicking the Hornet's Nest edition 3 text version part 1

Part 1 of "Kicking the Hornet's Nest" - all of the public writings of Satoshi Nakamoto arranged in chronological order.

include