Re: NEW: net/bitcoin

[Antoine Jacoutot]

On Wed, Jul 11, 2018 at 10:05:54PM +0200, Fabian Raetz wrote:
> Hi,
> 
> can we also create a package of the no_x11 flavor?

Not only we can, but we must.
Otherwise unbuilt FLAVORs tend to rot and die...

Thanks, commited.

> diff --git a/net/Makefile b/net/Makefile
> index 57cfb4eec35..b8781538c32 100644
> --- a/net/Makefile
> +++ b/net/Makefile
> @@ -27,6 +27,7 @@
>   SUBDIR += bird
>   SUBDIR += bird,v6
>   SUBDIR += bitcoin
> + SUBDIR += bitcoin,no_x11
>   SUBDIR += bitlbee
>   SUBDIR += bitlbee,libpurple
>   SUBDIR += bitlbee,otr
> 
> 
> Cheers,
> Fabian
> 
> Am So., 8. Juli 2018 um 20:05 Uhr schrieb Kirill Bychkov <
> ki...@linklevel.net>:
> 
> > On Sun, July 8, 2018 20:13, Rafael Sadowski wrote:
> > > On Sun Jul 08, 2018 at 05:39:33PM +0300, Kirill Bychkov wrote:
> > >> On Wed, July 4, 2018 23:28, Rafael Sadowski wrote:
> > >> > HI ports@, Hi Fabian Raetz!
> > >> >
> > >> > Thanks for testing over two weeks and tweaks/feedback. Your rc changes
> > >> > works fine for me.
> > >> >
> > >> > @ports: Attached new tarball with rc tweaks from Fabian Raetz.
> > >> >
> > >> > Could I get an okay (ports-wise) to import?
> > >>
> > >> Hi! Not an OK yet, sorry.
> > >> I guess better comment is needed to explain why this could be
> > >> built with clang only.
> > >
> > > Added "Undefined reference to boost and db4 with GCC" over COMPILER.
> > > Better ideas?
> >
> > OK kirby@
> > BTW you can use --disable-tests instead of @comments in PLIST
> >
> > >
> > > Complete output:
> > >
> > > /usr/bin/ar cr leveldb/libmemenv.a
> > > leveldb/helpers/memenv/leveldb_libmemenv_a-memenv.o
> > > /usr/bin/ranlib leveldb/libmemenv.a
> > > /usr/bin/libtool  --tag=CXX   --mode=link eg++ -Wstack-protector
> > > -fstack-protector-all  -fPIE -O2 -pipe  -std=c++11   -pthread
> > -Wl,-z,relro
> > > -Wl,-z,now  -L/usr/X11R6/lib -L/usr/local/lib -o bitcoind
> > bitcoind-bitcoind.o
> > > libbitcoin_server.a libbitcoin_common.a univalue/libunivalue.la
> > > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a
> > libbitcoin_consensus.a
> > > crypto/libbitcoin_crypto.a leveldb/libleveldb.a
> > leveldb/libleveldb_sse42.a
> > > leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib
> > > -lboost_system -lboost_filesystem -lboost_program_options-mt
> > -lboost_thread-mt
> > > -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc
> > > -L/usr/local/lib -levent_pthreads -levent_extra -levent_core
> > -L/usr/local/lib
> > > -levent_extra -levent_core -L/usr/local/lib -lzmq
> > > libtool: link: eg++ -o .libs/bitcoind -pthread -Wstack-protector
> > > -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z
> > > -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a
> > > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a
> > libbitcoin_consensus.a
> > > crypto/libbitcoin_crypto.a leveldb/libleveldb.a
> > leveldb/libleveldb_sse42.a
> > > leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++
> > > -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt
> > > -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl
> > -lcrypto
> > > -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium
> > > -Wl,-rpath-link,/usr/local/lib
> > > .libs/libzmq.so.4.2: warning: strcat() is almost always misused, please
> > use
> > > strlcat()
> > > .libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values,
> > is
> > > that what you want?
> > > .libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always
> > misused,
> > > please use strlcpy()
> > > .libs/libzmq.so.4.2: warning: sprintf() is often misused, please use
> > > snprintf()
> > > .libs/libevent_core.so.1.1: warning: random() may return deterministic
> > values,
> > > is that what you want?
> > > libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> > `SetupEnvironment()':
> > > util.cpp:(.text+0x12ca): undefined reference to
> > > `boost::filesystem::path::imbue(std::locale const&)'
> > > util.cpp:(.text+0x12d5): undefined reference to
> > > `boost::filesystem::path::imbue(std::locale const&)'
> > > libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> > >
> > `boost::program_options::detail::basic_config_file_iterator::getline(std::string&)':
> > >
> > util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98):
> > > undefined reference to `boost::program_options::to_internal(std::string
> > > const&)'
> > > libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> > >
> > `boost::program_options::detail::basic_config_file_iterator::basic_config_file_iterator(std::istream&,
> > > std::set,
> > std::allocator >
> > > const&, bool)':
> > >
> > 

Re: NEW: net/bitcoin

[Fabian Raetz]

Hi,

can we also create a package of the no_x11 flavor?

diff --git a/net/Makefile b/net/Makefile
index 57cfb4eec35..b8781538c32 100644
--- a/net/Makefile
+++ b/net/Makefile
@@ -27,6 +27,7 @@
  SUBDIR += bird
  SUBDIR += bird,v6
  SUBDIR += bitcoin
+ SUBDIR += bitcoin,no_x11
  SUBDIR += bitlbee
  SUBDIR += bitlbee,libpurple
  SUBDIR += bitlbee,otr


Cheers,
Fabian

Am So., 8. Juli 2018 um 20:05 Uhr schrieb Kirill Bychkov <
ki...@linklevel.net>:

