Bitcoin Forum
May 02, 2024, 10:46:08 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 [69] 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 »
1361  Bitcoin / Hardware / Re: Goliath on: December 12, 2012, 09:54:15 PM
I like to own my own gear and I like to have it hashing and tinkering with it.
I'm somewhat familiar with this type of deals. There will be no sales whatsoever. You could however negotiate a lease agreement. The equipment would have to be colocated in a secure datacenter (this means IBM, Experian, Wells Fargo, etc. datacenter; not Joe's Datacenter) and maintained only by an approved operator. You will however be able to see it, touch it and evaluate it using a mutually approved methodology, etc. Only certain failure/defect statistics will not be available.

Basically an appropriate operator and datacenter are assurances against reverse engineering and/or spying. This type of arrangements are not unusual in some markets. Think of them as a sort of "technology escrow". Operator assures that the technology vendor doesn't see the data you pass through their equipment and technology user doesn't open the box and reverse engineer it.
1362  Bitcoin / Hardware / Re: Goliath on: December 12, 2012, 08:53:37 PM
As to the technology it's more valuable to us in other markets so handing out our ideas and knowledge in any shape or form isn't a flyer. That includes even giving a hint of what we are doing.
Hurrah for more speculation! Bit-serial GaAs hashers?

Could anyone ping bitfury for his guess? Anyone else wants to speculate?

1363  Bitcoin / Project Development / Re: Probably the hottest business idea of the moment in BTC on: December 12, 2012, 04:32:55 PM
Quote from: Mircea Popescu
… is a code review and insurance service.
Comments welcome.
This isn't only a surefire money maker. The (yet unpublished) Dunning-Kruger-Popescu halting insurance pricing model will revolutionize the computer science. The old chestnut of halting problem will forever join the phlogiston in the annals of obsolete science. In similarity to the Black-Scholes option pricining model the creators of it will receive either the Fields Medal or the Nobel Prize for their key contribution: instead of the old boolean decision halts/doesn't halt replace it with an insurance contract: keep paying premiums while program runs and receive one-time settlement when the program doesn't halt.

Where do I send money? I mean I need to order some of that great Romanian sparkling wine to stimulate my own creativity in this holiday season.
1364  Bitcoin / Development & Technical Discussion / Re: ANN: Announcing code availability of the bitsofproof supernode on: December 10, 2012, 04:08:24 PM
I'm pretty sure there is a bug, yes. If I'm wrong then I will of course apologise and go back to update my previous post.

The point of being vague is that us finding bugs on random code reviews isn't reliable or scalable. With your new codebase you're not solving a problem any of the current core developers have, so there isn't much incentive for us to go finding bugs for you. But if people were to use or mine upon a new implementation with bugs, that would definitely cause problems.

So what's important to demonstrate is that your code can be used without presenting a danger to the network, and that means really solid processes and testing to ensure the behavior matches exactly. If we can find one or two issues, there could well be more, so a rigorous testing and protocol compliance regime is the only way to build confidence.
I'm preserving this against further editing. If anyone has any remaining doubts about Mike's motivation please compare this post with his earlier post in the "multi-sig or scalability" thread:

https://bitcointalk.org/index.php?topic=94453.msg1046848#msg1046848
1365  Bitcoin / Development & Technical Discussion / Re: ANN: Announcing code availability of the bitsofproof supernode on: December 10, 2012, 03:43:48 PM
I don't get the logic of withholding known bugs.
This type of "logic" is normally called extortion. GMaxwell is a known extortionist, except that he calls it "tipping the incentives". Here is the link his post from the beginning of this year where he was openly asking for payment:

https://bitcointalk.org/index.php?topic=56675.msg677910#msg677910

When I joined this forum I was completely wrong calling the Bitcoin core development team "Bitcoin bunker". Now that I understand the situation better I know that there's no single bunker. There are numerous one-or-two-person cubbyholes that may occasionally form the aliances to shoot at the occupant of another cubbyhole. The situation conforms better to the distributed paradigm inherent in the design of Bitcoin.

