Bitcoin Forum
June 21, 2024, 02:53:30 PM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 »
1  Bitcoin / Development & Technical Discussion / What's a good library to implement an incomplete node that connects to others? on: January 11, 2015, 10:12:17 PM
What's a good library that implements the Bitcoin protocol that would allow me to make an incomplete node that connects to other nodes and just receives the new transactions?

I know there are half-node implementations out there but they are either not working or they are outdated with the current state of the protocol. Python, C/C++, Go... any language would work.

I'm not talking about the JSON-RPC API. I'm talking about the protocol that Bitcoin nodes use to talk to each other.
2  Bitcoin / Development & Technical Discussion / Re: As a developer, what's the best way to accept BTC without using third-parties on: November 24, 2014, 07:22:09 AM
Not meant to be trustless?  Bitcoinj was trustless i thought it connects to peers and not some random api on the net unless its for a price feed which is irrelevent. What do u mean by this?

It connects to peers but it doesn't verify blocks like bitocoin-core does, as well as bitcoinj doesn't have the entire blockchain. Without those two things you can't be trustless. SPV are just meant to get your unspent outputs, sign transactions and broadcast your transactions. Bitcoin-core actually keeps the network healthy by verifying blocks.

Now you can make it trustless by running your own bitcoin-core and have bitcoinj only connect that.


@gmaxwell This shows how much work we work we have to do as a community as people don't understand the important differences. I know you are probably going to say "People don't need to know how it works" but having the different levels of security laid out can't hurt.

Bitcoinj actually supports full verification at this point given you use the PostgresFullPrunedBlockStore or MySQLFullPrunedBlockStore as your BlockStore.

Bitcoinj has two modes it has SPV and full verification. I clearly stated the SPV mode in all my post.

To be honest though I don't think bitcoinj's full verification passes all the test. I don't know haven't really looked at the project much in the last year.

Yeah, I understand that the SPV mode is different and that you were referring to that. No problems there. Smiley

As far as I know, BitcoinJ's full verification passes all the tests. I know it used to not but now it does. The initial syncing process is very slow, though. After reaching the Block #200000, it can only process less than two blocks per second, which is disconcerting.
3  Bitcoin / Development & Technical Discussion / Re: As a developer, what's the best way to accept BTC without using third-parties on: November 24, 2014, 07:08:36 AM
Not meant to be trustless?  Bitcoinj was trustless i thought it connects to peers and not some random api on the net unless its for a price feed which is irrelevent. What do u mean by this?

It connects to peers but it doesn't verify blocks like bitocoin-core does, as well as bitcoinj doesn't have the entire blockchain. Without those two things you can't be trustless. SPV are just meant to get your unspent outputs, sign transactions and broadcast your transactions. Bitcoin-core actually keeps the network healthy by verifying blocks.

Now you can make it trustless by running your own bitcoin-core and have bitcoinj only connect that.


@gmaxwell This shows how much work we work we have to do as a community as people don't understand the important differences. I know you are probably going to say "People don't need to know how it works" but having the different levels of security laid out can't hurt.

Bitcoinj actually supports full verification at this point given you use the PostgresFullPrunedBlockStore or MySQLFullPrunedBlockStore as your BlockStore.
4  Bitcoin / Development & Technical Discussion / Re: As a developer, what's the best way to accept BTC without using third-parties on: November 24, 2014, 12:15:28 AM
No, but you are concerned about scalability while I don't know what you are doing, that is the key word that I would use a 3rd party api. Lowest overhead and easiest to be scaling with.
"Scalability" is ultimately limited by the Bitcoin network, which-- by definition-- a Bitcoin full node can handle.  Interposing a 3rd party does not necessarily improve scalability-- it likely reduces it, especially since you're talking about unpaid services, so there is nothing to fund your utilization-- and using a third party service necessarily reduces security, more so than SPV, and necessarily adds additional points of failure: the reliability of third party blockchain services has been very low.

I'm sad to see that no one seems to have noticed the Baron link I gave above. It's a full order processing solution based on a local full node. It deserves more attention.