> On Sun, July 8, 2018 20:13, Rafael Sadowski wrote:
> > On Sun Jul 08, 2018 at 05:39:33PM +0300, Kirill Bychkov wrote:
> >> On Wed, July 4, 2018 23:28, Rafael Sadowski wrote:
> >> > HI ports@, Hi Fabian Raetz!
> >> >
> >> > Thanks for testing over two weeks and tweaks/feedback. Your rc changes
> >> > works fine for me.
> >> >
> >> > @ports: Attached new tarball with rc tweaks from Fabian Raetz.
> >> >
> >> > Could I get an okay (ports-wise) to import?
> >>
> >> Hi! Not an OK yet, sorry.
> >> I guess better comment is needed to explain why this could be
> >> built with clang only.
> >
> > Added "Undefined reference to boost and db4 with GCC" over COMPILER.
> > Better ideas?
>
> OK kirby@
> BTW you can use --disable-tests instead of @comments in PLIST
>
> >
> > Complete output:
> >
> > /usr/bin/ar cr leveldb/libmemenv.a
> > leveldb/helpers/memenv/leveldb_libmemenv_a-memenv.o
> > /usr/bin/ranlib leveldb/libmemenv.a
> > /usr/bin/libtool  --tag=CXX   --mode=link eg++ -Wstack-protector
> > -fstack-protector-all  -fPIE -O2 -pipe  -std=c++11   -pthread
> -Wl,-z,relro
> > -Wl,-z,now  -L/usr/X11R6/lib -L/usr/local/lib -o bitcoind
> bitcoind-bitcoind.o
> > libbitcoin_server.a libbitcoin_common.a univalue/libunivalue.la
> > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a
> libbitcoin_consensus.a
> > crypto/libbitcoin_crypto.a leveldb/libleveldb.a
> leveldb/libleveldb_sse42.a
> > leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib
> > -lboost_system -lboost_filesystem -lboost_program_options-mt
> -lboost_thread-mt
> > -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc
> > -L/usr/local/lib -levent_pthreads -levent_extra -levent_core
> -L/usr/local/lib
> > -levent_extra -levent_core -L/usr/local/lib -lzmq
> > libtool: link: eg++ -o .libs/bitcoind -pthread -Wstack-protector
> > -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z
> > -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a
> > libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a
> libbitcoin_consensus.a
> > crypto/libbitcoin_crypto.a leveldb/libleveldb.a
> leveldb/libleveldb_sse42.a
> > leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++
> > -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt
> > -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl
> -lcrypto
> > -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium
> > -Wl,-rpath-link,/usr/local/lib
> > .libs/libzmq.so.4.2: warning: strcat() is almost always misused, please
> use
> > strlcat()
> > .libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values,
> is
> > that what you want?
> > .libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always
> misused,
> > please use strlcpy()
> > .libs/libzmq.so.4.2: warning: sprintf() is often misused, please use
> > snprintf()
> > .libs/libevent_core.so.1.1: warning: random() may return deterministic
> values,
> > is that what you want?
> > libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> `SetupEnvironment()':
> > util.cpp:(.text+0x12ca): undefined reference to
> > `boost::filesystem::path::imbue(std::locale const&)'
> > util.cpp:(.text+0x12d5): undefined reference to
> > `boost::filesystem::path::imbue(std::locale const&)'
> > libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> >
> `boost::program_options::detail::basic_config_file_iterator::getline(std::string&)':
> >
> util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98):
> > undefined reference to `boost::program_options::to_internal(std::string
> > const&)'
> > libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> >
> `boost::program_options::detail::basic_config_file_iterator::basic_config_file_iterator(std::istream&,
> > std::set,
> std::allocator >
> > const&, bool)':
> >
> util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcEC2ERSiRKSt3setISsSt4lessISsESaISsEEb[_ZN5boost15program_options6detail26basic_config_file_iteratorIcEC5ERSiRKSt3setISsSt4lessISsESaISsEEb]+0x21):
> > undefined reference to
> >
> `boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set > std::less, std::allocator > const&, bool)'
> > libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function
> > `CDBEnv::Verify(std::string const&, bool (*)(std::string const&,
> > std::string&), 

Re: NEW: net/bitcoin

[Kirill Bychkov]

On Sun, July 8, 2018 20:13, Rafael Sadowski wrote:
> On Sun Jul 08, 2018 at 05:39:33PM +0300, Kirill Bychkov wrote:
>> On Wed, July 4, 2018 23:28, Rafael Sadowski wrote:
>> > HI ports@, Hi Fabian Raetz!
>> >
>> > Thanks for testing over two weeks and tweaks/feedback. Your rc changes
>> > works fine for me.
>> >
>> > @ports: Attached new tarball with rc tweaks from Fabian Raetz.
>> >
>> > Could I get an okay (ports-wise) to import?
>>
>> Hi! Not an OK yet, sorry.
>> I guess better comment is needed to explain why this could be
>> built with clang only.
>
> Added "Undefined reference to boost and db4 with GCC" over COMPILER.
> Better ideas?

OK kirby@
BTW you can use --disable-tests instead of @comments in PLIST

>
> Complete output:
>
> /usr/bin/ar cr leveldb/libmemenv.a
> leveldb/helpers/memenv/leveldb_libmemenv_a-memenv.o
> /usr/bin/ranlib leveldb/libmemenv.a
> /usr/bin/libtool  --tag=CXX   --mode=link eg++ -Wstack-protector
> -fstack-protector-all  -fPIE -O2 -pipe  -std=c++11   -pthread  -Wl,-z,relro
> -Wl,-z,now  -L/usr/X11R6/lib -L/usr/local/lib -o bitcoind bitcoind-bitcoind.o
> libbitcoin_server.a libbitcoin_common.a univalue/libunivalue.la
> libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a
> crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a
> leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib
> -lboost_system -lboost_filesystem -lboost_program_options-mt -lboost_thread-mt
> -lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc
> -L/usr/local/lib -levent_pthreads -levent_extra -levent_core -L/usr/local/lib
> -levent_extra -levent_core -L/usr/local/lib -lzmq
> libtool: link: eg++ -o .libs/bitcoind -pthread -Wstack-protector
> -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z
> -Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a
> libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a
> crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a
> leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++
> -lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt
> -lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto
> -lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium
> -Wl,-rpath-link,/usr/local/lib
> .libs/libzmq.so.4.2: warning: strcat() is almost always misused, please use
> strlcat()
> .libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values, is
> that what you want?
> .libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always misused,
> please use strlcpy()
> .libs/libzmq.so.4.2: warning: sprintf() is often misused, please use
> snprintf()
> .libs/libevent_core.so.1.1: warning: random() may return deterministic values,
> is that what you want?
> libbitcoin_util.a(libbitcoin_util_a-util.o): In function `SetupEnvironment()':
> util.cpp:(.text+0x12ca): undefined reference to
> `boost::filesystem::path::imbue(std::locale const&)'
> util.cpp:(.text+0x12d5): undefined reference to
> `boost::filesystem::path::imbue(std::locale const&)'
> libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> `boost::program_options::detail::basic_config_file_iterator::getline(std::string&)':
> util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98):
> undefined reference to `boost::program_options::to_internal(std::string
> const&)'
> libbitcoin_util.a(libbitcoin_util_a-util.o): In function
> `boost::program_options::detail::basic_config_file_iterator::basic_config_file_iterator(std::istream&,
> std::set, std::allocator >
> const&, bool)':
> util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcEC2ERSiRKSt3setISsSt4lessISsESaISsEEb[_ZN5boost15program_options6detail26basic_config_file_iteratorIcEC5ERSiRKSt3setISsSt4lessISsESaISsEEb]+0x21):
> undefined reference to
> `boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set std::less, std::allocator > const&, bool)'
> libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function
> `CDBEnv::Verify(std::string const&, bool (*)(std::string const&,
> std::string&), std::string&)':
> db.cpp:(.text+0x6812): undefined reference to `Db::verify(char const*, char
> const*, std::ostream*, unsigned int)'
> libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function
> `CDBEnv::Salvage(std::string const&, bool,
> std::vector
> >, std::vector > >,
> std::allocator char> >, std::vector char> > > > >&)':
> db.cpp:(.text+0x6e81): undefined reference to `Db::verify(char const*, char
> const*, std::ostream*, unsigned int)'
> collect2: error: ld returned 1 exit status
> Error while executing eg++ -o .libs/bitcoind -pthread -Wstack-protector
> -fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z
> -Wl,now bitcoind-bitcoind.o 

Re: NEW: net/bitcoin

[Rafael Sadowski]

On Sun Jul 08, 2018 at 05:39:33PM +0300, Kirill Bychkov wrote:
> On Wed, July 4, 2018 23:28, Rafael Sadowski wrote:
> > HI ports@, Hi Fabian Raetz!
> >
> > Thanks for testing over two weeks and tweaks/feedback. Your rc changes
> > works fine for me.
> >
> > @ports: Attached new tarball with rc tweaks from Fabian Raetz.
> >
> > Could I get an okay (ports-wise) to import?
> 
> Hi! Not an OK yet, sorry.
> I guess better comment is needed to explain why this could be
> built with clang only.

Added "Undefined reference to boost and db4 with GCC" over COMPILER.
Better ideas?

Complete output:

/usr/bin/ar cr leveldb/libmemenv.a 
leveldb/helpers/memenv/leveldb_libmemenv_a-memenv.o
/usr/bin/ranlib leveldb/libmemenv.a
/usr/bin/libtool  --tag=CXX   --mode=link eg++ -Wstack-protector 
-fstack-protector-all  -fPIE -O2 -pipe  -std=c++11   -pthread  -Wl,-z,relro 
-Wl,-z,now  -L/usr/X11R6/lib -L/usr/local/lib -o bitcoind bitcoind-bitcoind.o  
libbitcoin_server.a libbitcoin_common.a univalue/libunivalue.la 
libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a 
crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a 
leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib 
-lboost_system -lboost_filesystem -lboost_program_options-mt -lboost_thread-mt 
-lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc -L/usr/local/lib 
-levent_pthreads -levent_extra -levent_core -L/usr/local/lib -levent_extra 
-levent_core -L/usr/local/lib -lzmq
libtool: link: eg++ -o .libs/bitcoind -pthread -Wstack-protector 
-fstack-protector-all -fPIE -O2 -pipe -std=c++11 -Wl,-z -Wl,relro -Wl,-z 
-Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a 
libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a 
crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a 
leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++ 
-lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt 
-lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto 
-lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium 
-Wl,-rpath-link,/usr/local/lib  
  
.libs/libzmq.so.4.2: warning: strcat() is almost always misused, please use 
strlcat()
.libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values, is 
that what you want? 
  
.libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always misused, 
please use strlcpy()

.libs/libzmq.so.4.2: warning: sprintf() is often misused, please use snprintf()
.libs/libevent_core.so.1.1: warning: random() may return deterministic values, 
is that what you want?  
   
libbitcoin_util.a(libbitcoin_util_a-util.o): In function `SetupEnvironment()':
util.cpp:(.text+0x12ca): undefined reference to 
`boost::filesystem::path::imbue(std::locale const&)'
  
util.cpp:(.text+0x12d5): undefined reference to 
`boost::filesystem::path::imbue(std::locale const&)'
  
libbitcoin_util.a(libbitcoin_util_a-util.o): In function 
`boost::program_options::detail::basic_config_file_iterator::getline(std::string&)':
   
util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98):
 undefined reference to `boost::program_options::to_internal(std::string 
const&)'
libbitcoin_util.a(libbitcoin_util_a-util.o): In function 
`boost::program_options::detail::basic_config_file_iterator::basic_config_file_iterator(std::istream&,
 std::set, std::allocator > 
const&, bool)':
util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcEC2ERSiRKSt3setISsSt4lessISsESaISsEEb[_ZN5boost15program_options6detail26basic_config_file_iteratorIcEC5ERSiRKSt3setISsSt4lessISsESaISsEEb]+0x21):
 undefined reference to 
`boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set, std::allocator > const&, bool)'
libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function 
`CDBEnv::Verify(std::string const&, bool (*)(std::string const&, std::string&), 
std::string&)':
db.cpp:(.text+0x6812): undefined reference to `Db::verify(char const*, char 
const*, std::ostream*, unsigned int)'   
  
libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In function 

Re: NEW: net/bitcoin

[Kirill Bychkov]

On Wed, July 4, 2018 23:28, Rafael Sadowski wrote:
> HI ports@, Hi Fabian Raetz!
>
> Thanks for testing over two weeks and tweaks/feedback. Your rc changes
> works fine for me.
>
> @ports: Attached new tarball with rc tweaks from Fabian Raetz.
>
> Could I get an okay (ports-wise) to import?

Hi! Not an OK yet, sorry.
I guess better comment is needed to explain why this could be
built with clang only.
And since almost all @tag bits are in, it would be nice to use it
in new ports instead of @exec.

