Bitcoin Forum
May 04, 2024, 05:10:20 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 »
1  Economy / Speculation / Re: rpietila Wall Observer - the Quality TA Thread ;) on: August 21, 2015, 10:43:26 PM
I constantly see posts and articles saying that the price of bitcoin id heavily manipulated. Would it it be fair to say that price manipulation is much more difficult on the large time scale? Would anyone be able to suppress or inflate price for years? Just in case some of you agree that TA based on longer time intervals may sometimes be more useful than based on the recent history, here is a graph of all available history of Bitcoin price.



Haven't seen long term discussions here recently. Can anyone make smart guesses about long term future trends?
2  Alternate cryptocurrencies / Announcements (Altcoins) / Re: How to test-drive the DB on: November 18, 2014, 07:04:37 AM
In my case it is 100% reproducible with or without debugger.
Anyone can tell how to make debug version with unstripped executables?

Sorry for asking stupid questions; it's
Code:
make all-debug

Here is where it crashes:
Code:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7ffbd75fd700 (LWP 14760)]
0x0000000000654dee in cryptonote::Blockchain::handle_alternative_block (
    this=this@entry=0x7fffffffd320, b=..., id=..., bvc=...)
    at .../src/cryptonote_core/blockchain.cpp:1219
1219        else if(m_blocks.back().cumulative_difficulty < bei.cumulative_difficulty) //check if difficulty bigger then in main chain
(gdb) p m_blocks
$1 = std::vector of length 0, capacity 0
The m_blocks is empty. Is it normal? Should the size be checked first? Or is it in completely broken state at this point?
3  Alternate cryptocurrencies / Announcements (Altcoins) / Re: How to test-drive the DB on: November 17, 2014, 01:17:49 AM
In my case it is 100% reproducible with or without debugger.
Anyone can tell how to make debug version with unstripped executables?

Sorry for asking stupid questions; it's
Code:
make all-debug
4  Alternate cryptocurrencies / Announcements (Altcoins) / Re: How to test-drive the DB on: November 17, 2014, 01:14:10 AM
I am at block 308028.  I also got the segfault, but gdb was not running.
I think it crashed in the first while loop.  Now waiting for another segfault..

Test with enabled core dumps (ulimit -c unlimited) for next time


I was running non-debug version, now I run -fsanitize=address -version, so neither gdb nor cores are needed.


In my case it is 100% reproducible with or without debugger.
Anyone can tell how to make debug version with unstripped executables?
5  Alternate cryptocurrencies / Announcements (Altcoins) / Re: How to test-drive the DB on: November 16, 2014, 09:58:35 PM
Sorry, that was the stack of the wrong thread. Here is the one that's causing trouble:
Code:
(gdb) bt
#0  0x0000000000706bc4 in cryptonote::Blockchain::complete_timestamps_vector(unsigned long, std::vector<unsigned long, std::allocator<unsigned long> >&) ()

Remove the stray ; at src/cryptonote_core/blockchain.cpp:1059 , causes infinite loop

Thank you, otila. I have to officially declare myself blind.  Undecided

Now it segfaults in Blockchain::handle_alternative_block(const block& b, const crypto::hash& id, block_verification_context& bvc).

Is anyone able to run it as a main solution? Mine can't cross block 306781.
6  Alternate cryptocurrencies / Announcements (Altcoins) / Re: How to test-drive the DB on: November 16, 2014, 08:19:24 PM
Sorry, that was the stack of the wrong thread. Here is the one that's causing trouble:
Code:
(gdb) bt
#0  0x0000000000706bc4 in cryptonote::Blockchain::complete_timestamps_vector(unsigned long, std::vector<unsigned long, std::allocator<unsigned long> >&) ()

Remove the stray ; at src/cryptonote_core/blockchain.cpp:1059 , causes infinite loop

Thank you, otila. I have to officially declare myself blind.  Undecided
7  Alternate cryptocurrencies / Announcements (Altcoins) / Re: How to test-drive the DB on: November 16, 2014, 03:13:58 AM
Physical or virtual? During a sync from scratch lmdb can request as much as 8gb, but it's all virtual. I've seen well under 100mb of physical RAM in use once it's synced up.

