Bitcoin Forum
August 26, 2016, 11:24:23 PM *
News: When 0.13.0 is released in the near future, make sure that you carefully verify it.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 106 »
501  Bitcoin / Development & Technical Discussion / Re: Dynamically Controlled Bitcoin Block Size Max Cap on: August 29, 2015, 10:15:10 AM
Thanks to everyone for providing good arguements for improvement of the proposal. I have derived a second proposal and updated OP accordingly. If you have any counter-arguement to this proposal, feel free to put it here or in the comment section of the article - http://upalc.com/maxblocksize.php

I would insist on implementing a decay function for the sake of spam control and to prevent gaming the system.

I will repeat my point: the status quo path, where the current size is maintained if no increase/decrease is triggered is damaging in that it becomes trivial to maintain a size increase after a spam attack or in case a miner wants to game the system. At the same time a decrease becomes quasi impossible with the current thresholds.

An increase should be triggered at 66~75% capacity, not ~50%, and the fees should be at least 20% superior to the cumulated subsidy of the previous period. This is critical as it forces an attacker to compound his effort to inflict several unnatural increase on the network instead of simply giving the network a nudge and maintaining the increase trivially.

The goal of this proposal is to automatically adapt the max block size to the demand, not to offer a voting mechanism where spammers and large miners alike can pump up the block size and keep it there at minimal cost. If this is what you are aiming for, then Garzik's approach makes more sense.

In order to dynamically resize the block ceiling, the algorithm needs to distinguish between spam/attacks and organic growth. The simplest way to one from the other is that spam is acute, organic growth is chronic (or long lasting if you prefer). This means natural growth will always eventually trigger an increase, which is why tighter thresholds make sense. Natural growth will always manage to get to a sane threshold, but the higher the threshold, the more expensive it is to game the system.

However, in case the attacker is willing to pay the price for an upscaling, the effect of that attack should fade once the attack is over, which why we should have a decay function instead of a status quo condition. Only organic growth will be powerful enough to maintain a ceiling increase. With proper thresholds, an attacker would have to keep on spending more fees and increasing the difficultly significantly to keep the ceiling on growing, which is the only way he'd have to force in a lasting effect. At this point he is better off just mining for profit as a sane market actor, which is what a PoW blockchain relies on to begin with: there is more profit in participating to the network than to attack it.
502  Bitcoin / Armory / Re: Bitcoin-QT management on Mac on: August 29, 2015, 09:50:52 AM
--satoshi-datadir is used to point to the /blocks folder (holding the raw blockchain data), not the binary folder.
503  Bitcoin / Armory / Re: [Armory]Dont have the blockchain and bitcoin.conf stored per user. on: August 29, 2015, 09:44:55 AM
All your posts are complaining about default features, which is what auto bitcoind management is meant for. If you learn how to use Armory you can easily come up with a very specific setup suiting your needs. But do not expect the default one size fit all setting to accommodate that.
504  Bitcoin / Armory / Re: stuck or good? on: August 29, 2015, 09:42:45 AM
To make sure I understand.. Since I can't run bitcoind as a background process started from Armory, in order to keep an Armory wallet on my computer, I have to keep Bitcoin Core and Armory running side-by-side constantly..?

For Armory to go online, it needs a local instance of Core. If auto bitcoind is failing, you will have to Start BitcoinQt manually prior to starting Armory every time. It is critical that BitcoinQt is fully sync'd before you start Armory, so if you have not run Core in a few days, let it catch up before you start Armory.

Quote
Latest thing I'm having now: I start Armory and it seems suddenly stuck at organizing blockchain ?!

Log files please

Quote
any suggestions on trouble-shooting bitcoind crashing when started from Armory?

Probably something to do with your /blocks or binary path (the ones in File -> Settings). It is either getting mangled or it's invalid (non ASCII chars?). Auto bitcoind is a feature for default setups, i.e. you didn't customize your system and installation at all. If you intent to customize (like you did), I strongly suggest against using auto bitcoind.
505  Bitcoin / Armory / Re: armory Question on: August 28, 2015, 01:14:27 PM
Can you tell me how Bitcoin Core output uncompressed key?

Sorry I do not know how to use Core for that purpose. You would have to ask on http://bitcoin.stackexchange.com or on IRC. Worst case scenario, there should be some Python tools on github that would do the conversion for you.

Quote
I hope very soon to a supported version.
...
I suggest you software support Chinese, Bitcoin in China is very hot.

The problems are tied together. The old wallets do not support compressed private keys nor unicode characters. We can't allow for internationalization until we come out with the new wallets, because any non ascii text input in the current wallet format has a high chance of corrupting the file.
506  Bitcoin / Armory / Re: armory Question on: August 28, 2015, 09:58:09 AM
Not the private keys starting by L nor the public keys starting by 02 or 03. There will be support in later versions. That code is 95% done but it doesn't have a version target yet. There ought to be a way for Core to export uncompressed private keys.

Btw, I don't know why you want to import a private key into Armory but keep in mind that it isn't recommended.


507  Bitcoin / Armory / Re: armory Question on: August 28, 2015, 07:47:45 AM
That's a compressed private key. Armory doesn't handle those yet, use the 32 byte private key instead (64 hex characters).
508  Bitcoin / Armory / Re: stuck or good? on: August 27, 2015, 10:06:57 PM
From your log file, it appears bitcoind is crashing when Armory is trying to start it. I guess it probably has something to do with permissions on the folder holding the binary (exec permission probably). That or the blockchain folder Armory passes as an argument is getting mangled somehow.