>
> Thanks, Rafael
>
> On Mon Jul 02, 2018 at 11:07:10PM +0200, Fabian Raetz wrote:
>> add here's the missing diff xD
>>
>> Am Mo., 2. Juli 2018 um 23:06 Uhr schrieb Fabian Raetz <
>> fabian.ra...@gmail.com>:
>>
>> > Hi
>> >
>> > i've been running a bitcoin node for the last two weeks and everything
>> > seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and
>> > used it in combination with lnd [0] (in testnet)
>> >
>> > Please find the attached diff with two small improvements to the rc file:
>> > - add daemon_timeout=300. The daemon need time to shutdown successfully
>> > (syncing to disk). 300 sec. was choosen randomly but this value worked for
>> > me in several restarts.
>> > - remove pid_file. It works even without specifying it.
>> >
>> > With this, the port looks ok to me :)
>> >
>> > Cheer,
>> > Fabian
>> >
>> > [0] https://github.com/lightningnetwork/lnd
>> >
>> > Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski <
>> > raf...@sizeofvoid.org>:
>> >
>> >> On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote:
>> >> > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:
>> >> > > On 2018-06-23 09:07:38, Thomas Frohwein 
>> >> wrote:
>> >> > > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com
>> >> wrote:
>> >> > > > > I think the blockchain size is a deterrent. I can test it when
>> >> I'm back from traveling in ~ 10 days and have access to additional GB on
>> my
>> >> external drive, in case that helps.
>> >> > > > >
>> >> > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <
>> >> raf...@sizeofvoid.org> wrote:
>> >> > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
>> >> > > > > >
>> >> > > > > >It's not evil! It's NOT mining. ;)
>> >> > > >
>> >> > > > I installed it and tried to sync the 200GB blockchain to my
>> >> external HDD
>> >> > > > (because that's the only one that got this much space available).
>> It
>> >> > > > synced fine for 1-2 days with the bitcoin-qt client, but then at
>> >> about
>> >> > > > 30-40% of the blockchain synced, it now starts throwing an error:
>> >> > > >
>> >> > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error -
>> >> CAutoFile::read:fread failed: unspecified iostream_category error at
>> >> CBlockDiskPos(nFile=613, nPos=6513581)
>> >> > > >
>> >> > > > When this happens, the following lines appear in dmesg:
>> >> > > >
>> >> > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
>> >> > > >   SENSE KEY: Media Error
>> >> > > >   ASC/ASCQ: Unrecovered Read Error
>> >> > > >
>> >> > > > Fortunately, the drive still seems to be functional otherwise, can
>> >> be
>> >> > > > mounted and fsck -f doesn't see any issues. The dmesg lines
>> reappear
>> >> > > > whenever mounting or unmounting said drive until I disconnect and
>> >> > > > reconnect the drive from the USB port.
>> >> > > >
>> >> > >
>> >> > > This is almost certainly a problem with the drive.  I've had
>> >> > > several hard drives fail over the ~13 years or so I've been using
>> >> > > OpenBSD, and this is exactly the kind of error I see when the
>> >> > > drive is wearing out.
>> >> > >
>> >> > > The message means that the kernel could not read a sector on the
>> >> > > drive despite trying to do so.  I've had drives continue to
>> >> > > otherwise work for years after throwing errors like that (though I
>> >> > > made sure to back them up and only used them as "scratch" drives).
>> >> > > Another time I had a drive fail within weeks of throwing an error
>> >> > > like that.
>> >> > >
>> >> > > If it's still under warranty, I'd recommend sending it in for
>> >> > > replacement.  If it's not, I'd *highly* recommend backing up
>> >> > > anything on there to another drive.
>> >> > >
>> >> > > Sometimes, sectors can be "weak" and if you give the drive enough
>> >> > > time it will be able to read it, so if it can't be backed up
>> >> > > entirely, back up as much as you can, then let the drive sit for a
>> >> > > few days and try again.
>> >> > >
>> >> > > Some ports that may help:
>> >> > > sysutils/ddrescue
>> >> > > sysutils/testdisk
>> >> > > sysutils/e2fsprogs (for the "badblocks" program)
>> >> > > net/rsync (probably obvious, but still worth mentioning)
>> >> > >
>> >> > > Modern drives keep "spare sectors" in which to remap failing ones
>> >> > > like this, but they usually only do so when *writing* to the
>> >> > > sector, not when *reading* it.
>> >> > >
>> >> > > You could try backing 

Re: NEW: net/bitcoin

[Rafael Sadowski]

HI ports@, Hi Fabian Raetz!

Thanks for testing over two weeks and tweaks/feedback. Your rc changes
works fine for me.

@ports: Attached new tarball with rc tweaks from Fabian Raetz.

Could I get an okay (ports-wise) to import?

Thanks, Rafael

On Mon Jul 02, 2018 at 11:07:10PM +0200, Fabian Raetz wrote:
> add here's the missing diff xD
> 
> Am Mo., 2. Juli 2018 um 23:06 Uhr schrieb Fabian Raetz <
> fabian.ra...@gmail.com>:
> 
> > Hi
> >
> > i've been running a bitcoin node for the last two weeks and everything
> > seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and
> > used it in combination with lnd [0] (in testnet)
> >
> > Please find the attached diff with two small improvements to the rc file:
> > - add daemon_timeout=300. The daemon need time to shutdown successfully
> > (syncing to disk). 300 sec. was choosen randomly but this value worked for
> > me in several restarts.
> > - remove pid_file. It works even without specifying it.
> >
> > With this, the port looks ok to me :)
> >
> > Cheer,
> > Fabian
> >
> > [0] https://github.com/lightningnetwork/lnd
> >
> > Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski <
> > raf...@sizeofvoid.org>:
> >
> >> On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote:
> >> > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:
> >> > > On 2018-06-23 09:07:38, Thomas Frohwein 
> >> wrote:
> >> > > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com
> >> wrote:
> >> > > > > I think the blockchain size is a deterrent. I can test it when
> >> I'm back from traveling in ~ 10 days and have access to additional GB on my
> >> external drive, in case that helps.
> >> > > > >
> >> > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <
> >> raf...@sizeofvoid.org> wrote:
> >> > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> >> > > > > >
> >> > > > > >It's not evil! It's NOT mining. ;)
> >> > > >
> >> > > > I installed it and tried to sync the 200GB blockchain to my
> >> external HDD
> >> > > > (because that's the only one that got this much space available). It
> >> > > > synced fine for 1-2 days with the bitcoin-qt client, but then at
> >> about
> >> > > > 30-40% of the blockchain synced, it now starts throwing an error:
> >> > > >
> >> > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error -
> >> CAutoFile::read:fread failed: unspecified iostream_category error at
> >> CBlockDiskPos(nFile=613, nPos=6513581)
> >> > > >
> >> > > > When this happens, the following lines appear in dmesg:
> >> > > >
> >> > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
> >> > > >   SENSE KEY: Media Error
> >> > > >   ASC/ASCQ: Unrecovered Read Error
> >> > > >
> >> > > > Fortunately, the drive still seems to be functional otherwise, can
> >> be
> >> > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear
> >> > > > whenever mounting or unmounting said drive until I disconnect and
> >> > > > reconnect the drive from the USB port.
> >> > > >
> >> > >
> >> > > This is almost certainly a problem with the drive.  I've had
> >> > > several hard drives fail over the ~13 years or so I've been using
> >> > > OpenBSD, and this is exactly the kind of error I see when the
> >> > > drive is wearing out.
> >> > >
> >> > > The message means that the kernel could not read a sector on the
> >> > > drive despite trying to do so.  I've had drives continue to
> >> > > otherwise work for years after throwing errors like that (though I
> >> > > made sure to back them up and only used them as "scratch" drives).
> >> > > Another time I had a drive fail within weeks of throwing an error
> >> > > like that.
> >> > >
> >> > > If it's still under warranty, I'd recommend sending it in for
> >> > > replacement.  If it's not, I'd *highly* recommend backing up
> >> > > anything on there to another drive.
> >> > >
> >> > > Sometimes, sectors can be "weak" and if you give the drive enough
> >> > > time it will be able to read it, so if it can't be backed up
> >> > > entirely, back up as much as you can, then let the drive sit for a
> >> > > few days and try again.
> >> > >
> >> > > Some ports that may help:
> >> > > sysutils/ddrescue
> >> > > sysutils/testdisk
> >> > > sysutils/e2fsprogs (for the "badblocks" program)
> >> > > net/rsync (probably obvious, but still worth mentioning)
> >> > >
> >> > > Modern drives keep "spare sectors" in which to remap failing ones
> >> > > like this, but they usually only do so when *writing* to the
> >> > > sector, not when *reading* it.
> >> > >
> >> > > You could try backing up the drive, then writing zeros to the
> >> > > entire drive with dd(1) to try to see if it helps.  You could also
> >> > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs).
> >> > >
> >> > > -nUse non-destructive read-write mode.  By default only a non-
> >> > >   destructive read-only test is done.  This option must
> >> not be
> >> > >

Re: NEW: net/bitcoin

[Fabian Raetz]

add here's the missing diff xD

Am Mo., 2. Juli 2018 um 23:06 Uhr schrieb Fabian Raetz <
fabian.ra...@gmail.com>:

> Hi
>
> i've been running a bitcoin node for the last two weeks and everything
> seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and
> used it in combination with lnd [0] (in testnet)
>
> Please find the attached diff with two small improvements to the rc file:
> - add daemon_timeout=300. The daemon need time to shutdown successfully
> (syncing to disk). 300 sec. was choosen randomly but this value worked for
> me in several restarts.
> - remove pid_file. It works even without specifying it.
>
> With this, the port looks ok to me :)
>
> Cheer,
> Fabian
>
> [0] https://github.com/lightningnetwork/lnd
>
> Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski <
> raf...@sizeofvoid.org>:
>
>> On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote:
>> > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:
>> > > On 2018-06-23 09:07:38, Thomas Frohwein 
>> wrote:
>> > > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com
>> wrote:
>> > > > > I think the blockchain size is a deterrent. I can test it when
>> I'm back from traveling in ~ 10 days and have access to additional GB on my
>> external drive, in case that helps.
>> > > > >
>> > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <
>> raf...@sizeofvoid.org> wrote:
>> > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
>> > > > > >
>> > > > > >It's not evil! It's NOT mining. ;)
>> > > >
>> > > > I installed it and tried to sync the 200GB blockchain to my
>> external HDD
>> > > > (because that's the only one that got this much space available). It
>> > > > synced fine for 1-2 days with the bitcoin-qt client, but then at
>> about
>> > > > 30-40% of the blockchain synced, it now starts throwing an error:
>> > > >
>> > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error -
>> CAutoFile::read:fread failed: unspecified iostream_category error at
>> CBlockDiskPos(nFile=613, nPos=6513581)
>> > > >
>> > > > When this happens, the following lines appear in dmesg:
>> > > >
>> > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
>> > > >   SENSE KEY: Media Error
>> > > >   ASC/ASCQ: Unrecovered Read Error
>> > > >
>> > > > Fortunately, the drive still seems to be functional otherwise, can
>> be
>> > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear
>> > > > whenever mounting or unmounting said drive until I disconnect and
>> > > > reconnect the drive from the USB port.
>> > > >
>> > >
>> > > This is almost certainly a problem with the drive.  I've had
>> > > several hard drives fail over the ~13 years or so I've been using
>> > > OpenBSD, and this is exactly the kind of error I see when the
>> > > drive is wearing out.
>> > >
>> > > The message means that the kernel could not read a sector on the
>> > > drive despite trying to do so.  I've had drives continue to
>> > > otherwise work for years after throwing errors like that (though I
>> > > made sure to back them up and only used them as "scratch" drives).
>> > > Another time I had a drive fail within weeks of throwing an error
>> > > like that.
>> > >
>> > > If it's still under warranty, I'd recommend sending it in for
>> > > replacement.  If it's not, I'd *highly* recommend backing up
>> > > anything on there to another drive.
>> > >
>> > > Sometimes, sectors can be "weak" and if you give the drive enough
>> > > time it will be able to read it, so if it can't be backed up
>> > > entirely, back up as much as you can, then let the drive sit for a
>> > > few days and try again.
>> > >
>> > > Some ports that may help:
>> > > sysutils/ddrescue
>> > > sysutils/testdisk
>> > > sysutils/e2fsprogs (for the "badblocks" program)
>> > > net/rsync (probably obvious, but still worth mentioning)
>> > >
>> > > Modern drives keep "spare sectors" in which to remap failing ones
>> > > like this, but they usually only do so when *writing* to the
>> > > sector, not when *reading* it.
>> > >
>> > > You could try backing up the drive, then writing zeros to the
>> > > entire drive with dd(1) to try to see if it helps.  You could also
>> > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs).
>> > >
>> > > -nUse non-destructive read-write mode.  By default only a non-
>> > >   destructive read-only test is done.  This option must
>> not be
>> > >   combined with the -w option, as they are mutually
>> exclusive.
>> > >
>> > > "badblocks -n" will read all sectors on the drive and write back
>> > > the same data to the sector.  If it's "weak", and the program can
>> > > manage to read the sector, the drive may then remap that sector to
>> > > a spare.
>> > >
>> > > But!  How much do you really trust a drive that has started to
>> > > fail?  Drives are cheap.  Cheaper than they've ever been.  If this
>> > > drive contains the only copy of family photos 