Baron looks very interesting. Looking into it right now.
5  Bitcoin / Development & Technical Discussion / Re: As a developer, what's the best way to accept BTC without using third-parties on: November 22, 2014, 11:35:20 PM
Hi,

I am a developer with a lot of experience in C++, Java and Python. I am familiar with BitcoinJ and similar frameworks that help you interact with the Bitcoin network.

I am trying to accept Bitcoin payments for a project and I would like to avoid using third-party services such as Blockchain's Payment API, Coinbase and BitPay.

I'm thinking of working with "btcd" or "Bitcoinj". I have a prototype that uses the PostgresFullPrunedBlockStore. It works perfectly except when the service is down for a while. It misses transactions and syncing the blockchain doesn't seem to help. I end up not getting notified of "relevant" transactions that occurred when my service was down, despite syncing the blockchain.

I do realize that I can easily interact with "bitcoind" using RPC and add new addresses but I don't want to rely on bitcoind for that. I'm thinking of potential scalability issues.

What do you think would be the right approach here? I'm hoping to come up with a generic solution so that I can open-source it and other people can integrate it into their own systems.

I have one potential solution in mind. Let me know if you see any problems with this.
Code:
1- Join the network, wait for new blocks from peers
2- Loop indefinitely and wait for new blocks from peers. Receive block N:
  2a- Look at the block, check the transactions included in the block, are they relevant?
  2b- If they are relevant, note the unspent output and store it (making the assumption that its inputs are valid, if they weren't, it wouldn't be included in the block and propagated? Is this a safe assumption to make?)
  2c- Sweep the address and send it to cold wallet
  2d- Increment the balance of the user

What's wrong in using a 3rd party API ?
its not trustless

Bitcoinj isn't trustless either Wink

Yes, it is not. It isn't unreasonable to trust some full-nodes you are running, though.
6  Bitcoin / Development & Technical Discussion / Re: As a developer, what's the best way to accept BTC without using third-parties on: November 20, 2014, 09:31:37 PM
I do not want to rely on a separate process. I want my daemon to be self reliant.
You should have mentioned up front that intentionally getting hax0red was part of the design requirements.

Some people don't have any idea how bitcoin works but they use their programming certificates as "I know everything yet I am still asking". Now I know why I left this forum for while.

Not sure if that is directed towards me but if it is, that's very uncalled for and childish. You can avoid this drama by not looking at threads with questions and moving on your way on your high horse.
7  Bitcoin / Development & Technical Discussion / Re: As a developer, what's the best way to accept BTC without using third-parties on: November 20, 2014, 04:04:15 PM
I do not want to rely on a separate process. I want my daemon to be self reliant.
You should have mentioned up front that intentionally getting hax0red was part of the design requirements.

Why do you think that this design would lead to a breach? I'm not going to be running everything else on it. It will just be a payment processor connected to the network and the database, keeping track of balances and transactions.

One issue I can see with it would be that we wouldn't run validation on the inputs. Receiving the new block from multiple nodes should fix that, though. They wouldn't have relayed the blocks if the transactions in it weren't valid. So I need 1 confirmation.
8  Bitcoin / Development & Technical Discussion / Re: As a developer, what's the best way to accept BTC without using third-parties on: November 20, 2014, 03:35:06 PM
Generate keys offline, put them in database table, check using an api, then you don't have worry about sweeping them.

Can't be any easier.

I think he wants to check without relying on an api to some third party service.
He want to validate the balances on his own by parsing the blockchain.
All the decent full node implementations have a good API that you can use locally.

API does not imply a third party service.

I do not want to rely on a separate process. I want my daemon to be self reliant. That's why I have been focusing on BitcoinJ.

My implementation is now a SPV. Instead of keeping track of all unspent outputs, it checks for transactions relevant to my addresses on each block and sweeps them. It seems to be working now but I need to test it further.
9  Bitcoin / Development & Technical Discussion / Re: As a developer, what's the best way to accept BTC without using third-parties on: November 18, 2014, 01:56:40 AM
so you do need to worry about outputs then.  Will you need to write a "balance check" function from scratch?
I assume you are running a full node.