Resident size is what listed as RSS by ps, RES by top or RSIZE by atop. That was after blockchain conversion, few minutes after the daemon finished catching up again. Right now it's dropped to 222.4MB! Smiley

It seems like the daemon is hanging. Sitting at 100% CPU. Responds to console commands until you type "diff", at which point console stop responding to commands. simplewallet can connect, but can't retrieve anything. Here is the stack trace:

Sorry, that was the stack of the wrong thread. Here is the one that's causing trouble:
Code:
(gdb) bt
#0  0x0000000000706bc4 in cryptonote::Blockchain::complete_timestamps_vector(unsigned long, std::vector<unsigned long, std::allocator<unsigned long> >&) ()
#1  0x00000000007104de in cryptonote::Blockchain::handle_alternative_block(cryptonote::block const&, crypto::hash const&, cryptonote::block_verification_context&) ()
#2  0x00000000006e21e6 in cryptonote::Blockchain::add_new_block(cryptonote::block const&, cryptonote::block_verification_context&) ()
#3  0x00000000006e285a in cryptonote::core::handle_incoming_block(std::string const&, cryptonote::block_verification_context&, bool) ()
#4  0x0000000000674822 in cryptonote::t_cryptonote_protocol_handler<cryptonote::core>::handle_response_get_objects(int, cryptonote::NOTIFY_RESPONSE_GET_OBJECTS::request&, cryptonote::cryptonote_connection_context&) ()
#5  0x000000000066d8e6 in int epee::net_utils::buff_to_t_adapter<cryptonote::t_cryptonote_protocol_handler<cryptonote::core>, cryptonote::NOTIFY_RESPONSE_GET_OBJECTS::request, cryptonote::cryptonote_connection_context, boost::_bi::bind_t<int, boost::_mfi::mf3<int, cryptonote::t_cryptonote_protocol_handler<cryptonote::core>, int, cryptonote::NOTIFY_RESPONSE_GET_OBJECTS::request&, cryptonote::cryptonote_connection_context&>, boost::_bi::list4<boost::_bi::value<cryptonote::t_cryptonote_protocol_handler<cryptonote::core>*>, boost::arg<1>, boost::arg<2>, boost::arg<3> > > >(cryptonote::t_cryptonote_protocol_handler<cryptonote::core>*, int, std::string const&, boost::_bi::bind_t<int, boost::_mfi::mf3<int, cryptonote::t_cryptonote_protocol_handler<cryptonote::core>, int, cryptonote::NOTIFY_RESPONSE_GET_OBJECTS::request&, cryptonote::cryptonote_connection_context&>, boost::_b---Type <return> to continue, or q <return> to quit---
i::list4<boost::_bi::value<cryptonote::t_cryptonote_protocol_handler<cryptonote::core>*>, boost::arg<1>, boost::arg<2>, boost::arg<3> > >, cryptonote::cryptonote_connection_context&) [clone .local.1553] [clone .constprop.6383.27838] ()
#6  0x000000000066f7b8 in int nodetool::node_server<cryptonote::t_cryptonote_protocol_handler<cryptonote::core> >::handle_invoke_map<nodetool::p2p_connection_context_t<cryptonote::cryptonote_connection_context> >(bool, int, std::string const&, std::string&, nodetool::p2p_connection_context_t<cryptonote::cryptonote_connection_context>&, bool&) [clone .local.1551] ()
#7  0x0000000000678a73 in nodetool::node_server<cryptonote::t_cryptonote_protocol_handler<cryptonote::core> >::notify(int, std::string const&, nodetool::p2p_connection_context_t<cryptonote::cryptonote_connection_context>&) [clone .local.1549] ()
#8  0x0000000000630eae in epee::levin::async_protocol_handler<nodetool::p2p_connection_context_t<cryptonote::cryptonote_connection_context> >::handle_recv(void const*, unsigned long) [clone .local.3549] ()
#9  0x000000000064bc64 in epee::net_utils::connection<epee::levin::async_protocol_handler<nodetool::p2p_connection_context_t<cryptonote::cryptonote_connection_context> > >::handle_read(boost::system::error_code const&, unsigned long) ()
#10 0x000000000064a3bb in boost::asio::detail::completion_handler<boost::asio::detail::rewrapped_handler<boost::asio::detail::binder2<boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, boost::_bi::bind_t<void, boost::_mfi::mf2<void, epee::net_utils::connection<epee::levin::async_protocol_handler<nodetool::p2p_connection_context_t<cryptonote::cryptonote_connection_context> > >, b---Type <return> to continue, or q <return> to quit---
oost::system::error_code const&, unsigned long>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<epee::net_utils::connection<epee::levin::async_protocol_handler<nodetool::p2p_connection_context_t<cryptonote::cryptonote_connection_context> > > > >, boost::arg<1> (*)(), boost::arg<2> (*)()> >, boost::asio::detail::is_continuation_if_running>, boost::system::error_code, unsigned long>, boost::_bi::bind_t<void, boost::_mfi::mf2<void, epee::net_utils::connection<epee::levin::async_protocol_handler<nodetool::p2p_connection_context_t<cryptonote::cryptonote_connection_context> > >, boost::system::error_code const&, unsigned long>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<epee::net_utils::connection<epee::levin::async_protocol_handler<nodetool::p2p_connection_context_t<cryptonote::cryptonote_connection_context> > > > >, boost::arg<1> (*)(), boost::arg<2> (*)()> > > >::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long)
    ()