Re: NEW: net/bitcoin

[Fabian Raetz]

Hi

i've been running a bitcoin node for the last two weeks and everything
seems to be fine! I tested the QT client as well as the no_x11 FLAVOR and
used it in combination with lnd [0] (in testnet)

Please find the attached diff with two small improvements to the rc file:
- add daemon_timeout=300. The daemon need time to shutdown successfully
(syncing to disk). 300 sec. was choosen randomly but this value worked for
me in several restarts.
- remove pid_file. It works even without specifying it.

With this, the port looks ok to me :)

Cheer,
Fabian

[0] https://github.com/lightningnetwork/lnd

Am Di., 26. Juni 2018 um 23:20 Uhr schrieb Rafael Sadowski <
raf...@sizeofvoid.org>:

> On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote:
> > On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:
> > > On 2018-06-23 09:07:38, Thomas Frohwein 
> wrote:
> > > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com
> wrote:
> > > > > I think the blockchain size is a deterrent. I can test it when I'm
> back from traveling in ~ 10 days and have access to additional GB on my
> external drive, in case that helps.
> > > > >
> > > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski <
> raf...@sizeofvoid.org> wrote:
> > > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> > > > > >
> > > > > >It's not evil! It's NOT mining. ;)
> > > >
> > > > I installed it and tried to sync the 200GB blockchain to my external
> HDD
> > > > (because that's the only one that got this much space available). It
> > > > synced fine for 1-2 days with the bitcoin-qt client, but then at
> about
> > > > 30-40% of the blockchain synced, it now starts throwing an error:
> > > >
> > > > ERROR: ReadBlockFromDisk: Deserialize or I/O error -
> CAutoFile::read:fread failed: unspecified iostream_category error at
> CBlockDiskPos(nFile=613, nPos=6513581)
> > > >
> > > > When this happens, the following lines appear in dmesg:
> > > >
> > > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
> > > >   SENSE KEY: Media Error
> > > >   ASC/ASCQ: Unrecovered Read Error
> > > >
> > > > Fortunately, the drive still seems to be functional otherwise, can be
> > > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear
> > > > whenever mounting or unmounting said drive until I disconnect and
> > > > reconnect the drive from the USB port.
> > > >
> > >
> > > This is almost certainly a problem with the drive.  I've had
> > > several hard drives fail over the ~13 years or so I've been using
> > > OpenBSD, and this is exactly the kind of error I see when the
> > > drive is wearing out.
> > >
> > > The message means that the kernel could not read a sector on the
> > > drive despite trying to do so.  I've had drives continue to
> > > otherwise work for years after throwing errors like that (though I
> > > made sure to back them up and only used them as "scratch" drives).
> > > Another time I had a drive fail within weeks of throwing an error
> > > like that.
> > >
> > > If it's still under warranty, I'd recommend sending it in for
> > > replacement.  If it's not, I'd *highly* recommend backing up
> > > anything on there to another drive.
> > >
> > > Sometimes, sectors can be "weak" and if you give the drive enough
> > > time it will be able to read it, so if it can't be backed up
> > > entirely, back up as much as you can, then let the drive sit for a
> > > few days and try again.
> > >
> > > Some ports that may help:
> > > sysutils/ddrescue
> > > sysutils/testdisk
> > > sysutils/e2fsprogs (for the "badblocks" program)
> > > net/rsync (probably obvious, but still worth mentioning)
> > >
> > > Modern drives keep "spare sectors" in which to remap failing ones
> > > like this, but they usually only do so when *writing* to the
> > > sector, not when *reading* it.
> > >
> > > You could try backing up the drive, then writing zeros to the
> > > entire drive with dd(1) to try to see if it helps.  You could also
> > > try running "badblocks -n" on the drive (from sysutils/e2fsprogs).
> > >
> > > -nUse non-destructive read-write mode.  By default only a non-
> > >   destructive read-only test is done.  This option must
> not be
> > >   combined with the -w option, as they are mutually
> exclusive.
> > >
> > > "badblocks -n" will read all sectors on the drive and write back
> > > the same data to the sector.  If it's "weak", and the program can
> > > manage to read the sector, the drive may then remap that sector to
> > > a spare.
> > >
> > > But!  How much do you really trust a drive that has started to
> > > fail?  Drives are cheap.  Cheaper than they've ever been.  If this
> > > drive contains the only copy of family photos of your dearly
> > > departed grandmother, are you willing to risk it?
> > >
> > > sd4 at scsibus4 targ 1 lun 0:  SCSI4
> 0/direct fixed
> > > sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
> > >
> > > I see a 3TB Western Digital 

Re: NEW: net/bitcoin

[Rafael Sadowski]

On Tue Jun 26, 2018 at 10:39:17PM +0200, Rafael Sadowski wrote:
> On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:
> > On 2018-06-23 09:07:38, Thomas Frohwein  wrote:
> > > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com wrote:
> > > > I think the blockchain size is a deterrent. I can test it when I'm back 
> > > > from traveling in ~ 10 days and have access to additional GB on my 
> > > > external drive, in case that helps.
> > > > 
> > > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski  
> > > > wrote:
> > > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> > > > >
> > > > >It's not evil! It's NOT mining. ;)
> > > 
> > > I installed it and tried to sync the 200GB blockchain to my external HDD
> > > (because that's the only one that got this much space available). It
> > > synced fine for 1-2 days with the bitcoin-qt client, but then at about
> > > 30-40% of the blockchain synced, it now starts throwing an error:
> > > 
> > > ERROR: ReadBlockFromDisk: Deserialize or I/O error - 
> > > CAutoFile::read:fread failed: unspecified iostream_category error at 
> > > CBlockDiskPos(nFile=613, nPos=6513581)
> > > 
> > > When this happens, the following lines appear in dmesg:
> > > 
> > > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
> > >   SENSE KEY: Media Error
> > >   ASC/ASCQ: Unrecovered Read Error
> > > 
> > > Fortunately, the drive still seems to be functional otherwise, can be
> > > mounted and fsck -f doesn't see any issues. The dmesg lines reappear
> > > whenever mounting or unmounting said drive until I disconnect and
> > > reconnect the drive from the USB port.
> > > 
> > 
> > This is almost certainly a problem with the drive.  I've had
> > several hard drives fail over the ~13 years or so I've been using
> > OpenBSD, and this is exactly the kind of error I see when the
> > drive is wearing out.
> > 
> > The message means that the kernel could not read a sector on the
> > drive despite trying to do so.  I've had drives continue to
> > otherwise work for years after throwing errors like that (though I
> > made sure to back them up and only used them as "scratch" drives).
> > Another time I had a drive fail within weeks of throwing an error
> > like that.
> > 
> > If it's still under warranty, I'd recommend sending it in for
> > replacement.  If it's not, I'd *highly* recommend backing up
> > anything on there to another drive.
> > 
> > Sometimes, sectors can be "weak" and if you give the drive enough
> > time it will be able to read it, so if it can't be backed up
> > entirely, back up as much as you can, then let the drive sit for a
> > few days and try again.
> > 
> > Some ports that may help:
> > sysutils/ddrescue
> > sysutils/testdisk
> > sysutils/e2fsprogs (for the "badblocks" program)
> > net/rsync (probably obvious, but still worth mentioning)
> > 
> > Modern drives keep "spare sectors" in which to remap failing ones
> > like this, but they usually only do so when *writing* to the
> > sector, not when *reading* it.
> > 
> > You could try backing up the drive, then writing zeros to the
> > entire drive with dd(1) to try to see if it helps.  You could also
> > try running "badblocks -n" on the drive (from sysutils/e2fsprogs).
> > 
> > -nUse non-destructive read-write mode.  By default only a non-
> >   destructive read-only test is done.  This option must not be
> >   combined with the -w option, as they are mutually exclusive.
> > 
> > "badblocks -n" will read all sectors on the drive and write back
> > the same data to the sector.  If it's "weak", and the program can
> > manage to read the sector, the drive may then remap that sector to
> > a spare.
> > 
> > But!  How much do you really trust a drive that has started to
> > fail?  Drives are cheap.  Cheaper than they've ever been.  If this
> > drive contains the only copy of family photos of your dearly
> > departed grandmother, are you willing to risk it?
> > 
> > sd4 at scsibus4 targ 1 lun 0:  SCSI4 0/direct 
> > fixed
> > sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
> > 
> > I see a 3TB Western Digital My Book on a very popular online
> > retailer for only $89.99 USD with free shipping as I type this.
> > 
> > Is the data on that drive worth more than that?  Is the amount of
> > time you'd spend trying to squeeze a little more life out of the
> > drive worth it?  How much do you value your free time?  If you
> > enjoy tinkering with things like this and don't have valuable data
> > on it, it may be worth trying.  If you'd rather spend that time
> > outside hiking or seeing friends and family, then it may be more
> > economical to just buy a new one.  
> > 
> > Ultimately, only you can decide.
> > 
> > > I can't resume syncing the blockchain though because the error appears
> > > again.
> > > 
> > 
> > While I'm here, I poked around bitcoin's manpage and found this:
> > 
> >  -prune=
> > 
> >   Reduce storage 

Re: NEW: net/bitcoin

[Rafael Sadowski]

On Sun Jun 24, 2018 at 12:42:51PM +0900, Bryan Linton wrote:
> On 2018-06-23 09:07:38, Thomas Frohwein  wrote:
> > On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com wrote:
> > > I think the blockchain size is a deterrent. I can test it when I'm back 
> > > from traveling in ~ 10 days and have access to additional GB on my 
> > > external drive, in case that helps.
> > > 
> > > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski  
> > > wrote:
> > > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> > > >
> > > >It's not evil! It's NOT mining. ;)
> > 
> > I installed it and tried to sync the 200GB blockchain to my external HDD
> > (because that's the only one that got this much space available). It
> > synced fine for 1-2 days with the bitcoin-qt client, but then at about
> > 30-40% of the blockchain synced, it now starts throwing an error:
> > 
> > ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read:fread 
> > failed: unspecified iostream_category error at CBlockDiskPos(nFile=613, 
> > nPos=6513581)
> > 
> > When this happens, the following lines appear in dmesg:
> > 
> > sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
> > SENSE KEY: Media Error
> > ASC/ASCQ: Unrecovered Read Error
> > 
> > Fortunately, the drive still seems to be functional otherwise, can be
> > mounted and fsck -f doesn't see any issues. The dmesg lines reappear
> > whenever mounting or unmounting said drive until I disconnect and
> > reconnect the drive from the USB port.
> > 
> 
> This is almost certainly a problem with the drive.  I've had
> several hard drives fail over the ~13 years or so I've been using
> OpenBSD, and this is exactly the kind of error I see when the
> drive is wearing out.
> 
> The message means that the kernel could not read a sector on the
> drive despite trying to do so.  I've had drives continue to
> otherwise work for years after throwing errors like that (though I
> made sure to back them up and only used them as "scratch" drives).
> Another time I had a drive fail within weeks of throwing an error
> like that.
> 
> If it's still under warranty, I'd recommend sending it in for
> replacement.  If it's not, I'd *highly* recommend backing up
> anything on there to another drive.
> 
> Sometimes, sectors can be "weak" and if you give the drive enough
> time it will be able to read it, so if it can't be backed up
> entirely, back up as much as you can, then let the drive sit for a
> few days and try again.
> 
> Some ports that may help:
>   sysutils/ddrescue
>   sysutils/testdisk
>   sysutils/e2fsprogs (for the "badblocks" program)
>   net/rsync (probably obvious, but still worth mentioning)
> 
> Modern drives keep "spare sectors" in which to remap failing ones
> like this, but they usually only do so when *writing* to the
> sector, not when *reading* it.
> 
> You could try backing up the drive, then writing zeros to the
> entire drive with dd(1) to try to see if it helps.  You could also
> try running "badblocks -n" on the drive (from sysutils/e2fsprogs).
> 
>   -nUse non-destructive read-write mode.  By default only a non-
>   destructive read-only test is done.  This option must not be
>   combined with the -w option, as they are mutually exclusive.
> 
> "badblocks -n" will read all sectors on the drive and write back
> the same data to the sector.  If it's "weak", and the program can
> manage to read the sector, the drive may then remap that sector to
> a spare.
> 
> But!  How much do you really trust a drive that has started to
> fail?  Drives are cheap.  Cheaper than they've ever been.  If this
> drive contains the only copy of family photos of your dearly
> departed grandmother, are you willing to risk it?
> 
>   sd4 at scsibus4 targ 1 lun 0:  SCSI4 0/direct 
> fixed
>   sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors
> 
> I see a 3TB Western Digital My Book on a very popular online
> retailer for only $89.99 USD with free shipping as I type this.
> 
> Is the data on that drive worth more than that?  Is the amount of
> time you'd spend trying to squeeze a little more life out of the
> drive worth it?  How much do you value your free time?  If you
> enjoy tinkering with things like this and don't have valuable data
> on it, it may be worth trying.  If you'd rather spend that time
> outside hiking or seeing friends and family, then it may be more
> economical to just buy a new one.  
> 
> Ultimately, only you can decide.
> 
> > I can't resume syncing the blockchain though because the error appears
> > again.
> > 
> 
> While I'm here, I poked around bitcoin's manpage and found this:
> 
>  -prune=
> 
>   Reduce storage requirements by enabling pruning (deleting) of
>   old blocks. This allows the pruneblockchain RPC to be called to
>   delete specific blocks, and enables automatic pruning of old
>   blocks if a target size in MiB is provided. 

Re: NEW: net/bitcoin

[Bryan Linton]

On 2018-06-23 09:07:38, Thomas Frohwein  wrote:
> On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com wrote:
> > I think the blockchain size is a deterrent. I can test it when I'm back 
> > from traveling in ~ 10 days and have access to additional GB on my external 
> > drive, in case that helps.
> > 
> > On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski  
> > wrote:
> > >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> > >
> > >It's not evil! It's NOT mining. ;)
> 
> I installed it and tried to sync the 200GB blockchain to my external HDD
> (because that's the only one that got this much space available). It
> synced fine for 1-2 days with the bitcoin-qt client, but then at about
> 30-40% of the blockchain synced, it now starts throwing an error:
> 
> ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read:fread 
> failed: unspecified iostream_category error at CBlockDiskPos(nFile=613, 
> nPos=6513581)
> 
> When this happens, the following lines appear in dmesg:
> 
> sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
>   SENSE KEY: Media Error
>   ASC/ASCQ: Unrecovered Read Error
> 
> Fortunately, the drive still seems to be functional otherwise, can be
> mounted and fsck -f doesn't see any issues. The dmesg lines reappear
> whenever mounting or unmounting said drive until I disconnect and
> reconnect the drive from the USB port.
> 

This is almost certainly a problem with the drive.  I've had
several hard drives fail over the ~13 years or so I've been using
OpenBSD, and this is exactly the kind of error I see when the
drive is wearing out.

The message means that the kernel could not read a sector on the
drive despite trying to do so.  I've had drives continue to
otherwise work for years after throwing errors like that (though I
made sure to back them up and only used them as "scratch" drives).
Another time I had a drive fail within weeks of throwing an error
like that.

If it's still under warranty, I'd recommend sending it in for
replacement.  If it's not, I'd *highly* recommend backing up
anything on there to another drive.

Sometimes, sectors can be "weak" and if you give the drive enough
time it will be able to read it, so if it can't be backed up
entirely, back up as much as you can, then let the drive sit for a
few days and try again.

Some ports that may help:
sysutils/ddrescue
sysutils/testdisk
sysutils/e2fsprogs (for the "badblocks" program)
net/rsync (probably obvious, but still worth mentioning)

Modern drives keep "spare sectors" in which to remap failing ones
like this, but they usually only do so when *writing* to the
sector, not when *reading* it.

You could try backing up the drive, then writing zeros to the
entire drive with dd(1) to try to see if it helps.  You could also
try running "badblocks -n" on the drive (from sysutils/e2fsprogs).

-nUse non-destructive read-write mode.  By default only a non-
  destructive read-only test is done.  This option must not be
  combined with the -w option, as they are mutually exclusive.

"badblocks -n" will read all sectors on the drive and write back
the same data to the sector.  If it's "weak", and the program can
manage to read the sector, the drive may then remap that sector to
a spare.

But!  How much do you really trust a drive that has started to
fail?  Drives are cheap.  Cheaper than they've ever been.  If this
drive contains the only copy of family photos of your dearly
departed grandmother, are you willing to risk it?

sd4 at scsibus4 targ 1 lun 0:  SCSI4 0/direct 
fixed
sd4: 2861556MB, 4096 bytes/sector, 732558336 sectors

I see a 3TB Western Digital My Book on a very popular online
retailer for only $89.99 USD with free shipping as I type this.

Is the data on that drive worth more than that?  Is the amount of
time you'd spend trying to squeeze a little more life out of the
drive worth it?  How much do you value your free time?  If you
enjoy tinkering with things like this and don't have valuable data
on it, it may be worth trying.  If you'd rather spend that time
outside hiking or seeing friends and family, then it may be more
economical to just buy a new one.  

Ultimately, only you can decide.

> I can't resume syncing the blockchain though because the error appears
> again.
> 

While I'm here, I poked around bitcoin's manpage and found this:

 -prune=

  Reduce storage requirements by enabling pruning (deleting) of
  old blocks. This allows the pruneblockchain RPC to be called to
  delete specific blocks, and enables automatic pruning of old
  blocks if a target size in MiB is provided. This mode is
  incompatible with -txindex and -rescan. Warning: Reverting this
  setting requires re-downloading the entire blockchain. (default:
  0 = disable pruning blocks, 1 = allow manual pruning via RPC,
  >550 

Re: NEW: net/bitcoin

[Thomas Frohwein]

On Fri, Jun 08, 2018 at 11:38:49AM +, tfrohw...@fastmail.com wrote:
> I think the blockchain size is a deterrent. I can test it when I'm back from 
> traveling in ~ 10 days and have access to additional GB on my external drive, 
> in case that helps.
> 
> On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski  wrote:
> >3rd ping, or 4rd? Could anyone sacrifice themselves, please.
> >
> >It's not evil! It's NOT mining. ;)

I installed it and tried to sync the 200GB blockchain to my external HDD
(because that's the only one that got this much space available). It
synced fine for 1-2 days with the bitcoin-qt client, but then at about
30-40% of the blockchain synced, it now starts throwing an error:

ERROR: ReadBlockFromDisk: Deserialize or I/O error - CAutoFile::read:fread 
failed: unspecified iostream_category error at CBlockDiskPos(nFile=613, 
nPos=6513581)

When this happens, the following lines appear in dmesg:

sd4(umass0:1:0): Check Condition (error 0x70) on opcode 0x28
SENSE KEY: Media Error
ASC/ASCQ: Unrecovered Read Error

Fortunately, the drive still seems to be functional otherwise, can be
mounted and fsck -f doesn't see any issues. The dmesg lines reappear
whenever mounting or unmounting said drive until I disconnect and
reconnect the drive from the USB port.

I can't resume syncing the blockchain though because the error appears
again.

Not sure if this is a deficiency of the port or maybe the hard drive
itself...

bitcoin's debug.log (9.5M): https://thfr.info/tmpstor/debug.log

OpenBSD 6.3-current (GENERIC.MP) #36: Wed Jun 20 00:03:07 MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 7454228480 (7108MB)
avail mem = 7157866496 (6826MB)
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.0 @ 0x3f262000 (86 entries)
bios0: vendor American Megatrends Inc. version "1.A0" date 02/27/2018
bios0: MSI MS-7A74
acpi0 at bios0: rev 2
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP APIC FPDT FIDT MCFG SSDT SSDT SSDT HPET SSDT SSDT UEFI 
SSDT LPIT SSDT SSDT SSDT SSDT DBGP DBG2 WSMT
acpi0: wakeup devices PEGP(S4) PEG0(S4) PEGP(S4) PEG1(S4) PEGP(S4) PEG2(S4) 
PXSX(S4) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4) PXSX(S4) RP12(S4) 
PXSX(S4) RP13(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz, 3892.39 MHz
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu0: 256KB 64b/line 8-way L2 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 23MHz
cpu0: mwait min=64, max=64, C-substates=0.2.1.2.4.1, IBE
cpu1 at mainbus0: apid 2 (application processor)
cpu1: Intel(R) Core(TM) i3-7100 CPU @ 3.90GHz, 3890.94 MHz
cpu1: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,SGX,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,MPX,RDSEED,ADX,SMAP,CLFLUSHOPT,PT,IBRS,IBPB,STIBP,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES,MELTDOWN
cpu1: 256KB 64b/line 8-way L2 cache
cpu1: smt 0, core 1, package 0
ioapic0 at mainbus0: apid 2 pa 0xfec0, version 20, 120 pins
acpimcfg0 at acpi0 addr 0xe000, bus 0-255
acpihpet0 at acpi0: 2399 Hz
acpiprt0 at acpi0: bus 0 (PCI0)
acpiprt1 at acpi0: bus 1 (PEG0)
acpiprt2 at acpi0: bus -1 (PEG1)
acpiprt3 at acpi0: bus -1 (PEG2)
acpiprt4 at acpi0: bus -1 (RP09)
acpiprt5 at acpi0: bus -1 (RP10)
acpiprt6 at acpi0: bus -1 (RP11)
acpiprt7 at acpi0: bus -1 (RP12)
acpiprt8 at acpi0: bus -1 (RP13)
acpiprt9 at acpi0: bus -1 (RP01)
acpiprt10 at acpi0: bus -1 (RP02)
acpiprt11 at acpi0: bus -1 (RP03)
acpiprt12 at acpi0: bus -1 (RP04)
acpiprt13 at acpi0: bus -1 (RP05)
acpiprt14 at acpi0: bus -1 (RP06)
acpiprt15 at acpi0: bus 2 (RP07)
acpiprt16 at acpi0: bus -1 (RP08)
acpiprt17 at acpi0: bus -1 (RP17)
acpiprt18 at acpi0: bus -1 (RP18)
acpiprt19 at acpi0: bus -1 (RP19)
acpiprt20 at acpi0: bus -1 (RP20)
acpiprt21 at acpi0: bus -1 (RP21)
acpiprt22 at acpi0: bus -1 (RP22)
acpiprt23 at acpi0: bus -1 (RP23)
acpiprt24 at acpi0: bus -1 (RP24)
acpiprt25 at acpi0: bus -1 (RP14)
acpiprt26 at acpi0: bus -1 (RP15)
acpiprt27 at acpi0: bus -1 (RP16)
acpiec0 at acpi0: not present
acpicpu0 at acpi0: C2(200@151 mwait.1@0x33), C1(1000@1 

Re: NEW: net/bitcoin

[tfrohw...@fastmail.com]

I think the blockchain size is a deterrent. I can test it when I'm back from 
traveling in ~ 10 days and have access to additional GB on my external drive, 
in case that helps.

On June 8, 2018 6:53:55 AM UTC, Rafael Sadowski  wrote:
>3rd ping, or 4rd? Could anyone sacrifice themselves, please.
>
>It's not evil! It's NOT mining. ;)
>
>On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote:
>> Hi ports@
>> 
>> Attached is a new port for bitcoin. Long time ago pascal@ started
>> working on bitcoin in openbsd-wip. I've finished this work and run a
>full
>> bitcoin node over weeks without problems so far:
>> 
>> https://twitter.com/sizeofvoid/status/976586173538885632
>> 
>> $ cat net/bitcoin/pkg/DESCR
>> 
>> Bitcoin is an experimental new digital currency that enables instant
>> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
>> technology to operate with no central authority: managing
>transactions
>> and issuing money are carried out collectively by the network.
>> Bitcoin is also the name of the open source software which enables
>> the use of this currency.
>> 
>> Ok? Comments?
>> 
>> Greetings to the hackerroom.
>> 
>> Rafael Sadowski

Re: NEW: net/bitcoin

[Rafael Sadowski]

3rd ping, or 4rd? Could anyone sacrifice themselves, please.

It's not evil! It's NOT mining. ;)

On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote:
> Hi ports@
> 
> Attached is a new port for bitcoin. Long time ago pascal@ started
> working on bitcoin in openbsd-wip. I've finished this work and run a full
> bitcoin node over weeks without problems so far:
> 
> https://twitter.com/sizeofvoid/status/976586173538885632
> 
> $ cat net/bitcoin/pkg/DESCR
> 
> Bitcoin is an experimental new digital currency that enables instant
> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
> technology to operate with no central authority: managing transactions
> and issuing money are carried out collectively by the network.
> Bitcoin is also the name of the open source software which enables
> the use of this currency.
> 
> Ok? Comments?
> 
> Greetings to the hackerroom.
> 
> Rafael Sadowski

Re: NEW: net/bitcoin

[Rafael Sadowski]

On Fri May 18, 2018 at 11:47:48AM -0400, Joseph Mayer wrote:
> 2018-05-07 3:21 GMT+08:00 Rafael Sadowski :
> > It doesn't build with ports-gcc 
> 
> I got it built using ports not too long ago.
> 
> What issues did you get trying to build it using gcc-ports (GCC 4.9.4)?

Please find attached my GCC output. The same linker call works with
clang but not with ports-gcc.

> 
> The only issue was the difficulty of install Berkeley DB, which can be
> resolved by either building and installing (how?) or something like
> --disable-wallet, as only the wallet subfunctionality uses it anyhow,
> not the central router.
> 
> Do you build the QT and wallet parts?

Please check the ports Makefile.

> 
> > and you already said it: "... you wouldn't want to run this on a
> > machine that doesn't have clang available to it since it's probably
> > far too slow."
> 
> Clang may be working well for many projects, this one included, but
> there are also projects today where Clang consistently performs
> disastrously, so GCC will remain having a valid niche, maybe for very
> long.
> 

It's about architectures not projects.
/usr/bin/libtool  --tag=CXX   --mode=link c++ -Wstack-protector 
-fstack-protector-all  -fPIE -O2 -pipe  -std=c++14   -pthread  -Wl,-z,relro 
-Wl,-z,now  -L/usr/X11R6/lib -L/usr/local/lib -L/usr/local/lib/db4 -o bitcoind 
bitcoind-bitcoind.o  libbitcoin_server.a libbitcoin_common.a 
univalue/libunivalue.la libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a 
libbitcoin_consensus.a
crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a 
leveldb/libmemenv.a secp256k1/libsecp256k1.la -pthread -L/usr/local/lib 
-lboost_system -lboost_filesystem -lboost_program_options-mt -lboost_thread-mt 
-lboost_chrono-mt -ldb_cxx -lssl -lcrypto -lcrypto -lminiupnpc -L/usr/local/lib 
-levent_pthreads -levent_extra -levent_core -L/usr/local/lib -levent_extra 
-levent_core -L/usr/local/lib -lzmq
libtool: link: c++ -o .libs/bitcoind -pthread -Wstack-protector 
-fstack-protector-all -fPIE -O2 -pipe -std=c++14 -Wl,-z -Wl,relro -Wl,-z 
-Wl,now bitcoind-bitcoind.o libbitcoin_server.a libbitcoin_common.a 
libbitcoin_util.a libbitcoin_wallet.a libbitcoin_zmq.a libbitcoin_consensus.a 
crypto/libbitcoin_crypto.a leveldb/libleveldb.a leveldb/libleveldb_sse42.a 
leveldb/libmemenv.a -L.libs -lunivalue -lsecp256k1 -lboost_system -lc++ 
-lc++abi -lpthread -lm -lboost_filesystem -lboost_program_options-mt 
-lboost_thread-mt -lboost_system-mt -lboost_chrono-mt -ldb_cxx -lssl -lcrypto 
-lminiupnpc -levent_pthreads -levent_extra -levent_core -lzmq -lsodium 
-Wl,-rpath-link,/usr/local/lib  
   
.libs/libzmq.so.4.2: warning: sprintf() is often misused, please use snprintf()
.libs/libzmq.so.4.2: warning: strcat() is almost always misused, please use 
strlcat()
.libs/libevent_core.so.1.1: warning: random() may return deterministic values, 
is that what you want?  
   
.libs/libboost_filesystem.so.8.0: warning: strcpy() is almost always misused, 
please use strlcpy()

.libs/libdb_cxx.so.6.0: warning: rand() may return deterministic values, is 
that what you want? 
  
libbitcoin_util.a(libbitcoin_util_a-util.o): In function `SetupEnvironment()':
util.cpp:(.text+0x12ca): undefined reference to 
`boost::filesystem::path::imbue(std::locale const&)'
  
util.cpp:(.text+0x12d5): undefined reference to 
`boost::filesystem::path::imbue(std::locale const&)'
  
libbitcoin_util.a(libbitcoin_util_a-util.o): In function 
`boost::program_options::detail::basic_config_file_iterator::getline(std::string&)':
   
util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs[_ZN5boost15program_options6detail26basic_config_file_iteratorIcE7getlineERSs]+0x98):
 undefined reference to `boost::program_options::to_internal(std::string 
const&)'
libbitcoin_util.a(libbitcoin_util_a-util.o): In function 
`boost::program_options::detail::basic_config_file_iterator::basic_config_file_iterator(std::istream&,
 std::set, std::allocator > 
const&, bool)':
util.cpp:(.text._ZN5boost15program_options6detail26basic_config_file_iteratorIcEC2ERSiRKSt3setISsSt4lessISsESaISsEEb[_ZN5boost15program_options6detail26basic_config_file_iteratorIcEC5ERSiRKSt3setISsSt4lessISsESaISsEEb]+0x21):
 undefined reference to 