1366  Bitcoin / Hardware / Re: New kid on the block? on: December 09, 2012, 12:15:17 AM
The picture looks suspiciously like BFL's FPGA Singles.

But if it is a real reuse of an existing ASIC chip then I presume that the chip was designed to accelerate IPsec VPNs:

https://bitcointalk.org/index.php?topic=48863.msg622587#msg622587
1367  Bitcoin / Bitcoin Technical Support / Re: Exceeds size limit? on: December 08, 2012, 11:10:58 PM
or am I just stuck and paying a BIG fee?
Not if you have a bitcoin-rich uncle. Just meet with him and ask him to use his 1000 BTC wad of cash to mop up the dust in your wallet.

I'm not kidding. You can avoid all fees if you can convince someone to include your small transaction outputs in a single large transaction. It is the total sum transferred that matters.
1368  Other / Off-topic / Re: Butterfly Labs is going to give lifetime warranty on: December 08, 2012, 05:24:25 PM
Switching cores off is a useful technique to be used on chips that have huge die sizes ( 200mm2 and up ) where defect probabilities go up and for each defect you either have to throw a very expensive chip to bin or do something else that also might cost big money. The disabling a core is also an expensive solution because it needs a lot of engineering and testing.

I believe this is not useful for BFL because the die sizes are so small making each chip so cheap to produce that is much more economical to just throw the faulty ones to bin rather than trying to do something clever with them. The small die size also means that defect probabilities are much smaller than on bigger dies as the defect probability is some constant multiplied with the die size.

Pulling some numbers from my ass: Not being able to switch cores off could cost them 50 chips each worth $3. How much engineering would you like to do to save $150? The situation is totally different if we are talking about saving 10000 defective chips each worth $200.
The engineering required is near zero. Basically a gated clock buffer instead of plain clock buffer. And a single register wide enough to store those "clock enable" bits for each hashing core.

The overall design is extremely repetitive. The first constraint is thermal. The second one is power distribution rail bounce caused by the huge number of simultaneous switches. Gating the clock would be a standard hardware debugging technique for such a project. I could say that not including clock gating would be a design mistake. The primary objective is to facilitate debugging. Defect tolerance is an additional benefit obtained for free.

Again, the chip is so repetitive and so self-testing, that standard debugging aids (like JTAG) are nearly worthless. The chip is almost an analog or mixed-signal power chip: the primary constraints are thermal and parasitic impedances.

Edit: Furthermore, I think none of the Bitcoin ASIC manufacturers can afford to invest time and money into a proper chip testing. I'm thinking that all packaged chips will be soldered into the mining boards and the final testing will be in-situ. I don't even think that an investment into the proper test equipment would be worthwhile from the engineering point of view. All in all, those chips are just lottery ticket printing machines, it doesn't make sense to test if some rare tickets are missing or mangled. Each winning ticket is worth something for just a couple of minutes maximum.
1369  Other / Off-topic / Re: Butterfly Labs is going to give lifetime warranty on: December 08, 2012, 04:35:29 AM
What you're describing is certainly possible but I don't think it is practical for BFL and I'm surprised nobody else in this thread has called you out on it yet.  They're making small batches of a niche product - there is no big volume here.  The "switch a core off if it didn't work" model is only really practical if you're making chips by the boatload.  BFL needs a low chip failure rate to survive.
Please remember, that the mining software doesn't access the hashing chip directly, but through the the secret firmware. There will be no need for expensive lasering or fusing on the die. Just the firmware has to have a bitmap of the verified working hashers. So the whole situation is very different from the things like CPUs with whole sections of them disabled at the hardware level, because BFL can disable the defective cores at the level equivalent to BIOS.

I'm also assuming that they didn't do fully-unrolled hashers, but much smaller, iterative ones. Therefore I assumed that the chip will have at multiple tens or even hundreds of hashing cores.