I'm debating if I should run a full node or if I should code a "pretend" full node. Either way, you can assume that I can store the entire blockchain. I just don't want to store all the unspent outputs, but only the ones for my addresses. Because indexing unspent outputs for all addresses can get tedious and require up to 320GB of disk space.

I will likely need to write a balance check function from scratch. I was planning on using "PostgresFullPrunedBlockStore" from BitcoinJ and call calculateBalanceForAddress(Address) but they don't seem to have implemented this class well.
10  Bitcoin / Development & Technical Discussion / Re: As a developer, what's the best way to accept BTC without using third-parties on: November 18, 2014, 01:46:46 AM
best practice is not to re use addresses.  You get one transaction per address, and then you can sweep it.

Thanks but that's what I will be doing anyway. After sweeping, the address will be taken out of the "active_addresses" list and won't be checked ever again. This detail however doesn't make downtime any better. When the Bitcoin payment processing daemon is down, I won't be notified of the new transactions. BitcoinJ, when catching up with the blockchain, refuses to notify me of my transactions.
11  Bitcoin / Development & Technical Discussion / Re: As a developer, what's the best way to accept BTC without using third-parties on: November 17, 2014, 09:41:41 PM
I dont think you need to worry about peers, blocks, unspent outputs, etc.

Just generate a key/address pair , give the public address to your customer.
What's wrong with that?

I need to be able to programmatically check for the incoming transactions to that address and sweep all the unspent outputs. I am already planning on generating a key/address pair and give the public address to the customer.

I just need to have a reliable way to be notified of incoming transactions to that address. My current Bitcoinj setup notifies me and sweeps the transactions when notified. However, this only happens if my service is up and running when the user makes the transaction. If the service is down, the transactions go unnoticed and I don't get notified during the blockchain sync process.

I was using BlockChain and PostgresFullPrunedBlockStore, and I noticed that it wasn't populating the unspent outputs table. This was probably due to me using BlockChain instead of FullPrunedBlockChain. I refactored that into my code and now I am syncing again. Let's see what happens with that.
12  Bitcoin / Development & Technical Discussion / As a developer, what's the best way to accept BTC without using third-parties on: November 17, 2014, 09:11:23 PM
Hi,

I am a developer with a lot of experience in C++, Java and Python. I am familiar with BitcoinJ and similar frameworks that help you interact with the Bitcoin network.

I am trying to accept Bitcoin payments for a project and I would like to avoid using third-party services such as Blockchain's Payment API, Coinbase and BitPay.

I'm thinking of working with "btcd" or "Bitcoinj". I have a prototype that uses the PostgresFullPrunedBlockStore. It works perfectly except when the service is down for a while. It misses transactions and syncing the blockchain doesn't seem to help. I end up not getting notified of "relevant" transactions that occurred when my service was down, despite syncing the blockchain.

I do realize that I can easily interact with "bitcoind" using RPC and add new addresses but I don't want to rely on bitcoind for that. I'm thinking of potential scalability issues.

What do you think would be the right approach here? I'm hoping to come up with a generic solution so that I can open-source it and other people can integrate it into their own systems.

I have one potential solution in mind. Let me know if you see any problems with this.
Code:
1- Join the network, wait for new blocks from peers
2- Loop indefinitely and wait for new blocks from peers. Receive block N:
  2a- Look at the block, check the transactions included in the block, are they relevant?
  2b- If they are relevant, note the unspent output and store it (making the assumption that its inputs are valid, if they weren't, it wouldn't be included in the block and propagated? Is this a safe assumption to make?)
  2c- Sweep the address and send it to cold wallet
  2d- Increment the balance of the user
13  Bitcoin / Development & Technical Discussion / Re: sx command line utilities - Empower The Sysadmin With Bitcoin Tools on: November 04, 2014, 10:35:52 PM
hey so just an update as to what's going on:
- Obelisk has been renamed to libbitcoin-server and is undergoing lots of changes.
- libbitcoin has a new faster blockchain backend.
- SX is renamed to libbitcoin-explorer and has been improved.
we're still working on testing & improving the software, but once that's complete, there will be a new release.
sorry about all the troubles.