`boost::program_options::detail::common_config_file_iterator::common_config_file_iterator(std::set, std::allocator > const&, bool)'
libbitcoin_wallet.a(libbitcoin_wallet_a-db.o): In 

Re: NEW: net/bitcoin

[Joseph Mayer]

2018-05-07 3:21 GMT+08:00 Rafael Sadowski :
> It doesn't build with ports-gcc 

I got it built using ports not too long ago.

What issues did you get trying to build it using gcc-ports (GCC 4.9.4)?

The only issue was the difficulty of install Berkeley DB, which can be
resolved by either building and installing (how?) or something like
--disable-wallet, as only the wallet subfunctionality uses it anyhow,
not the central router.

Do you build the QT and wallet parts?

> and you already said it: "... you wouldn't want to run this on a
> machine that doesn't have clang available to it since it's probably
> far too slow."

Clang may be working well for many projects, this one included, but
there are also projects today where Clang consistently performs
disastrously, so GCC will remain having a valid niche, maybe for very
long.

Re: NEW: net/bitcoin

[Rafael Sadowski]

anyone?

On Sun May 06, 2018 at 09:21:50PM +0200, Rafael Sadowski wrote:
> On Sun May 06, 2018 at 01:23:43PM -0400, Brian Callahan wrote:
> > 
> > On 05/05/18 07:29, Rafael Sadowski wrote:
> > > *ping*
> > > 
> > > On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote:
> > > > Hi ports@
> > > > 
> > > > Attached is a new port for bitcoin. Long time ago pascal@ started
> > > > working on bitcoin in openbsd-wip. I've finished this work and run a 
> > > > full
> > > > bitcoin node over weeks without problems so far:
> > > > 
> > > > https://twitter.com/sizeofvoid/status/976586173538885632
> > > > 
> > > > $ cat net/bitcoin/pkg/DESCR
> > > > 
> > > > Bitcoin is an experimental new digital currency that enables instant
> > > > payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
> > > > technology to operate with no central authority: managing transactions
> > > > and issuing money are carried out collectively by the network.
> > > > Bitcoin is also the name of the open source software which enables
> > > > the use of this currency.
> > > > 
> > > > Ok? Comments?
> > > > 
> > > > Greetings to the hackerroom.
> > > > 
> > > > Rafael Sadowski
> > > 
> > 
> > It reads and builds ok, and bitcoin-qt even launches.
> > I am not going to download the 200GB (!!!) that it wants me to, so that's as
> > far as I can test.
> > portcheck -N complains about hardcoded paths in pkg/bitcoind.rc
> > 
> > One thought from me: is there no hope for this to build on !CLANG_ARCHS?
> > (You only have COMPILER=base-clang ports-clang). Maybe that is the right way
> > to go, since I'm guessing you wouldn't want to run this on a machine that
> > doesn't have clang available to it since it's probably far too slow.
> > 
> > In that case, you don't need that CXXFLAGS line.
> > 
> 
> It doesn't build with ports-gcc and you already said it: "... you
> wouldn't want to run this on a machine that doesn't have clang available
> to it since it's probably far too slow."
> 
> Yes builds fine without CXXFLAGS. Ok with /var -> ${VARBASE}?
> 
> Thanks for test and review!
> 

Re: NEW: net/bitcoin

[Rafael Sadowski]

On Sun May 06, 2018 at 01:23:43PM -0400, Brian Callahan wrote:
> 
> On 05/05/18 07:29, Rafael Sadowski wrote:
> > *ping*
> > 
> > On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote:
> > > Hi ports@
> > > 
> > > Attached is a new port for bitcoin. Long time ago pascal@ started
> > > working on bitcoin in openbsd-wip. I've finished this work and run a full
> > > bitcoin node over weeks without problems so far:
> > > 
> > > https://twitter.com/sizeofvoid/status/976586173538885632
> > > 
> > > $ cat net/bitcoin/pkg/DESCR
> > > 
> > > Bitcoin is an experimental new digital currency that enables instant
> > > payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
> > > technology to operate with no central authority: managing transactions
> > > and issuing money are carried out collectively by the network.
> > > Bitcoin is also the name of the open source software which enables
> > > the use of this currency.
> > > 
> > > Ok? Comments?
> > > 
> > > Greetings to the hackerroom.
> > > 
> > > Rafael Sadowski
> > 
> 
> It reads and builds ok, and bitcoin-qt even launches.
> I am not going to download the 200GB (!!!) that it wants me to, so that's as
> far as I can test.
> portcheck -N complains about hardcoded paths in pkg/bitcoind.rc
> 
> One thought from me: is there no hope for this to build on !CLANG_ARCHS?
> (You only have COMPILER=base-clang ports-clang). Maybe that is the right way
> to go, since I'm guessing you wouldn't want to run this on a machine that
> doesn't have clang available to it since it's probably far too slow.
> 
> In that case, you don't need that CXXFLAGS line.
> 

It doesn't build with ports-gcc and you already said it: "... you
wouldn't want to run this on a machine that doesn't have clang available
to it since it's probably far too slow."

Yes builds fine without CXXFLAGS. Ok with /var -> ${VARBASE}?

Thanks for test and review!

Re: NEW: net/bitcoin

[Brian Callahan]

On 05/05/18 07:29, Rafael Sadowski wrote:

*ping*

On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote:

Hi ports@

Attached is a new port for bitcoin. Long time ago pascal@ started
working on bitcoin in openbsd-wip. I've finished this work and run a full
bitcoin node over weeks without problems so far:

https://twitter.com/sizeofvoid/status/976586173538885632

$ cat net/bitcoin/pkg/DESCR

Bitcoin is an experimental new digital currency that enables instant
payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
technology to operate with no central authority: managing transactions
and issuing money are carried out collectively by the network.
Bitcoin is also the name of the open source software which enables
the use of this currency.

Ok? Comments?

Greetings to the hackerroom.

Rafael Sadowski




It reads and builds ok, and bitcoin-qt even launches.
I am not going to download the 200GB (!!!) that it wants me to, so 
that's as far as I can test.

portcheck -N complains about hardcoded paths in pkg/bitcoind.rc

One thought from me: is there no hope for this to build on !CLANG_ARCHS? 
(You only have COMPILER=base-clang ports-clang). Maybe that is the right 
way to go, since I'm guessing you wouldn't want to run this on a machine 
that doesn't have clang available to it since it's probably far too slow.


In that case, you don't need that CXXFLAGS line.

~Brian

Re: NEW: net/bitcoin

[Rafael Sadowski]

*ping*

On Wed Apr 25, 2018 at 09:31:02PM +0200, Rafael Sadowski wrote:
> Hi ports@
> 
> Attached is a new port for bitcoin. Long time ago pascal@ started
> working on bitcoin in openbsd-wip. I've finished this work and run a full
> bitcoin node over weeks without problems so far:
> 
> https://twitter.com/sizeofvoid/status/976586173538885632
> 
> $ cat net/bitcoin/pkg/DESCR
> 
> Bitcoin is an experimental new digital currency that enables instant
> payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
> technology to operate with no central authority: managing transactions
> and issuing money are carried out collectively by the network.
> Bitcoin is also the name of the open source software which enables
> the use of this currency.
> 
> Ok? Comments?
> 
> Greetings to the hackerroom.
> 
> Rafael Sadowski

NEW: net/bitcoin

[Rafael Sadowski]

Hi ports@

Attached is a new port for bitcoin. Long time ago pascal@ started
working on bitcoin in openbsd-wip. I've finished this work and run a full
bitcoin node over weeks without problems so far:

https://twitter.com/sizeofvoid/status/976586173538885632

$ cat net/bitcoin/pkg/DESCR

Bitcoin is an experimental new digital currency that enables instant
payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
technology to operate with no central authority: managing transactions
and issuing money are carried out collectively by the network.
Bitcoin is also the name of the open source software which enables
the use of this currency.

Ok? Comments?

Greetings to the hackerroom.

Rafael Sadowski


bitcoin.tar.gz
Description: Binary data

Re: new: net/bitcoin

[Christian Weisgerber]

I think everybody who proposes a bitcoin port should consider whether
something that seriously deals with people's money doesn't warrant
special auditing and whether they are prepared to invest that work.

I'm very uncomfortable with shipping our usual it seems to build
and run for me packages and having naive users actually put their
trust in them.  But it is 0P3NB5D! 1T MU57 B3 S3KYOOR!

-- 
Christian naddy Weisgerber  na...@mips.inka.de

Re: new: net/bitcoin

[Alexander Pakhomov]

Welcome, audit it. That would be cool. I guess divide code into separate
processes for gui, core and maybe database would be great.
I actually looked through patches. They obviously fix staff like include dirs.

So you can trust this port as you trust official source.

I don't really care about it since I haven't a LOT of bitcoins.
BTW I don't really understand how to perform reliable security audit.
Remember famous Linux backdoor example?
if ((options == (__WCLONE|__WALL))  (current-uid = 0))
  retval = -EINVAL;
I looked at this code 3 times before I understand where it is...

17.11.2013, 19:15, Christian Weisgerber na...@mips.inka.de:
 I think everybody who proposes a bitcoin port should consider whether
 something that seriously deals with people's money doesn't warrant
 special auditing and whether they are prepared to invest that work.

 I'm very uncomfortable with shipping our usual it seems to build
 and run for me packages and having naive users actually put their
 trust in them.  But it is 0P3NB5D! 1T MU57 B3 S3KYOOR!

 --
 Christian naddy Weisgerber  na...@mips.inka.de

Re: new: net/bitcoin

[Pascal Stumpf]

On Thu, 14 Nov 2013 20:30:37 +, Stuart Henderson wrote:
 On 2013/11/14 12:18, Aaron wrote:
  On Wed, Nov 13, 2013 at 3:07 PM, Alexander Pakhomov ker0...@yandex.ru 
  wrote:
   bitcoin-qt also compiles:
  
   cd /usr/ports/pobj/bitcoin-.../bitcoin-...
   bitcoin-qt.pro: remove -lrt line
   qmake4 BOOST_LIBS_SUFFIX=-mt INCLUDE_PATH+=/usr/local/include/db4
   gmake
  
   Don't know should I make a separate port or it is better to include in 
   this.
  
  Not sure either - but here is a version of just bitcoin-qt :D
 
 The manpages here conflict with the other port in bitcoin.tar.gz..
 Also I noticed when reading the Makefile that there's an internal copy
 of leveldb, can it use leveldb from ports instead?

My version in openbsd-wip does that, so maybe you can use that as a
starting point.

  Maybe a flavor vs a different port?
 
 I don't think a flavour makes sense, if you want to build them in the same
 port then just subpackage the qt interface, separate ports would be fine with
 me too though (but I think I'd have ports/net/bitcoin/qt and
 ports/net/bitcoin/daemon or something, so you can use a Makefile.inc so
 there's less chance of them getting out-of-sync later).

I think the MULTI_PACKAGES approach is the sanest solution; I just didn't
bother with it because I didn't need bitcoin-qt anyway.

Re: new: net/bitcoin

[Aaron]

On Wed, Nov 13, 2013 at 3:07 PM, Alexander Pakhomov ker0...@yandex.ru wrote:
 bitcoin-qt also compiles:

 cd /usr/ports/pobj/bitcoin-.../bitcoin-...
 bitcoin-qt.pro: remove -lrt line
 qmake4 BOOST_LIBS_SUFFIX=-mt INCLUDE_PATH+=/usr/local/include/db4
 gmake

 Don't know should I make a separate port or it is better to include in this.

Not sure either - but here is a version of just bitcoin-qt :D

Maybe a flavor vs a different port?


 12.11.2013, 22:31, Aaron def...@gmail.com:

  On Sat, Jan 12, 2013 at 9:47 AM, David Hill dh...@mindcry.org wrote:
   On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote:
   :On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote:
   : Bitcoin is an experimental new digital currency that enables instant
   : payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
   : technology to operate with no central authority: managing transactions
   : and issuing money are carried out collectively by the network.
   : Bitcoin is also the name of the open source software which enables
   : the use of this currency.
   :
   :
   : Of course, mining is not very efficient on OpenBSD, but it is still
   : useful to manage your wallet, make transactions etc.
   :
   :
   :Updated port attached (0.7.1), latest update done by Alex Bula.
   :
   :ok?

   Updated your port to 0.7.2 and successfully using it on i386.
   Attached is the tarball.
  Updated to 0.8.5 - working great on amd64.  FWIW I can't reproduce
  the deleting /dev/null issue.


bitcoin.tar.gz
Description: GNU Zip compressed data

Re: new: net/bitcoin

[Stuart Henderson]

On 2013/11/14 12:18, Aaron wrote:
 On Wed, Nov 13, 2013 at 3:07 PM, Alexander Pakhomov ker0...@yandex.ru wrote:
  bitcoin-qt also compiles:
 
  cd /usr/ports/pobj/bitcoin-.../bitcoin-...
  bitcoin-qt.pro: remove -lrt line
  qmake4 BOOST_LIBS_SUFFIX=-mt INCLUDE_PATH+=/usr/local/include/db4
  gmake
 
  Don't know should I make a separate port or it is better to include in this.
 
 Not sure either - but here is a version of just bitcoin-qt :D

The manpages here conflict with the other port in bitcoin.tar.gz..
Also I noticed when reading the Makefile that there's an internal copy
of leveldb, can it use leveldb from ports instead?

 Maybe a flavor vs a different port?

I don't think a flavour makes sense, if you want to build them in the same
port then just subpackage the qt interface, separate ports would be fine with
me too though (but I think I'd have ports/net/bitcoin/qt and
ports/net/bitcoin/daemon or something, so you can use a Makefile.inc so
there's less chance of them getting out-of-sync later).

Re: new: net/bitcoin

[Alexander Pakhomov]

bitcoin-qt also compiles:

cd /usr/ports/pobj/bitcoin-.../bitcoin-...
bitcoin-qt.pro: remove -lrt line
qmake4 BOOST_LIBS_SUFFIX=-mt INCLUDE_PATH+=/usr/local/include/db4
gmake

Don't know should I make a separate port or it is better to include in this.

12.11.2013, 22:31, Aaron def...@gmail.com:

  On Sat, Jan 12, 2013 at 9:47 AM, David Hill dh...@mindcry.org wrote:
   On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote:
   :On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote:
   : Bitcoin is an experimental new digital currency that enables instant
   : payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
   : technology to operate with no central authority: managing transactions
   : and issuing money are carried out collectively by the network.
   : Bitcoin is also the name of the open source software which enables
   : the use of this currency.
   :
   :
   : Of course, mining is not very efficient on OpenBSD, but it is still
   : useful to manage your wallet, make transactions etc.
   :
   :
   :Updated port attached (0.7.1), latest update done by Alex Bula.
   :
   :ok?

   Updated your port to 0.7.2 and successfully using it on i386.
   Attached is the tarball.
  Updated to 0.8.5 - working great on amd64.  FWIW I can't reproduce
  the deleting /dev/null issue.

Re: new: net/bitcoin

[Aaron]

On Sat, Jan 12, 2013 at 9:47 AM, David Hill dh...@mindcry.org wrote:
 On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote:
 :On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote:
 : Bitcoin is an experimental new digital currency that enables instant
 : payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
 : technology to operate with no central authority: managing transactions
 : and issuing money are carried out collectively by the network.
 : Bitcoin is also the name of the open source software which enables
 : the use of this currency.
 :
 :
 : Of course, mining is not very efficient on OpenBSD, but it is still
 : useful to manage your wallet, make transactions etc.
 :
 :
 :Updated port attached (0.7.1), latest update done by Alex Bula.
 :
 :ok?

 Updated your port to 0.7.2 and successfully using it on i386.
 Attached is the tarball.



Updated to 0.8.5 - working great on amd64.  FWIW I can't reproduce
the deleting /dev/null issue.


bitcoin.tar.gz
Description: GNU Zip compressed data

Re: new: net/bitcoin

[Fred]

On 11/12/13 18:31, Aaron wrote:

On Sat, Jan 12, 2013 at 9:47 AM, David Hill dh...@mindcry.org wrote:

On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote:
:On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote:
: Bitcoin is an experimental new digital currency that enables instant
: payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
: technology to operate with no central authority: managing transactions
: and issuing money are carried out collectively by the network.
: Bitcoin is also the name of the open source software which enables
: the use of this currency.
:
:
: Of course, mining is not very efficient on OpenBSD, but it is still
: useful to manage your wallet, make transactions etc.
:
:
:Updated port attached (0.7.1), latest update done by Alex Bula.
:
:ok?

Updated your port to 0.7.2 and successfully using it on i386.
Attached is the tarball.




Updated to 0.8.5 - working great on amd64.  FWIW I can't reproduce
the deleting /dev/null issue.



Hi Aaron,

Thanks for the port - I can confirm that it is working well on amd64:

port:fred ~ bitcoind -?|head -1
Bitcoin version v0.8.5.0-gef14a26-beta

port:fred ~ dmesg|head -4
OpenBSD 5.4-current (GENERIC.MP) #117: Sun Nov  3 11:37:42 MST 2013
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 8447131648 (8055MB)
avail mem = 8214102016 (7833MB)

Cheers

Fred

Re: new: net/bitcoin

[Aaron]

On Wed, Mar 20, 2013 at 4:33 PM, Pascal Stumpf pascal.stu...@cubes.de wrote:
 On Tue, 19 Mar 2013 14:53:59 +0100, Pascal Stumpf wrote:
 Version 0.8.1 of the bitcoin port.  Needs the leveldb fix I sent
 earlier.

 Bitcoin is an experimental new digital currency that enables instant
 payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
 technology to operate with no central authority: managing transactions
 and issuing money are carried out collectively by the network.
 Bitcoin is also the name of the open source software which enables
 the use of this currency.

 ok?


 Grr, now a version that actually builds (forgotten patch).

Tested on amd64 - OK from me.

Re: new: net/bitcoin

[Robert Connolly]

On 03/19/13 06:53, Pascal Stumpf wrote:

Version 0.8.1 of the bitcoin port.  Needs the leveldb fix I sent
earlier.

Bitcoin is an experimental new digital currency that enables instant
payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
technology to operate with no central authority: managing transactions
and issuing money are carried out collectively by the network.
Bitcoin is also the name of the open source software which enables
the use of this currency.

ok?
I would like to see this in ports. I'm using another system for Bitcoin 
because I didn't get around porting it to my OBSD laptop.


Thanks

Re: new: net/bitcoin

[Pascal Stumpf]

On Tue, 19 Mar 2013 14:53:59 +0100, Pascal Stumpf wrote:
 Version 0.8.1 of the bitcoin port.  Needs the leveldb fix I sent
 earlier.
 
 Bitcoin is an experimental new digital currency that enables instant
 payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
 technology to operate with no central authority: managing transactions
 and issuing money are carried out collectively by the network.
 Bitcoin is also the name of the open source software which enables
 the use of this currency.
 
 ok?
 

Grr, now a version that actually builds (forgotten patch).


bitcoin.tgz
Description: bitcoin.tgz

new: net/bitcoin

[Pascal Stumpf]

Version 0.8.1 of the bitcoin port.  Needs the leveldb fix I sent
earlier.

Bitcoin is an experimental new digital currency that enables instant
payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
technology to operate with no central authority: managing transactions
and issuing money are carried out collectively by the network.
Bitcoin is also the name of the open source software which enables
the use of this currency.

ok?


bitcoin.tgz
Description: bitcoin.tgz

Re: new: net/bitcoin

[David Hill]

On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote:
:On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote:
: Bitcoin is an experimental new digital currency that enables instant
: payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
: technology to operate with no central authority: managing transactions
: and issuing money are carried out collectively by the network.
: Bitcoin is also the name of the open source software which enables
: the use of this currency.
: 
: 
: Of course, mining is not very efficient on OpenBSD, but it is still
: useful to manage your wallet, make transactions etc.
: 
:
:Updated port attached (0.7.1), latest update done by Alex Bula.
:
:ok?

Updated your port to 0.7.2 and successfully using it on i386.
Attached is the tarball.




bitcoin.tgz
Description: application/tar-gz

Re: new: net/bitcoin

[Pascal Stumpf]

On Sat, 26 May 2012 15:44:31 +0200, Pascal Stumpf wrote:
 Bitcoin is an experimental new digital currency that enables instant
 payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
 technology to operate with no central authority: managing transactions
 and issuing money are carried out collectively by the network.
 Bitcoin is also the name of the open source software which enables
 the use of this currency.
 
 
 Of course, mining is not very efficient on OpenBSD, but it is still
 useful to manage your wallet, make transactions etc.
 

Updated port attached (0.7.1), latest update done by Alex Bula.

ok?


bitcoin.tgz
Description: bitcoin.tgz

Re: new: net/bitcoin

[Gregor Best]

On Sun, Dec 09, 2012 at 05:09:56PM +0100, Pascal Stumpf wrote:
 [...]
 ok?

There seems to be one superflouus file, patches/patch-srd_db.cpp.org.
Can't say anything else yet, it's still building.

-- 
Gregor Best

Re: new: net/bitcoin

[Tom Doherty]

Hi
This works for me on i386 after applying the uvm patch here:
http://old.nabble.com/Re%3A-uvm_fault-page-fault-on-i386-25-May-2012-snapshot-p33936119.html
I'll continue testing once this is fixed in tree
Thanks
Tom

On Sat, May 26, 2012 at 2:44 PM, Pascal Stumpf pascal.stu...@cubes.dewrote:

 Bitcoin is an experimental new digital currency that enables instant
 payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
 technology to operate with no central authority: managing transactions
 and issuing money are carried out collectively by the network.
 Bitcoin is also the name of the open source software which enables
 the use of this currency.


 Of course, mining is not very efficient on OpenBSD, but it is still
 useful to manage your wallet, make transactions etc.

new: net/bitcoin

[Pascal Stumpf]

Bitcoin is an experimental new digital currency that enables instant
payments to anyone, anywhere in the world. Bitcoin uses peer-to-peer
technology to operate with no central authority: managing transactions
and issuing money are carried out collectively by the network.
Bitcoin is also the name of the open source software which enables
the use of this currency.


Of course, mining is not very efficient on OpenBSD, but it is still
useful to manage your wallet, make transactions etc.


bitcoin.tgz
Description: gzip compressed data, from Unix