On the FPGAs the hashers were unrolled primarily because the deficiency in the place-and-route software heurisics: for the rolled designs the P&R failed to converge or produced spectacularly bad layouts. ASIC designers use way more advanced layout-optimization software.
1370  Economy / Service Discussion / Re: dissapointed by bitcoin enterpreneurs - BFL, GLBSE on: December 06, 2012, 06:13:52 PM
It should be unbelievable that a perfectly valid business model of providing an exchange service for bitcoin bushiness can be shut down by people threatening to put you in jail... But hey, what do I know of what is fair.
I don't want to pick on the author, but this was such a lovely Freudian typo. I surely can envision Internet as a sort of bush (or jungle) where Bitcoin bushnessmen roam in search of a weaker prey. But instead of killing the prey they send they prey back home for more deposits.
1371  Economy / Economics / Re: The best chart I have seen regarding money creation on: December 06, 2012, 04:58:49 PM
I see the words "fractal reserve" in the image - is something to do with preserving the Mandlebrot set going on here?
Yeah. And the "Borad money (cash + deposits)", on the lower, right portion of the graph, is like "Borat money", for make benefit of glorious nation of Kazakhstan.

Too bad that the pictures included in posts can be replaced afterwards with no notification or an ability to quote for posterity.
1372  Bitcoin / Bitcoin Discussion / Re: How do we deal with an internet blackout? on: December 03, 2012, 06:29:06 PM
A transmitter could be set up that continiously broadcasts the block chain. Several of them in different places perhaps. They could be jammed, or falsefied so perhaps more than one would be needed. Its possible this could be even on the longwave band, or on something more modern like encrypted CDMA on a band of frequencies. As well as current transactions, blockchain history would also be periodically transmitted, perhaps using a special protocol that was able to transmit current and historical data simultaneously.
Moon bounce is the word. Let them shoot the Moon down to disable the radio and laser links!

https://bitcointalk.org/index.php?topic=92781.msg1024491#msg1024491

Support the free trade on Earth by banking on the Moon!
1373  Bitcoin / Development & Technical Discussion / Re: BIP 2112 on: December 01, 2012, 09:05:59 PM
Ah come now, it's not that bad is it.
I took "suck balls" as a sort of backhanded compliment from Casascius. If he really wanted to put me down, he would've written e.g. "sucks dead Easter bunnies through a bent straw" or "could suck-start a Harley through the exhaust pipe."

English is a virtual minefield of smoothly readable, but ambiguous sentences, e.g. pharmacist dispensed with accuracy.
1374  Bitcoin / Development & Technical Discussion / Re: BIP 2112 on: December 01, 2012, 09:00:12 PM
Just musing if Coq, Haskell or even Fortran are worth a look ...
Another proposed language was Lua. Apparently it rapidly spreads in the computer science departments in Latin America. Unfortunately I'm illiterate in both Portugese and Spanish, so I can't read the most recent research papers.
1375  Bitcoin / Wallet software / Re: [ANNOUNCE] picocoin and libccoin -- C-based bitcoin library and client on: December 01, 2012, 07:03:41 PM
FWIW while I've never tried doing it QEMU can apparently emulate the big-endian PowerPC architecture. Here is one guys notes about getting it working from two years ago, specifically to test endian issues.
Thanks. The other option for big-endian testing on Intel little-endian laptop is running an IBM mainframe Linux eg. Debian or RedHat S390 on the Hercules emulator.

http://www.hercules-390.org/
1376  Bitcoin / Wallet software / Re: [ANNOUNCE] picocoin and libccoin -- C-based bitcoin library and client on: December 01, 2012, 06:37:27 PM
The frequent invocations of RedHat upthread are weird and misplaced.  _I_ did the initial BE testing for Jeff. Lots of people have access to BE systems and pretty much anyone who wants to can have access to one (for a couple bucks on ebay if nothing else).  ... but nothing Jeff is doing makes handling the endlessness hard as directly evidenced by the fact that he got it running fine on BE without using one.  Your 'solution' of pushing unions everywhere for that is an odd one and I'm happy to not work on your codebase.