#11 0x000000000064b545 in boost::asio::detail::reactive_socket_recv_op<boost::asio::mutable_buffers_1, boost::asio::detail::wrapped_handler<boost::asio::io_service::strand, boost::_bi::bind_t<void, boost::_mfi::mf2<void, epee::net_utils::connection<epee::levin::async_protocol_handler<nodetool::p2p_connection_context_t<cryptonote::cryptonote_connection_context> > >, boost::system::error_code const&, unsigned long>, boost::_bi::list3<boost::_bi::value<boost::shared_ptr<epee::net_utils::connection<epee::levin::async_protocol_handler<nodetool::p2p_connection_context_t<cryptonote::cryptonote_connection_context> > > > >, boost::arg<1> (*)(), boost::arg<2> (*)()> >, boost::asio::detail::is_continuation_if_running> >::---Type <return> to continue, or q <return> to quit---
do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#12 0x00000000006554bd in boost::asio::detail::epoll_reactor::descriptor_state::do_complete(boost::asio::detail::task_io_service*, boost::asio::detail::task_io_service_operation*, boost::system::error_code const&, unsigned long) ()
#13 0x0000000000667e47 in epee::net_utils::boosted_tcp_server<epee::levin::async_protocol_handler<nodetool::p2p_connection_context_t<cryptonote::cryptonote_connection_context> > >::worker_thread() ()
#14 0x00007fa25aaa274a in thread_proxy ()
   from /usr/local/lib/libboost_thread.so.1.55.0
#15 0x00000034e5407ee5 in start_thread () from /lib64/libpthread.so.0
#16 0x00000034e4cf4b8d in clone () from /lib64/libc.so.6
(gdb)
8  Alternate cryptocurrencies / Announcements (Altcoins) / Re: How to test-drive the DB on: November 16, 2014, 02:59:31 AM
Physical or virtual? During a sync from scratch lmdb can request as much as 8gb, but it's all virtual. I've seen well under 100mb of physical RAM in use once it's synced up.

Resident size is what listed as RSS by ps, RES by top or RSIZE by atop. That was after blockchain conversion, few minutes after the daemon finished catching up again. Right now it's dropped to 222.4MB! Smiley

It seems like the daemon is hanging. Sitting at 100% CPU. Responds to console commands until you type "diff", at which point console stop responding to commands. simplewallet can connect, but can't retrieve anything. Here is the stack trace:

Code:
(gdb) bt
#0  0x00000034e540bca0 in pthread_cond_wait@@GLIBC_2.3.2 ()
   from /lib64/libpthread.so.0
