The assumption is that you would send variations of the same transaction to different nodes with a tip for working to integrate your transaction.  In order for that node to collect their tip they eventually have to generate a block, but they eventually will anyway.  The tip would be below […]

Just to be able to ask “What if …?” and have all ideas collected in one place. For example. It seems, that a generating node does not need to receive all that transactions at all. The only data it needs is the previous block hash. Right? Next. It is possible […]

Quote from: sirius-m on August 11, 2010, 02:01:53 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 […]

[…] An interesting feature is that this simplifies the validation process. All that needs to be done is to parse the block list (of hashes) once. As each hash is parsed you simply look it up in a hash-set. If it doesn’t exist you add it. If it does exist […]

Building r127 here, we see some missing casts, apparently: Code: rpc.cpp: In function ‘json_spirit::Value gethashespersec(const json_spirit::Array&, bool)’: rpc.cpp:340: error: conversion from ‘int64’ to ‘json_spirit::Value’ is ambiguous json/json_spirit_value.h:283: note: candidates are: json_spirit::Value_impl<Config>::Value_impl(double) [with Config = json_spirit::Config_vector<std::basic_string<char, std::char_traits<char>, std::allocator<char> > >] json/json_spirit_value.h:275: note:                 json_spirit::Value_impl<Config>::Value_impl(uint64_t) […]

Quote from: jgarzik on August 10, 2010, 18:53:57 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 […]

As some might have noticed, one of the things that bugs me about bitcoin is that the entire history of transactions is completely public. I totally understand the benefits of how this simplifies things and makes it easy for everyone to prove coins are valid. So this is not a […]

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) SVN rev 128: disable […]

Thanks very much for your reply. I agree with your analysis, and this thread has actually changed my mind as to my initial criticism. After more careful study of the design of the Bitcoin network and trying to understand the exact manner in which Bitcoin attempts to create value from […]

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, […]