No problem at all, we really appreciate the work that you guys put into this. Do you know when we will have access to this new release? Is it already on GitHub?

Are you guys aware that obelisk-server's syncing routine stalls in certain cases? I had to write a script to make sure that obelisk processes at least 5 blocks per minute, and if that's not the case, restarts it in order to continue syncing.

I suspect this is happening due to the following error that's exposed to the user:

Code:
Failed to store transaction in mempool <Transaction-Hash>: Spent input not found
14  Bitcoin / Development & Technical Discussion / Re: sx command line utilities - Empower The Sysadmin With Bitcoin Tools on: November 03, 2014, 05:47:54 PM
Can someone kindly advise me what the issue is with Ubuntu 14 LTS installation? I'm a Ubuntu newbie but have followed the instructions and running sudo bash ./install-sx.sh file from / (root) always gives this install error:

Code:
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=c++11... yes
checking whether make supports nested variables... (cached) yes
checking --enable-testnet argument... no
checking for boostlib >= 1.20.0... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for SSL... yes
checking for CURL... yes
checking for libsecp256k1... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating include/bitcoin/Makefile
config.status: creating src/Makefile
config.status: creating libbitcoin.pc
config.status: executing depfiles commands
config.status: executing libtool commands
configure: WARNING: unrecognized options: --with-libsecp256k1
Making all in include/bitcoin
make[1]: Entering directory `/usr/local/src/libbitcoin-git/include/bitcoin'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/local/src/libbitcoin-git/include/bitcoin'
Making all in src
make[1]: Entering directory `/usr/local/src/libbitcoin-git/src'
  CXX      utility/ec_keys.lo
utility/ec_keys.cpp: In function 'libbitcoin::ec_point libbitcoin::secret_to_public_key(const ec_secret&, bool)':
utility/ec_keys.cpp:66:23: error: 'secp256k1_ecdsa_pubkey_create' was not declared in this scope
             compressed))
                       ^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_public_key(const ec_point&)':
utility/ec_keys.cpp:75:78: error: 'secp256k1_ecdsa_pubkey_verify' was not declared in this scope
     return secp256k1_ecdsa_pubkey_verify(public_key.data(), public_key.size());
                                                                              ^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_private_key(const ec_secret&)':