#1  0x00000000006565bb in boost::condition_variable::wait(boost::unique_lock<boost::mutex>&) ()
#2  0x00007fed2fe58eb4 in boost::thread::join_noexcept() ()
   from /usr/local/lib/libboost_thread.so.1.55.0
#3  0x0000000000663597 in nodetool::node_server<cryptonote::t_cryptonote_protocol_handler<cryptonote::core> >::run() [clone .local.2695] ()
#4  0x00000000005c71af in main ()
(gdb)
9  Alternate cryptocurrencies / Announcements (Altcoins) / Re: How to test-drive the DB on: November 16, 2014, 02:22:31 AM
Yay!!! My computer is usable again!  Grin
Though the resident size of my bitmonerod is now 1.4GB, not "less than 512MB", as reported by papa_lazzarou.

Physical or virtual? During a sync from scratch lmdb can request as much as 8gb, but it's all virtual. I've seen well under 100mb of physical RAM in use once it's synced up.

Resident size is what listed as RSS by ps, RES by top or RSIZE by atop. That was after blockchain conversion, few minutes after the daemon finished catching up again. Right now it's dropped to 222.4MB! Smiley
10  Alternate cryptocurrencies / Announcements (Altcoins) / Re: How to test-drive the DB on: November 16, 2014, 01:08:09 AM
Feedbacks (both negative and positive) welcomed!

Hi,

The blockchain converter worked fine for me (at least the first 18k blocks). But it was taking ages on my (low end) laptop so I went with osensei's link.

I'm now running a monero node using less than 512MB of RAM. Grin

Can anyone tell what's the size of the resulting database file?

Yup, around 4.3 GB.

Yay!!! My computer is usable again!  Grin
Though the resident size of my bitmonerod is now 1.4GB, not "less than 512MB", as reported by papa_lazzarou.
11  Alternate cryptocurrencies / Announcements (Altcoins) / Re: How to test-drive the DB on: November 15, 2014, 10:24:25 PM
Feedbacks (both negative and positive) welcomed!

Hi,

The blockchain converter worked fine for me (at least the first 18k blocks). But it was taking ages on my (low end) laptop so I went with osensei's link.

I'm now running a monero node using less than 512MB of RAM. Grin

Can anyone tell what's the size of the resulting database file?
12  Bitcoin / Electrum / Re: Electrum server discussion thread on: July 07, 2014, 05:19:29 PM
Third time in 2 or 3 months that the database of my server e2.pdmc.net broke ("wrong_hash"). Is this just me or are other operators experiencing this as well?
Anyway, I'll take my server offline for now and bring it back online once I find enough time to move it faster hardware (probably in August).

I have the same, I moved to Samsung 840 SSD but database is still breaking sometimes, without a clear reason.

I never had this problem, while running the server on a very old and busy box.

Do both of you want to share particulars of your setup to see if there are any similarities?
13  Economy / Economics / Re: (SSS) - A Sane and Simple bitcoin Savings plan on: June 09, 2014, 02:44:04 AM
I was making a suggestion for an improvement for the tool for others, and NOT for myself.  
I have no doubt about that. Sorry if you felt hostility in my comment; it wasn't my intention.
14  Economy / Economics / Re: (SSS) - A Sane and Simple bitcoin Savings plan on: June 08, 2014, 04:07:25 AM
I love you SSS plan http://bitcoinsavingsplan.comSmiley I am using it for Nxt now. Too bad there is not an option to add other crypto's like Nxt.

Thanks, I think it should still work fine as long as you ignore the BTC units  Smiley

I just updated it today based on some requests to be able to modify the "doubling" to other values.  You can now modify the cycle multiplier to trigger a sell on 2x, 1.5x, 1.1x, etc.

Also, if you want to set up a fixed withdrawal rate in fiat, there is an option under the cycle multiplier to calculate that for you based on a given rake %.



I really like this tool, also. 