Now that you've made your numerous complaints would you please cut it out? The tangent is going nowhere. If you want bitcoin software written to your particular, and somewhat odd, specifications feel free to do so yourself or to pay someone to do so.
I apologize for misattributing anyone's work. I didn't actually read the commit log. From the way you wrote I have to assume that Jeff did 100% of work and you did 100% of testing. It doesn't really matter who did what, so long as it is getting done at a reasonable frequency.

The "somewhat odd" comment is really strange. It is the standard way to strenghten the C type system from structural equivalence to name equivalence. The type systems taxonomy is the standard curriculum of pretty much every CS or SE course at the university level. In fact the C++ code I posted above is patterned after the sample C/C++ code and a paper that was included with the "cfront" C++ compiler distribution from Bjarne Stroustrup that I've seen on some dusty VAX at my school. I didn't claim the autorship and in fact the requirement of not overusing type-cast-ing is one of the standard admonishments in the C/C++ project specifications.

On the other hand the 1995-1997 copyright dates on glib.h show that the base GTK/GNOME code was designed during the darkest days of GCC, predating the EGCS fork: http://en.wikipedia.org/wiki/GNU_Compiler_Collection#EGCS_fork . At that time GCC was widely used as a baseline: it would reliably produce largest and slowest code after taking the longest time to build it; so almost anything looked better in comparison. From what I've heard from one of the Linux distribution maintainers was that many sub-optimal choices in open source packages were motivated by the desire to avoid tripping up GCC to produce very slow or incorrect code. Those days are long gone.

It really doesn't take an advanced computer science education to understand why poking holes in C/C++ type system by using unsafe casts is not a good architectural choice. It may be a good short term choice. Open source projects thrive on finding a group of people who while "scratching their own itch" actually scratch in the same place. It may well be the truth that many programmers here enjoy lookin at every uint32 and ponder wheteher to use it directly or through GUINT32_{TO,FROM}_LE macros.

I also know from the past experience that overall such people are not a majority, and would consider the above task a software engineering equivalent of digging diteches and filling them back in. For every one person who posted here there is at least 10 who read this thread with understanding. Of those 10 at least 2-3 will copy/paste the example code I wrote for a future reference.

So, yes, go ahead and play with the following somewhat longer example C code. Modify it to make mistakes and see which way is better for yourself.
Code:
#include <stdio.h>
#ifdef _MSC_VER
#include <stdlib.h>
#define inline __inline
#define __builtin_bswap32 _byteswap_ulong
#endif
#ifdef __GNUC__
#define _byteswap_ulong __builtin_bswap32
#endif
/*
 * type safe little endian
 */
union le_int {
unsigned char b[4];
int i;
};
/* little endian setter on little endian host */
static inline union le_int h2l_int(int a)
{
union le_int t;

t.i = a;
return t;
}
/* little endian getter on little endian host */
static inline int l2h_int(union le_int a)
{
return a.i;
}
/*
 * type safe big endian
 */
union be_int {
unsigned char b[4];
int i;
};
/* big endian setter on little endian host */
static inline union be_int h2b_int(int a)
{
union be_int t;

t.i = _byteswap_ulong(a);
return t;
}
/* big endian getter on little endian host */
static inline int b2h_int(union be_int a)
{
return _byteswap_ulong(a.i);
}

/* excerpted from the Glib.h include tree */
typedef unsigned int guint32;
typedef signed int gint32;
#define GUINT32_SWAP_LE_BE(val) ((guint32) __builtin_bswap32 ((gint32) val))
#define GINT32_TO_LE(val) ((gint32) (val))
#define GINT32_TO_BE(val) ((gint32) GUINT32_SWAP_LE_BE (val))
#define GINT32_FROM_LE(val) (GINT32_TO_LE (val))
#define GINT32_FROM_BE(val) (GINT32_TO_BE (val))
/* end of Glib.h excerpt */