utility/ec_keys.cpp:81:60: error: 'secp256k1_ecdsa_seckey_verify' was not declared in this scope
     return secp256k1_ecdsa_seckey_verify(private_key.data());
                                                            ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_tweak_add(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:115:73: error: 'secp256k1_ecdsa_pubkey_tweak_add' was not declared in this scope
     return secp256k1_ecdsa_pubkey_tweak_add(a.data(), a.size(), b.data());
                                                                         ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:121:73: error: 'secp256k1_ecdsa_pubkey_tweak_mul' was not declared in this scope
     return secp256k1_ecdsa_pubkey_tweak_mul(a.data(), a.size(), b.data());
                                                                         ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_add(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:127:64: error: 'secp256k1_ecdsa_privkey_tweak_add' was not declared in this scope
     return secp256k1_ecdsa_privkey_tweak_add(a.data(), b.data());
                                                                ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:133:64: error: 'secp256k1_ecdsa_privkey_tweak_mul' was not declared in this scope
     return secp256k1_ecdsa_privkey_tweak_mul(a.data(), b.data());
                                                                ^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_public_key(const ec_point&)':
utility/ec_keys.cpp:76:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_private_key(const ec_secret&)':
utility/ec_keys.cpp:82:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_tweak_add(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:116:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:122:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_add(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:128:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:134:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
make[1]: *** [utility/ec_keys.lo] Error 1
make[1]: Leaving directory `/usr/local/src/libbitcoin-git/src'
make: *** [all-recursive] Error 1
sim@ubuntu:/$ sx
The program 'sx' is currently not installed. You can install it by typing:
sudo apt-get install lrzsz

Everything is fine up until this point.

Any help would be greatly appreciated; have literally spent 2 days trying to work this out with LTS 12 now LTS 14 (ie I'm not here as first resort, I've RTFM!)

TL;DR:

Ubuntu 14 LTS, how to fix this error?

Code:
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:133:64: error: 'secp256k1_ecdsa_privkey_tweak_mul' was not declared in this scope
     return secp256k1_ecdsa_privkey_tweak_mul(a.data(), b.data());
                                                                ^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_public_key(const ec_point&)':
utility/ec_keys.cpp:76:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_private_key(const ec_secret&)':
utility/ec_keys.cpp:82:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_tweak_add(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:116:1: warning: control reaches end of non-void function [-Wreturn-type]


I had the same issue and fixed it.

Make sure you have:
1- secp256k1 installed
2- libbitcoin installed

To install secp256k1:
Code:
$ git clone https://github.com/bitcoin/secp256k1
$ cd secp256k1
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install

To install libbitcoin:
Code:
$ git clone https://github.com/libbitcoin/libbitcoin
$ cd libbitcoin
$ autoreconf -i
$ ./configure --enable-leveldb
$ make
$ sudo make install
$ sudo ldconfig

You will likely need to do the following as well:
Code:
$ sudo apt-get install build-essential autoconf automake libtool libboost-all-dev pkg-config libcurl4-openssl-dev libleveldb-dev libssl-dev

I still get HeadsOrTails's error of "utility/ec_keys.cpp:134:1: warning: control reaches end of non-void function" whenever I try to make libbitcoin after the configure step.  Any advice or things to try?

That's just a warning, you should be able to build it despite that message. If it isn't building successfully, it must be another error.

To get rid of the warning, find the function and have it return something at the end.
15  Bitcoin / Development & Technical Discussion / Re: sx command line utilities - Empower The Sysadmin With Bitcoin Tools on: October 30, 2014, 04:35:37 PM
Can someone kindly advise me what the issue is with Ubuntu 14 LTS installation? I'm a Ubuntu newbie but have followed the instructions and running sudo bash ./install-sx.sh file from / (root) always gives this install error:

Code:
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether we are using the GNU C++ compiler... (cached) yes
checking whether g++ accepts -g... (cached) yes
checking dependency style of g++... (cached) gcc3
checking whether g++ supports C++11 features by default... no
checking whether g++ supports C++11 features with -std=c++11... yes
checking whether make supports nested variables... (cached) yes
checking --enable-testnet argument... no
checking for boostlib >= 1.20.0... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for SSL... yes
checking for CURL... yes
checking for libsecp256k1... yes
checking that generated files are newer than configure... done
configure: creating ./config.status
config.status: creating Makefile
config.status: creating include/bitcoin/Makefile
config.status: creating src/Makefile
config.status: creating libbitcoin.pc
config.status: executing depfiles commands
config.status: executing libtool commands
configure: WARNING: unrecognized options: --with-libsecp256k1
Making all in include/bitcoin
make[1]: Entering directory `/usr/local/src/libbitcoin-git/include/bitcoin'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/local/src/libbitcoin-git/include/bitcoin'
Making all in src
make[1]: Entering directory `/usr/local/src/libbitcoin-git/src'
  CXX      utility/ec_keys.lo
utility/ec_keys.cpp: In function 'libbitcoin::ec_point libbitcoin::secret_to_public_key(const ec_secret&, bool)':
utility/ec_keys.cpp:66:23: error: 'secp256k1_ecdsa_pubkey_create' was not declared in this scope
             compressed))
                       ^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_public_key(const ec_point&)':
utility/ec_keys.cpp:75:78: error: 'secp256k1_ecdsa_pubkey_verify' was not declared in this scope
     return secp256k1_ecdsa_pubkey_verify(public_key.data(), public_key.size());
                                                                              ^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_private_key(const ec_secret&)':
utility/ec_keys.cpp:81:60: error: 'secp256k1_ecdsa_seckey_verify' was not declared in this scope
     return secp256k1_ecdsa_seckey_verify(private_key.data());
                                                            ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_tweak_add(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:115:73: error: 'secp256k1_ecdsa_pubkey_tweak_add' was not declared in this scope
     return secp256k1_ecdsa_pubkey_tweak_add(a.data(), a.size(), b.data());
                                                                         ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:121:73: error: 'secp256k1_ecdsa_pubkey_tweak_mul' was not declared in this scope
     return secp256k1_ecdsa_pubkey_tweak_mul(a.data(), a.size(), b.data());
                                                                         ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_add(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:127:64: error: 'secp256k1_ecdsa_privkey_tweak_add' was not declared in this scope
     return secp256k1_ecdsa_privkey_tweak_add(a.data(), b.data());
                                                                ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:133:64: error: 'secp256k1_ecdsa_privkey_tweak_mul' was not declared in this scope
     return secp256k1_ecdsa_privkey_tweak_mul(a.data(), b.data());
                                                                ^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_public_key(const ec_point&)':
utility/ec_keys.cpp:76:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_private_key(const ec_secret&)':
utility/ec_keys.cpp:82:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_tweak_add(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:116:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:122:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_add(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:128:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:134:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
make[1]: *** [utility/ec_keys.lo] Error 1
make[1]: Leaving directory `/usr/local/src/libbitcoin-git/src'
make: *** [all-recursive] Error 1
sim@ubuntu:/$ sx
The program 'sx' is currently not installed. You can install it by typing:
sudo apt-get install lrzsz

Everything is fine up until this point.

Any help would be greatly appreciated; have literally spent 2 days trying to work this out with LTS 12 now LTS 14 (ie I'm not here as first resort, I've RTFM!)

TL;DR:

Ubuntu 14 LTS, how to fix this error?

Code:
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_multiply(libbitcoin::ec_secret&, const ec_secret&)':
utility/ec_keys.cpp:133:64: error: 'secp256k1_ecdsa_privkey_tweak_mul' was not declared in this scope
     return secp256k1_ecdsa_privkey_tweak_mul(a.data(), b.data());
                                                                ^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_public_key(const ec_point&)':
utility/ec_keys.cpp:76:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::verify_private_key(const ec_secret&)':
utility/ec_keys.cpp:82:1: warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^
utility/ec_keys.cpp: In function 'bool libbitcoin::ec_tweak_add(libbitcoin::ec_point&, const ec_secret&)':
utility/ec_keys.cpp:116:1: warning: control reaches end of non-void function [-Wreturn-type]


I had the same issue and fixed it.

Make sure you have:
1- secp256k1 installed
2- libbitcoin installed

To install secp256k1:
Code:
$ git clone https://github.com/bitcoin/secp256k1
$ cd secp256k1
$ ./autogen.sh
$ ./configure
$ make
$ sudo make install

To install libbitcoin:
Code:
$ git clone https://github.com/libbitcoin/libbitcoin
$ cd libbitcoin
$ autoreconf -i
$ ./configure --enable-leveldb
$ make
$ sudo make install
$ sudo ldconfig

You will likely need to do the following as well:
Code:
$ sudo apt-get install build-essential autoconf automake libtool libboost-all-dev pkg-config libcurl4-openssl-dev libleveldb-dev libssl-dev
16  Bitcoin / Hardware / Re: BITMAIN‘s Liquid Cooled Miner C1: It is not only cool, but it is cool on: October 29, 2014, 06:58:39 PM
so, whats the noise with these watercooled miners?

Depends on what you are using to cool your radiators. If you have good fans, it shouldn't be too loud.
17  Bitcoin / Development & Technical Discussion / Re: sx command line utilities - Empower The Sysadmin With Bitcoin Tools on: October 29, 2014, 09:24:57 AM
I'm now on my fifth attempt using 2 different servers (one a pretty much clean Debian VM and one an established server).. every time I get nearly to the end of the blockchain sync it just seems to sit around not receiving new blocks and spewing reams of errors such as below. I'm assuming blockchain database corruption but it always seems to be somewhere in the 27#### block range (I've just noticed this). Is this normal? Is there maybe something about this range of blocks, was that when someone was spamming the blockchain? Getting a bit frustrated here sapping so much time and bandwidth and still haven't got a sync'd copy to play with. I don't want to download a torrent copy.


WARNING: Error storing memory pool transaction c0c958698d61b260a885115a7e2ccec1a25c8a121c0da9ec6165f0ce11920c9b: Spent input not found


I am having this exact same issue on Ubuntu 64 (latest version) running in VirtualBox on my MacBook Pro Retina.  I have 70GB of SSD and 6GB RAM allocated to the VM.  The block chain has simply stopped updating at right around 300,000 block height.  What solved this problem for you?

I'm afraid nothing solved the problem for me, I gave it a good go but submitted defeat assuming that the h/ware I was using was too slow. I'll try again though one day when I have spare hardware in the hope that whatever caused it is solved.

I'm now on my fifth attempt using 2 different servers (one a pretty much clean Debian VM and one an established server).. every time I get nearly to the end of the blockchain sync it just seems to sit around not receiving new blocks and spewing reams of errors such as below. I'm assuming blockchain database corruption but it always seems to be somewhere in the 27#### block range (I've just noticed this). Is this normal? Is there maybe something about this range of blocks, was that when someone was spamming the blockchain? Getting a bit frustrated here sapping so much time and bandwidth and still haven't got a sync'd copy to play with. I don't want to download a torrent copy.


WARNING: Error storing memory pool transaction c0c958698d61b260a885115a7e2ccec1a25c8a121c0da9ec6165f0ce11920c9b: Spent input not found


I am having this exact same issue on Ubuntu 64 (latest version) running in VirtualBox on my MacBook Pro Retina.  I have 70GB of SSD and 6GB RAM allocated to the VM.  The block chain has simply stopped updating at right around 300,000 block height.  What solved this problem for you?

I was having the same problem and I even have the same configuration with the MBP Retina.

It has nothing to do with the hardware or virtualization. It has to do with the systemwide file descriptor limits. Linux limits the number of files a process can have open and how many files can be open globally.

While excessively lenient of a policy, applying these settings wiil fix the issue:
Code:
sysctl -w fs.file-max=409600
echo "fs.file-max=409600" >> /etc/sysctl.conf
ulimit -n 409600
echo "$USER soft nofile 409600" >> /etc/security/limits.conf
echo "$USER hard nofile 409600" >> /etc/security/limits.conf
18  Bitcoin / Hardware / Re: ANTMINER S4 2TH/s, Batch 1 on Sale this week, shipping before Sept. Ends on: September 24, 2014, 06:06:47 PM

Yeah, not going to be purchasing. 90+ days for ROI if you aren't paying for electricity. And this is given the difficulty doesn't jump (which won't happen).
19  Bitcoin / Bitcoin Discussion / Re: satoshin@gmx.com is compromised on: September 09, 2014, 04:46:02 PM
It is funny how he chose to just pull a prank on you instead of emailing prominent people, saying that he is about to sell, causing panic and doubt.
20  Bitcoin / Hardware / Re: ANTMINER S3 Discussion and Support Thread. on: September 01, 2014, 08:13:18 PM
any news about starting to ship batch 8 ?
I paid 0.58 BTC x2 , for something that will never ROI
At least they should send it faster !

at least you are losing 0.58 unlike me, I ordered batch 6 and payed 1.32 BTC, I only made 0.30 BTC back (not counting electricity) Cheesy

so I am down 1 BTC + electricity.

Don't forget that you own the hardware and there are lots of people on eBay that will pay $400+ for your miner.

After fees and shipping youd be luck to get >$400 once people realize how bad of a deal Batch 8 is the market will bve flooded and prices will be driven down.  Now is the time to sell the S3s!

True, that's why I sold both of my B1 S3's already.
Pages: [1] 2 3 4 5 6 7 8 9 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!