I do have one suggestion that may make the tool even more amazing, and that would be able to individually modify the multiplier for each cycle.  In that regard, each line would have its own multiplier and I would NOT want to rake very much in earlier cycles; however, in later cycles my rake multiplier would be higher.  So, if I could set the multiplier on each line, then I would really be able to customize the plan to my individualized preference(s)





Next you will want your customizations to be saved for you, because you will feel it's too annoying to redo all the tweaking tomorrow, when you have a new idea. I think the tool is good as it is. If you want something more personalized, you can create your own spreadsheet. Takes just a few minutes. If you want it to be accessible from anywhere, use Google Docs or some other similar service.
15  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [XMR] Monero - Secure, private, untraceable cryptocurrency on: June 07, 2014, 07:23:09 PM
I must be doing something wrong... When I try to transfer more than 1 XMR I get this error msg. I'm using the right command (transfer 0 <Deposit Address> <amount> <Payment ID>) Any ideas?

Error: transaction <2c8673622b1b0197add13c336ed439ee3884252da11417b25bcb2794dde14f4b> is too big. Transaction size: 35187 bytes, transaction size limit: 24400 bytes

Thanks!
You're not doing anything wrong, but there is a limit on transaction size. You have received many small transactions thus your transaction will use very many inputs and in total it is above transaction limit. To fix this send smaller amounts. If you need to send exactly 1 XMR you could setup another wallet where you transfer funds first, e.g in increments of 0.1 XMR or whatever is the maximum you can send.

Also, switch to a smaller pool, so your payments are less frequent but larger in size.
16  Bitcoin / Electrum / Re: [ANNOUNCE] Electrum - Lightweight Bitcoin Client on: May 16, 2014, 05:35:42 AM
What does the server see? I mean in case someone looks at the server data can he see all the addresses that are connected to one wallet?

Yes.

Quote
Though i guess the label sync plugin should be able to provide the same data, even for more than one wallet when using the same plugin website login.

I believe that data is encrypted before being sent to the server.

edit: see  https://bitcointalk.org/index.php?topic=154144.0

Oh... doesnt sound good... I mean who knows what those data could be useful for if such a electrum server gets hacked or seized. And the server operator could see it all the time. The same goes for the plugin server.

So its possible to identify the complete wallet, addresses, transactions and property of a certain user only by finding one hint. I dont like thinking about this and im a bit angry why i didnt think about this earlier.

I thought it would be better to create a new wallet and a new plugin account with new email sometimes. But now i think using electrum is a risk in itself. You need to trust every server provider (when using auto connect, which is the standard) and you need to hope the server nor the plugin server gets hacked. Sounds a bit risky. The coins cant be stolen but it sounds still too much for me.

You can run your own server if that is bothering you so much.
17  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN][MRO] Monero - Anonymous Currency Based on Ring Signatures on: May 14, 2014, 01:02:56 AM
Does anyone know how to extract private key out of wallet?

And, if it's at all possible, how to create a wallet having a private key?
18  Bitcoin / Electrum / Re: "Not connected" issue again. on: May 08, 2014, 05:46:23 AM
SSL and https usually mean the same thing.
They should, but not in my experience with Electrum.

SSL means there is persistent connection encrypted with SSL, HTTPS means HTTP over SSL. So not same; not only in Electrum.

To rule out bad network configuration, can you try to connect to any of the servers outside of Electrum? Try:

nc -v servername 50002

And see if it says "connected".

I don't think Electrum servers are dropping SSL support. Have you changed your router recently by any chance?
19  Bitcoin / Wallet software / Re: Need help - Bitcoin deamon client on: April 25, 2014, 06:24:05 PM
Look at how to run Electrum with console interface: electrum -gstdio
and check out this project: https://github.com/spesmilo/sx
20  Bitcoin / Electrum / Re: Electrum server discussion thread on: April 25, 2014, 12:36:08 AM
Redownloading latest DB indeed fixed the problem.

Now I wonder what the following lines mean. Is this normal?

[24/04/2014-00:33:26] utxo not in database; postponing mempool update
[24/04/2014-00:33:37] utxo not in database; postponing mempool update
Pages: [1] 2 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!