For now, turn off auto bitcoind management. To do so, start Armory, go to File -> Settings and uncheck the first checkbox (you should also to a Help -> Rebuild and Rescan for the good measure). Close Armory, start BitcoinQt manually, then start Armory again, it should pick up from there.
509  Bitcoin / Armory / Re: armory Question on: August 27, 2015, 09:05:00 PM
Did the private key start with L?
510  Bitcoin / Armory / Re: stuck or good? on: August 27, 2015, 07:17:01 PM
If it is fully synced and Armory is still stuck, I'll need to see a log file.
511  Bitcoin / Development & Technical Discussion / Re: New Proposal to reduce space requirements for full nodes on: August 27, 2015, 10:16:24 AM
I am aware of that. But today you cannot spend coins which are in the pruned blocks. That should be solved.

Why not? My understanding of pruned blocks is that they keep all UTXOs with the necessary intermediary hashes to compute the merkle root. What pruned blocks get rid of is transaction history, unspent coins scripts are still all there.
512  Bitcoin / Armory / Re: How to reach support on: August 26, 2015, 03:53:24 PM
Should work now
513  Bitcoin / Armory / Re: Starting preliminary 0.94 testing - "Headless fullnode" on: August 26, 2015, 02:04:54 PM
You are missing some block data starting 353055, which is why Armory can't scan any futher.

In your blocks folder, you should delete the last few blk files, probably up to blk00320.dat (315 to be on safe side) and the associated rev files (rev00320.dat and so on). Then start BitcoinQt, it will tell you its DB is corrupt and rebuild it from scratch, download the last few missing files in the process.

Once that is done, start Armory, it should recover from that.
514  Bitcoin / Armory / Re: Starting preliminary 0.94 testing - "Headless fullnode" on: August 26, 2015, 06:40:30 AM
So you are saying it takes 24h+ to crash? Can you keep an eye on the process memory? I'll run some tests on my own.

I got a third crash at 20150825_2016. It looks like Armory has to have been running for 24++ hrs in order to
get to the condition that triggers the std::bad_alloc. The approximate 48 hr interval that I see is probably due to
the fixed times of day that I use the PC. I sent 1.5BTC from bitcoin-qt to Armory-watch. Armory popped up the
std::bad_alloc window a few seconds after bitcoin-qt said it had sent the TX. I think the problem occurs when
Armory receives the raw TX. After restarting, it gets the TX from the block without a problem (but that's not after
a 24++ hr delay).

The memory usage remained fairly constant for the 48 hrs, including after the exception.
  Armory:   VIRT = 1052M  RES = 288M   SHR = 19M
  Bitcoin-qt  VIRT = 1121M  RES = 404M   SHR = 12M

I'm not having any success debuging ArmoryQt.py with gdb. I'll just try to get a crash in less than 48 hrs.


What's the total size of your DB? The headers DB alone?

https://github.com/etotheipi/BitcoinArmory/blob/ffreeze/cppForSwig/mdb/mdb.c#L588

Reduce this value to 16MB and rebuild a new DB with that, see if it suffers from the bad_alloc.
515  Bitcoin / Armory / Re: Starting preliminary 0.94 testing - "Headless fullnode" on: August 24, 2015, 09:55:55 PM
I got a first std::bad_alloc crash at 20150821_1449.
I restarted Armory under gdb.
I got the second std::bad_alloc crash at 20150823_2125.

So you are saying it takes 24h+ to crash? Can you keep an eye on the process memory? I'll run some tests on my own.
516  Bitcoin / Armory / Re: Starting preliminary 0.94 testing - "Headless fullnode" on: August 24, 2015, 04:46:51 PM
We don't use realloc directly, and very little malloc anyways.

It is most likely a std container failing to get enough memory. The issue isn't so much that the addressing failed but whether it is because it ran out of RAM or it was passed a bad ptr. If this is happening in a std container, which we rely heavily upon, then it's the former.

Did the issue happen after scanning the whole chain or was it in a freshly started process?
517  Bitcoin / Armory / Re: Tutorial: Compiling Armory and getting it onto an offline computer on: August 24, 2015, 04:37:06 PM
Any USB device comes with a firmware and class negotiation, even a plain hub. These manufacturers don't come up with their own MCUs, they buy generic MCUs from large manufacturers like TI, Microchip and FTDI. They upload a USB firmware in the MCU's NVRAM and this the vulnerability root kits target to survive a power cycle.
518  Bitcoin / Armory / Re: Starting preliminary 0.94 testing - "Headless fullnode" on: August 24, 2015, 04:32:58 PM
bad_alloc usually means the process failed to allocate more RAM. I'd like to make sure this is not happening on a x86 machine first before I investigate.
519  Bitcoin / Armory / Re: stuck or good? on: August 24, 2015, 04:17:28 PM
Shutdown Armory, start BitcoinQt manually and let it do it's thing. If it is fully synced and Armory is still stuck, I'll need to see a log file.
520  Bitcoin / Armory / Re: Starting preliminary 0.94 testing - "Headless fullnode" on: August 24, 2015, 04:13:28 PM
I'm pretty sure Core 2 can handle both x86 and x64 OSes, so this isn't really helping me. Browse to Armory's binary folder, and run this command and paste the result back:

Code:
file _CppBlockUtils.so
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 [26] 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 ... 106 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!