/* little endian type unsafe */
int lehmer1(int n)
{
int r = GINT32_TO_LE(1);

while (n--)
r = GINT32_TO_LE((16807 * GINT32_FROM_LE(r)) % 2147483647);
return GINT32_FROM_LE(r);
}
/* little endian type safe */
int lehmer2(int n)
{
union le_int r = h2l_int(1);

while (n--)
r = h2l_int((16807 * l2h_int(r)) % 2147483647);
return l2h_int(r);
}
/* big endian type unsafe */
int lehmer3(int n)
{
int r = GINT32_TO_BE(1);

while (n--)
r = GINT32_TO_BE((16807 * GINT32_FROM_BE(r)) % 2147483647);
return GINT32_FROM_BE(r);
}
/* big endian type safe */
int lehmer4(int n)
{
union be_int r = h2b_int(1);

while (n--)
r = h2b_int((16807 * b2h_int(r)) % 2147483647);
return b2h_int(r);
}

int main()
{
printf("%d\n",lehmer1(2112));
printf("%d\n",lehmer2(2112));
printf("%d\n",lehmer3(2112));
printf("%d\n",lehmer4(2112));
return 0;
}
1377  Bitcoin / Project Development / Re: Hiring C++ and JS programmers on: December 01, 2012, 04:34:30 PM
Ripple sounds like something an economist designed (a compliment). It is really clever, but it may not make sense to ordinary people. Good marketing seems really important here.
It is a software re-implementation of the century-old paper credit certificates, called wechsel (in German) http://de.wikipedia.org/wiki/Wechsel_(Urkunde) and similar in many European languages. Vexel would the a probable Anglophone equivalent pronunciation.

Do not click on Wikipedia for English translation, because the "promisory note" is not an equivalent. It would take a longer discussion to explain why, but the root of it is in the difference between adversarial and inquisitorial law systems.

Anyway, if you know any Ashkenazi Jew who did business in Europe in the past century you can get first-hand account of the advantages and the drawbacks.
1378  Bitcoin / Wallet software / Re: [ANNOUNCE] picocoin and libccoin -- C-based bitcoin library and client on: November 28, 2012, 10:17:40 AM
Removing the GLib dependency is straightforward for any developer.  GLib is used for a few ADTs like variable length strings, hash tables and arrays.

Not sure you understand the problem space...  First, newlib is wholly different from GLib, and does not provide the ADTs that GLib provides.  Second, replacing GLib and OpenSSL would not change resource usage much at all.  ADTs, Big Integer support, SHA hashing and ECDSA are required regardless of lib chosen.  They would simply be replaced with...  code that did the same thing under name other than "OpenSSL" or "GLib."

If I don't understand the problem space then you don't understand the solution space. GLib's ADT heavily depend on glibc-style memory allocation and both depend on GCC extensions and cross-compiling with MinGW instead of Visual Studio or any other native Windows compiler.

Both GLib and OpenSSL are extremely resource intensive and the only way to get respectable performance out of them is by running on a host with paging MMU and TLB. This excludes majority of standalone / lightweight OSes.

The problem/solution space doesn't demand OpenSSL. It requires BigNums, ECDSA, SHA-256. Any multiuser OS is just a serious hindrance for an lightweight implementation on a lean hardware. All those tasks are best performed not on the main CPU but on the attached GPU or DSP array. When the GPU can be directly called without the overhead of going through OpenGL/OpenCL the whole new world of possibilities opens up. As far as I know currently only PowerVR GPUs have an open source toolchain. This means Texas Instruments OMAP chips. In a year or two probably someone will do the same for the Broadcom VideoCore chips in Raspberry Pi. The performance and power efficiency gained from MIMD implemenations will be immense.

