Bitcoin Forum
May 22, 2019, 06:18:54 PM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 »
181  Bitcoin / Development & Technical Discussion / tcatm's 4-way SSE2 for Linux 32/64-bit is in 0.3.10 on: August 15, 2010, 03:52:09 PM
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

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.
182  Bitcoin / Development & Technical Discussion / Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 on: August 15, 2010, 03:40:29 AM
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
+++ \new\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)
183  Bitcoin / Development & Technical Discussion / Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 on: August 14, 2010, 10:06:13 PM
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.

184  Bitcoin / Development & Technical Discussion / Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 on: August 14, 2010, 05:55:37 PM
Got the test working on 32-bit with MinGW GCC 4.5.  Exactly 50% slower than stock with Core 2.
185  Bitcoin / Development & Technical Discussion / Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 on: August 14, 2010, 04:22:29 AM
If you haven't already, try aligning thash.  It might matter.  Couldn't hurt.

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.

186  Bitcoin / Development & Technical Discussion / Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 on: August 14, 2010, 12:49:18 AM
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
187  Bitcoin / Development & Technical Discussion / Re: Proposed change to sendtoaddress API call on: August 13, 2010, 11:39:14 PM
It's too soon to start junking up the API for backward compatibility at all costs.

Just return "<txid>".
188  Bitcoin / Bitcoin Discussion / Re: Not a suggestion on: August 13, 2010, 07:28:47 PM
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/

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.
189  Bitcoin / Development & Technical Discussion / Version 0.3.9 rc1, please test on: August 13, 2010, 05:40:00 PM
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-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

SHA1 47d9998f7d15fe81234a5c89a542da9d0664df40 bitcoin-0.3.9.rc2-linux.tar.gz

Please report back your results
http://bitcointalk.org/index.php?topic=820
190  Bitcoin / Development & Technical Discussion / Re: Bitcoin Watchdog Service on: August 13, 2010, 05:09:27 PM
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.
191  Bitcoin / Development & Technical Discussion / Re: Bugfixes in SVN rev 130 on: August 13, 2010, 03:15:23 AM
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.
192  Bitcoin / Development & Technical Discussion / Re: 4 hashes parallel on SSE2 CPUs for 0.3.6 on: August 12, 2010, 10:07:23 PM
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 (!)
193  Bitcoin / Bitcoin Technical Support / Re: Having problems specifing -datadir on: August 12, 2010, 09:43:29 PM
Fixed in SVN rev 130.
194  Bitcoin / Development & Technical Discussion / Re: Bitcoin Watchdog Service on: August 12, 2010, 09:34:44 PM
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.
195  Bitcoin / Development & Technical Discussion / Bugfixes in SVN rev 130 on: August 12, 2010, 09:20:31 PM
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
196  Bitcoin / Development & Technical Discussion / Re: BSD detection on: August 12, 2010, 09:14:20 PM
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
197  Bitcoin / Bitcoin Discussion / Re: Not a suggestion on: August 12, 2010, 02:46:56 AM
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.
198  Bitcoin / Development & Technical Discussion / Re: BSD detection on: August 12, 2010, 12:02:06 AM
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?
199  Bitcoin / Bitcoin Discussion / Re: Flood attack 0.00000001 BC on: August 11, 2010, 11:28:50 PM
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.
200  Bitcoin / Development & Technical Discussion / Re: Where is the separate discussion devoted to possible Bitcoin weaknesses. on: August 11, 2010, 10:40:25 PM
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.

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.
Pages: « 1 2 3 4 5 6 7 8 9 [10] 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!