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_ 
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.
----