It will soon be building on MacOSX and Windows.
The salient point for Windows is: is it going to be possible to build it using a native Windows compiler like Visual Studio, OpenWATCOM or Borland/Embarcadero? Because another MinGW-only deliverable will be impossible to integrate into the Windows ecosystem.
1379  Bitcoin / Wallet software / Re: [ANNOUNCE] picocoin and libccoin -- C-based bitcoin library and client on: November 28, 2012, 06:22:56 AM
It continues to be true for all known compilers I've seen or heard of, when compared with a simple, native machine integer as used by the current implementation.
OK, show of hands. You must have heard of the existience of Microsoft Visual Studio C++/C compiler. I wrote a short test program that tests strong-typed little-endian integer on the Intel architecture, which will be the most important case.
Code:
#include <cstdio>

union le_int {
unsigned char b[4];
int i;
void operator =(int a) { i = a; }
operator int() { return i; }
};

int lehmer1(int n)
{
int r = 1;
while (n--)
r = (16807 * r) % 2147483647;
return r;
}

int lehmer2(int n)
{
union le_int r;

r = 1;
while (n--)
r = (16807 * r) % 2147483647;
return r;
}

void main()
{
printf("%d\n",lehmer1(2112));
printf("%d\n",lehmer2(2112));
}

and the generated "Release Win32" code, with everything at default:

Code:
00311000  push        edi  
printf("%d\n",lehmer1(2112));
00311001  mov         ecx,840h 
00311006  mov         edx,1 
0031100B  mov         edi,7FFFFFFFh 
00311010  imul        edx,edx,41A7h 
00311016  mov         eax,edx 
00311018  cdq 
00311019  idiv        eax,edi 
0031101B  dec         ecx 
0031101C  jne         main+10h (0311010h) 
0031101E  push        edx 
0031101F  push        312100h 
00311024  call        dword ptr ds:[312090h] 
0031102A  add         esp,8 
printf("%d\n",lehmer2(2112));
0031102D  mov         ecx,840h 
00311032  mov         edx,1 
00311037  imul        edx,edx,41A7h 
0031103D  mov         eax,edx 
0031103F  cdq 
00311040  idiv        eax,edi 
00311042  dec         ecx 
00311043  jne         main+37h (0311037h) 
00311045  push        edx 
00311046  push        312100h 
0031104B  call        dword ptr ds:[312090h] 
00311051  add         esp,8

Could anyone here can give an example of a popular compiler that produces different code for those two little functions? Maybe the test program needs to be somehow changed to trip up the optimizer? I'm seriously asking. I have code like this (and pure C equivalent with #define macros instead of operators()) in wide deployment for many years now on a variety of platforms.

I really only have my Windows laptop with me. I would have to ask people to unpack and boot my usual development environment for remote access.

Meanwhile I'm going to see if I can trip-up the Visual Studio somehow by rewriting this code in various ways.
1380  Bitcoin / Development & Technical Discussion / Re: BIP 2112 on: November 28, 2012, 02:20:10 AM
I assume he means a prospectus embedded in the genesis block. So a new block chain would be a sort of IPO with the contract locked in  forevermore.
Well, not "locked forevermore". The only thing locked like this is "root prospectus". Every implementation would need to support "prospectus ammendments" that form tree branches. So every "digital security" is defined by a pair (hash(root prospectus),hash(tip of branch steming from the root)).

http://en.wikipedia.org/wiki/Tree_(data_structure)

Edit: I guess the point of this can be summarized: it makes the changes to the algorithms explicit and verifiable in linear time, very much like git does to any general source code.

Edit2: Also, like git and like normal securities exchanges this will allow for orderly and verifiable backtracking and reversal, once the "economic majority" decides that certain branch of the prospectus was erroneous, fraudulent or otherwise undesired.
Pages: « 1 ... 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 [69] 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!