Bitcoin Forum
December 08, 2016, 12:18:19 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
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 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 ... 60 »
  Print  
Author Topic: [announce] Namecoin - a distributed naming system based on Bitcoin  (Read 319978 times)
memvola
Hero Member
*****
Offline Offline

Activity: 896


View Profile
April 23, 2011, 01:19:32 AM
 #101


P2P DNS based on bitcoin's proof-of-work notary service will look a bit different.

How?

1.  Is there a full spec somewhere?

I was just toying with bind and value fields for domain entries. The idea is to start using these domains right away through a DNS bridge. I'm not an expert on DNS nor bitcoin but here are my random thoughts... Smiley

First, I don't know if the value field can or should be binary. I'd insist on expecting gzipped zone files by default, but we can also detect that from the header even under base64 (which isn't extremely economical). If we can agree that zone files could be used for everything (i2p, tor, freenet, some future wireless mesh system) then this could be the standard. Otherwise we also need a header. I for one haven't figured how simple delegation would work with a zone file. Maybe a different specification would be more appropriate.

DNS servers can report arbitrary data (at least as CNAME or TXT records), but resolvers seem to expect IP, so I was unable to successfully use a DNS server to map names to, for instance, .onion adresses. I'm hoping someone less ignorant about resolvers will come up with an idea. Is introducing a class other than IN a good idea? There could also be privacy concerns in the case of a DNS bridge.

Also, I'm guessing the zone file will need to know the TLD in order to work properly under an ordinary DNS server. So we also need to decide on the default TLD. dmp1ce's proposal/question about arbitrary TLDs should be answered at this point. What are the options?

  • A default TLD, like .bit, dictated by the system.
  • No default TLD, current registered names act as TLDs. Also arbitrary TLDs are allowed, like d/example.weird
  • One default TLD, and arbitrary TLDs allowed in one of these forms: d/example.weird, dweird/example, d/example/weird, d/weird.example, ?
  • Multiple TLDs, dictated by the specification. There is currently only one, but developers may decide to introduce new ones via the application specifier.
  • ?
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481199499
Hero Member
*
Offline Offline

Posts: 1481199499

View Profile Personal Message (Offline)

Ignore
1481199499
Reply with quote  #2

1481199499
Report to moderator
1481199499
Hero Member
*
Offline Offline

Posts: 1481199499

View Profile Personal Message (Offline)

Ignore
1481199499
Reply with quote  #2

1481199499
Report to moderator
1481199499
Hero Member
*
Offline Offline

Posts: 1481199499

View Profile Personal Message (Offline)

Ignore
1481199499
Reply with quote  #2

1481199499
Report to moderator
xf2_org
Member
**
Offline Offline

Activity: 70


View Profile
April 23, 2011, 02:30:01 AM
 #102


P2P DNS based on bitcoin's proof-of-work notary service will look a bit different.

How?

See satoshi's posts (recently reposted and collected by noagendamarket).

memvola
Hero Member
*****
Offline Offline

Activity: 896


View Profile
April 23, 2011, 02:40:34 PM
 #103

You won't get the name until at least 12 blocks after the block name_new went through on.  You should get it if you didn't get an error.  I have gotten all of mine.

I missed two of them even though I got no error and no one else had attempted to get the same ones. Apart from the other failures I've mentioned before.
vinced
Newbie
*
Offline Offline

Activity: 23


View Profile
April 23, 2011, 10:28:37 PM
 #104

Status

As I'm writing this, we are at block 559.  Generation is about 10 minutes per block so the difficulty is right on target.  181 domains registered.

Economics

Some good points were raised regarding the economics of the system.  Here are my thoughts.  As the code is now the network fees become negligible in a couple of years and only the regular transaction fees remain.  Miners will charge transaction fees based on the cost of processing and competition.

Beyond that, some names are more valuable than others because of marketing reasons.  Some miners might try to charge more to update valuable names.  Some names will be registered early and sold in marketplaces.

It seems that all these dynamics will result in some kind of equilibrium, but it is difficult to tell what it will be.

It's not clear how miners will choose tx fees.  The maximum that a domain holder might need to spend to renew their domain is the equivalent to the average miner revenue from a block.  This comes out to 50 NC + 5000 times the average domain tx fee if there are 5000 tx per block.  This is how much it would cost them to generate a block themselves.  The owner of sex.bit might experience this.

As to the total number of names supported by the system, max bitcoin block size is now 1MB, average tx size might be 200, renewal period is 12000 blocks and assume 2 updates per period. This gives 30M domains supported.  I feel this is too low and we'll have to raise the block size, either now or later.  Should we target 10 billion names?

DNS

I've been thinking more about representing values.  A zone file doesn't seem like a good solution after all.  For one, you can't do DNS delegation if you are behind Tor.  So I'm proposing JSON with optional gzip encoding.  Example:

  {'map': {'' : '127.0.0.1', 'y' : ['127.0.0.2','::2'], 'foo' : 'bar.com'}}

first case is an IPv4, second is IPv4 + IPv6, third glues to an existing domain.  In the third case, you translate foo.name.bit to foo.bar.com and resolve that.  It's close enough to delegation and works behind Tor.  We can extend this for mail exchange and other things as the need arises.

We do have to decide on a TLD strategy so people know what URL to tell their users.  Otherwise there will be inconsistent implementations and the end-users will get confused.

I propose resolving .bit, .b and .n, recommending that web sites expect virtual hosts under all three, but that people refer to .bit URLs for now.  This gives us some fallbacks if ICANN decides to use .bit for something else.  So if you register d/foo, you normally use https://foo.bit, but foo.n and foo.b also work.

@memvola - just saw your post about TLDs and you bring up some interesting ideas.  Maybe start with my proposal above and add TLDs later if it seems like the right thing?

Generation

The code is identical to bitcoin, with the amount halved every four years.  Some people seem to prefer constant generation?  Reasons?

@da2ce7 the initially high network fee will slow early domain squatting.

@memvola if you get a name clash, the losing transaction becomes a zombie and the wallet thinks you have less coins to spend.  This will be fixed soon, sorry that it ties up your NC.  As to the network fee, it was 50 at genesis and is already a bit lower.  It will be 25 after about 2 months.

@dmp1ce yes, updates are costless.  Also, if you update before the 12 are up, the tx will stick around until the 12th block comes.  It's no problem.

@0x6763 good point.  However, if there's a clash with ICANN, different users will see different sites for the same name.  Wouldn't it be better if clashes are avoided, at least until the system is stronger?  21 million NC will be created and some are lost to the decaying network fee.

@gavinandresen - I agree with your analysis.  There's no other discussion of the economics, other than this thread.

@xf2_org @noagendamarket - Namecoin is pretty close to what Satoshi described.  What significant differences do you see?  He did mention a renewal fee, but I don't see why that would be useful in addition to the tx fee set by the miner.

!v | Namecoin founder | https://dot-bit.org/
memvola
Hero Member
*****
Offline Offline

Activity: 896


View Profile
April 24, 2011, 03:34:31 AM
 #105

DNS

I've been thinking more about representing values.  A zone file doesn't seem like a good solution after all.  For one, you can't do DNS delegation if you are behind Tor.  So I'm proposing JSON with optional gzip encoding.  Example:

  {'map': {'' : '127.0.0.1', 'y' : ['127.0.0.2','::2'], 'foo' : 'bar.com'}}

first case is an IPv4, second is IPv4 + IPv6, third glues to an existing domain.  In the third case, you translate foo.name.bit to foo.bar.com and resolve that.  It's close enough to delegation and works behind Tor.  We can extend this for mail exchange and other things as the need arises.

I couldn't quite figure out what all the use cases could be. I'll give it a try, but take it with a grain of salt. Smiley

In the majority of cases, people (I assume from skimming through the other threads) would want it to work as a domain name registry. It would be a drop-in replacement for Wikileaks people (or me) for instance. For these cases, both public and local (namecoind?) DNS bridges would forward queries to the specified primary master server. In effect, it's identical to adding the below zone statement to named.conf:

Code:
zone "example.bit" {
        type forward;
        forward only;
        forwarders { ns1.examplehost.net; ns2.examplehost.net; };
};

So, whatever the format, they will supply two name servers and nothing else. In the Tor case, it's up to the exit node to resolve example.bit. I don't think it would be feasible to try to forward the request from behind Tor (I tried it through the proxy without success, but I might be missing something). I'm assuming namecoind would also act as a DNS server. Please correct me because I'm making a wild guess here. Smiley

Some people might want it to act as a master server by supplying a zone file. Below is an example.

Code:
$TTL 1W
$ORIGIN example.bit.
@       IN      SOA     localhost. hostmaster.example.bit. (
2011042222
8H
4H
                        1W
1D )
TXT "We could abuse some types of records."
NS localhost.
A 74.125.113.147
AAAA 2001:4860:0:1001::68
      MX 10 mail99.mailer.bit.
www CNAME @
mail CNAME mail99.mailer.bit.
onion CNAME eqt5g4fuenphqinx.onion.

This should almost be the same in effect to your Json example, so both formats would do the deed. I'm rather confused by your example though, because if namecoind will indeed act as a DNS server, to my knowledge, it should forward the foo.bar.com query through the proxy. Maybe even namecoind will be a proxy itself?

I put the onion record there as a naive example but it wouldn't/shouldn't work that way. It shouldn't even be in the IN class. I'm not sure there is a way that would cover all non-ip networks. For freenet for instance, http redirection could work. For tor/i2p, a local resolver could catch query results and treat them appropriately. Again, if there will be a namecoin proxy, it might solve these issues.

I propose resolving .bit, .b and .n, recommending that web sites expect virtual hosts under all three, but that people refer to .bit URLs for now.  This gives us some fallbacks if ICANN decides to use .bit for something else.  So if you register d/foo, you normally use https://foo.bit, but foo.n and foo.b also work.

@memvola - just saw your post about TLDs and you bring up some interesting ideas.  Maybe start with my proposal above and add TLDs later if it seems like the right thing?

I get the reasoning but wouldn't it be confusing? It could be after many years that ICANN decides to use .bit and by then, every record would need to use each and every TLD, just in case. Maybe we need to find something ICANN wouldn't pick. Smiley

As for adding new TLDs later, I think it's the sanest choice. But this in turn gives some more authority to the developers, that's why I think some people don't like the idea.

@memvola if you get a name clash, the losing transaction becomes a zombie and the wallet thinks you have less coins to spend.  This will be fixed soon, sorry that it ties up your NC.

There's also the cases where a clash hasn't occured but names don't show in name_scan. I can give a more detailed report if it's not the same issue.
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
April 24, 2011, 06:53:48 AM
 #106

I  am disappointed in not seeing a great deal of activity in your repository. I know it's a voluntary project and all...

Are you busy or something?

dmp1ce
Member
**
Offline Offline

Activity: 69


View Profile WWW
April 24, 2011, 10:16:14 AM
 #107

Generation

The code is identical to bitcoin, with the amount halved every four years.  Some people seem to prefer constant generation?  Reasons?
My only thought was that the amount of money in the system can be a limiting factor on the number of domains possible.  I have not done the math to see if this could be the case.  Or if it is always the case that domains are limited by the block size.

I guess it is not a big deal because plenty of coins will be generated within the next 8 to 12 years, but I'm wondering what I'll happen later if there are no more extra coins to afford to buy new domains?  Again I suppose the rate could be changed to constant if this becomes a problem, so it isn't a big problem.

It likely makes NC rarer than BTC however since NC is getting clobbered by the name_firstupdate commands.  It may end up that NC is more valuable than BTC or even the domain names themselves.  I just hadn't thought that the system would intend to make the Namecoin currency valuable in the same way Bitcoin does, but I think it could work.

BTCmon - Support great bitcoin apps
FnuGk
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 24, 2011, 03:56:16 PM
 #108

could someone explain exactly what is this?
is it just a a bitcoin clone using another blockchain or what is it?

also give me a OS X binary so i can run this thing Smiley

My bitcoin address if you feel like giving things away Smiley
1NvURSqNqFUX1g4xAJe5xzBJYRkMSCyXqk
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
April 24, 2011, 03:59:59 PM
 #109

could someone explain exactly what is this?
is it just a a bitcoin clone using another blockchain or what is it?

also give me a OS X binary so i can run this thing Smiley

It's a distributed domain name registration system that use bitcoin technology, meant to solve the takedown problem.

FnuGk
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 24, 2011, 04:03:51 PM
 #110

could someone explain exactly what is this?
is it just a a bitcoin clone using another blockchain or what is it?

also give me a OS X binary so i can run this thing Smiley

It's a distributed domain name registration system that use bitcoin technology, meant to solve the takedown problem.

this confuses me anymore. what does domain names have to do with anything?

My bitcoin address if you feel like giving things away Smiley
1NvURSqNqFUX1g4xAJe5xzBJYRkMSCyXqk
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
April 24, 2011, 04:06:04 PM
 #111


this confuses me anymore. what does domain names have to do with anything?

It have everything to do with namecoins.

The problem: Damn guberments can take down any domain name they like.

The solution: Those evil guberments can't take down namecoin domains because it's distributed.

kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
April 24, 2011, 04:28:17 PM
 #112

I am unable to run bitcoind and namecoind at the same time. Has anybody have that issue?

FnuGk
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 24, 2011, 04:30:15 PM
 #113

So im trying to compile it.

i am following the guide for bitcoin that comes with the source code but instead of checking out from the svn as the guide tells me i am putting the namecoin source in the "trunks" folder.

am i doinng it right?

My bitcoin address if you feel like giving things away Smiley
1NvURSqNqFUX1g4xAJe5xzBJYRkMSCyXqk
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
April 24, 2011, 04:31:19 PM
 #114

So im trying to compile it.

i am following the guide for bitcoin that comes with the source code but instead of checking out from the svn as the guide tells me i am putting the namecoin source in the "trunks" folder.

am i doinng it right?
Huh

Namecoin is in a git repository.

FnuGk
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 24, 2011, 04:34:53 PM
 #115

So im trying to compile it.

i am following the guide for bitcoin that comes with the source code but instead of checking out from the svn as the guide tells me i am putting the namecoin source in the "trunks" folder.

am i doinng it right?
Huh

Namecoin is in a git repository.

downloaded the namecoin source from github unzipped it and put it in the trunks folder.

how else should this be compiled?? (i am no programmer and have no idea what im doing besides following the manual)

My bitcoin address if you feel like giving things away Smiley
1NvURSqNqFUX1g4xAJe5xzBJYRkMSCyXqk
kiba
Legendary
*
Offline Offline

Activity: 980


View Profile
April 24, 2011, 04:39:30 PM
 #116

downloaded the namecoin source from github unzipped it and put it in the trunks folder.

how else should this be compiled?? (i am no programmer and have no idea what im doing besides following the manual)

Trunks folder?  Huh

FnuGk
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 24, 2011, 04:42:44 PM
 #117

downloaded the namecoin source from github unzipped it and put it in the trunks folder.

how else should this be compiled?? (i am no programmer and have no idea what im doing besides following the manual)

Trunks folder?  Huh

this is the guide i am following. I am changing bitcoin to namecoin and then instead of the first step of checking the bitcoin source out from svn i am putting the namecoin source in the same folder:
Code:
Copyright (c) 2010 Laszlo Hanyecz
Distributed under the MIT/X11 software license, see the accompanying
file license.txt or http://www.opensource.org/licenses/mit-license.php.
This product includes software developed by the OpenSSL Project for use in
the OpenSSL Toolkit (http://www.openssl.org/).  This product includes
cryptographic software written by Eric Young (eay@cryptsoft.com).


Mac OS X build instructions
Laszlo Hanyecz (solar@heliacal.net)


Tested on 10.5 and 10.6 intel.  PPC is not supported because it's big-endian.

All of the commands should be executed in Terminal.app.. it's in
/Applications/Utilities

You need to install XCode with all the options checked so that the compiler
and everything is available in /usr not just /Developer
I think it comes on the DVD but you can get the current version from
http://developer.apple.com


1.  Pick a directory to work inside.. something like ~/bitcoin works.  The
structure I use looks like this:
(~ is your home directory)

~/bitcoin
~/bitcoin/trunk         # source code
~/bitcoin/deps          # dependencies.. like libraries and headers needed to compile
~/bitcoin/Bitcoin.app   # the application bundle where you can run the app

Just execute: mkdir ~/bitcoin
This will create the top dir for you..

WARNING: do not use the ~ notation with the configure scripts.. use the full
name of the directory, for example /Users/james/bitcoin/deps for a user named
'james'.  In my examples I am using 'macosuser' so make sure you change that.

2.  Check out the trunk version of the bitcoin code from subversion:

cd ~/bitcoin
svn checkout https://bitcoin.svn.sourceforge.net/svnroot/bitcoin/trunk

This will make ~/bitcoin/trunk for you with all the files from subversion.

3.  Get and build the dependencies


Boost
-----

Download from http://www.boost.org/users/download/
I'm assuming it ended up in ~/Downloads..

mkdir ~/bitcoin/deps
cd ~/bitcoin/deps
tar xvjf ~/Downloads/boost_1_42_0.tar.bz2
cd boost_1_42_0
./bootstrap.sh
./bjam architecture=combined address-model=32_64 macosx-version=10.6 macosx-version-min=10.5 link=static runtime-link=static --toolset=darwin --prefix=/Users/macosuser/bitcoin/deps install

This part takes a while.. use your judgement and fix it if something doesn't
build for some reason.

Change the prefix to whatever your directory is (my username in this example
is macosuser).  I'm also running on 10.6 so i have macosx-version=10.6  change
to 10.5 if you're using leopard.

This is what my output looked like at the end:
...failed updating 2 targets...
...skipped 144 targets...
...updated 8074 targets...


OpenSSL
-------

Download from http://www.openssl.org/source/

We would like to build this as a 32 bit/64 bit library so we actually build it
2 times and join it together here..  If you downloaded with safari it already
uncompressed it so it will just be a tar not a tar.gz

cd ~/bitcoin/deps
tar xvf ~/Downloads/openssl-1.0.0.tar
mv openssl-1.0.0 openssl-1.0.0-i386
tar xvf ~/Downloads/openssl-1.0.0.tar
mv openssl-1.0.0 openssl-1.0.0-x86_64
# build i386 (32 bit intel) binary
cd openssl-1.0.0-i386
./Configure --prefix=/Users/macosuser/bitcoin/deps --openssldir=/Users/macosuser/deps/openssl darwin-i386-cc && make
make install # only do this on one of the architectures, to install the headers
cd ..
# build x86_64 (64 bit intel) binary
cd openssl-1.0.0-x86_64
./Configure --prefix=/Users/macosuser/bitcoin/deps --openssldir=/Users/macosuser/deps/openssl darwin64-x86_64-cc && make
cd ..

# combine the libs
cd ~/bitcoin/deps
lipo -arch i386 openssl-1.0.0-i386/libcrypto.a -arch x86_64 openssl-1.0.0-x86_64/libcrypto.a -o lib/libcrypto.a -create
lipo -arch i386 openssl-1.0.0-i386/libssl.a -arch x86_64 openssl-1.0.0-x86_64/libssl.a -o lib/libssl.a -create

Verify your binaries

file lib/libcrypto.a

output should look like this:

ib/libcrypto.a: Mach-O universal binary with 2 architectures
lib/libcrypto.a (for architecture i386): current ar archive random library
lib/libcrypto.a (for architecture x86_64): current ar archive random library


Berkeley DB
-----------

Download from http://freshmeat.net/projects/berkeleydb/

cd ~/bitcoin/deps
tar xvf ~/Downloads/db-4.8.26.tar
cd db-4.8.26/build_unix
../dist/configure --prefix=/Users/macosuser/bitcoin/deps --enable-cxx && make && make install


wxWidgets
---------

This is the big one..

Check it out from svn

cd ~/bitcoin/deps
svn checkout http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk wxWidgets-trunk

This will make a wxWidgets-trunk directory in deps.

Use this script snippet, change your prefix to whatever your dir is:

PREFIX=~/bitcoin/deps
SRCDIR="$PREFIX/wxWidgets-trunk"
BUILDDIR="$SRCDIR/macbuild"

cd "$PREFIX" &&
#svn checkout http://svn.wxwidgets.org/svn/wx/wxWidgets/trunk wxWidgets-trunk &&
cd "$SRCDIR" &&

[ -f include/wx/hashmap.h.orig ] || cp include/wx/hashmap.h include/wx/hashmap.h.orig &&
sed 's/if wxUSE_STL/if 0 \&\& wxUSE_STL/g' < include/wx/hashmap.h.orig > include/wx/hashmap.h &&

[ -f include/wx/hashset.h.orig ] || cp include/wx/hashset.h include/wx/hashset.h.orig &&
sed 's/if wxUSE_STL/if 0 \&\& wxUSE_STL/g' < include/wx/hashset.h.orig > include/wx/hashset.h &&



rm -vrf "$BUILDDIR" &&
mkdir "$BUILDDIR" &&
cd "$BUILDDIR" &&

../configure --prefix="$PREFIX" \
--with-osx_cocoa \
--disable-shared \
--disable-debug_flag \
--with-macosx-version-min=10.5 \
--enable-stl \
--enable-utf8 \
--enable-universal_binary \
--with-libjpeg=builtin \
--with-libpng=builtin \
--with-regex=builtin \
--with-libtiff=builtin \
--with-zlib=builtin \
--with-expat=builtin \
--with-macosx-sdk=/Developer/SDKs/MacOSX10.5.sdk &&


find . -name Makefile |
while read i; do
  echo $i;
  sed 's/-arch i386/-arch i386 -arch x86_64/g' < "$i" > "$i".new &&
  mv "$i" "$i".old &&
  mv "$i".new "$i";
done



make &&
make install



Now you should be able to build bitcoin

cd ~/bitcoin/trunk
make -f makefile.osx bitcoin

Before you can run it, you need to create an application bundle for Mac OS.
Create the directories in terminal using mkdir and copy the files into place.
They are available at http://heliacal.net/~solar/bitcoin/mac-build/
You need the Info.plist and the .ins file.  The Contents/MacOS/bitcoin file is
the output of the build.
Your directory structure should look like this:

Bitcoin.app
Bitcoin.app/Contents
Bitcoin.app/Contents/Info.plist
Bitcoin.app/Contents/MacOS
Bitcoin.app/Contents/MacOS/bitcoin
Bitcoin.app/Contents/Resources
Bitcoin.app/Contents/Resources/BitcoinAppIcon.icns

To run it you can just click the Bitcoin.app in Finder, or just do open
~/bitcoin/Bitcoin.app
If you want to run it with arguments you can just run it without backgrounding
by specifying the full name in terminal:
~/bitcoin/Bitcoin.app/Contents/MacOS/bitcoin -addnode=192.75.207.66

My bitcoin address if you feel like giving things away Smiley
1NvURSqNqFUX1g4xAJe5xzBJYRkMSCyXqk
dmp1ce
Member
**
Offline Offline

Activity: 69


View Profile WWW
April 24, 2011, 07:14:12 PM
 #118

Here is a Windows binary that works as far as I can tell.  I make no guarantees!  http://dl.dropbox.com/u/2882613/Namecoin/namecoin-win32-4-24-2011.zip

The source is included there and I'll upload my source to github here: https://github.com/dmp1ce/namecoin  I made very minor changes just to get things compiling.

To run it I ran namecoind.exe in a cmd.exe terminal and then opened another cmd.exe terminal to run namecoind.exe commands like getinfo.  No GUI yet.

Happy rabbit egg day!

BTCmon - Support great bitcoin apps
LZ
Staff
Legendary
*
Offline Offline

Activity: 1456


Satoshi everywhere!


View Profile WWW
April 24, 2011, 07:42:13 PM
 #119

dmp1ce, can you build it with the static linking? But thank you anyway! Smiley

also give me a OS X binary so i can run this thing Smiley
I think that we can just ask laszlo to build it. Smiley

"Never invest unless you can afford to lose your entire investment." © S3052
FnuGk
Jr. Member
*
Offline Offline

Activity: 55


View Profile
April 24, 2011, 08:03:14 PM
 #120

cant the op be edited with links to the binary's posted around in this thread?

My bitcoin address if you feel like giving things away Smiley
1NvURSqNqFUX1g4xAJe5xzBJYRkMSCyXqk
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 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 ... 60 »
  Print  
 
Jump to:  

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!