But the adding of a single transaction to a single block can trigger a lot of searches.
Example:
1. You want to add transaction A with a conflict to already added transaction B.
2. You make two leaves: one with the old block (with B), second with A added (and B removed).
3. Now you have to search the whole block for transactions that depended on B.
4. Now you have to search the whole block for transactions dependent on the transactions from step 3 and so on.
Yup, you don't scan though. You would keep the block as a DAG, prune a node and its dependents. |
|
|
|
|
I was thinking more along the lines of maintaining several blocks - pretty much like the blockchain handles forks.
Normally - only 1 block. The tree is a single root block.
When you receive a tx:
go through every leaf :
- try to add it to that leaf.
- If there is a replaceable tx, split the leaf into two. One with the old tx, one with the new one.
- Update the total fees
- If total fees > current max, update current max, set current block as best - switch hashing to this block
It's 1MB per block and it will become costly if there are many splits but you can optimize better by sharing the common txs in the lowest common ancestor.
But yeah - not worth the effort.
|
|
|
|
So i find more of a security issue the following:[/b]
-the corrupting of the Armory client by either a phishing site gives fake download file with hacked armory keylogger protocol built in.
Of course i use PGP verification every time I download, but it still has a light chance
-more likely is that if a virus gets downloaded from a faucet (high probability of viruses there), but i got good antivirus, so every time a file tries to modify something either it needs admin acces from PC or if its an injector then the antivirus should detect that
Even if your online PC is 100% compromised, your funds are safe as long as you follow the armory cold storage workflow. In particular - check what you are signing. -the other security concern is the 51% attack and somehow a client infiltrating the network and reversing transactions:
for example a fake/malicious exchange will quickly reverse the transactions before enough confirmations apply
51% of the total hashing power is insanely hard to get. Currently, it is like finding a single grain of sand in the world. And even if someone can, he will go after the big addresses. Some of them have tens of millions of $. -or another security issue is the corrupt blockchain, as someone could infiltrate the chain and fill it up with fake blockchain contents so that after he could mess up a few accounts
Same as above What do you think about these security problems?
Don't worry |
|
|
|
Miners could do that, but I think there is no efficient strategy to arrange an optimal combination of transactions.
When miners get a number of transactions, the obvious thing to do is the following:
1. Check whether the first transaction is consistent with the blockchain, if it is, add it to the mempool.
2. Check whether the next transaction is consistent with the blockchain AND the mempool.
3. GOTO 2.
Now, a transaction that is inconsistent with the pool may yield a higher fee if included and the conflicting transactions are removed. But it is not just one transaction versus the other. You might kick out a low-fee transaction and put your new transaction in. But your new transaction may make a third transaction invalid, and removing that one might make another one invalid and so on. An all these transactions have fees and you want to maximize the sum.
For me this smells like an NP-complete problem.
You can evaluate the total cost of switching a tx vs another. It would become hard if you have a lot of conflicting tx influencing each other but I doubt it happens often - a simple decision tree works. In any case, fishing for the extra few decimilli btc doesn't seem worthwhile. |
|
|
|
I removed my message while I was working out how to use uP|x. In my message I wrote k = uP|x which I realized later doesn't work.
Adam's modified version should work, shouldn't it?
Yes/no. I thought it was nice at first but then I realized it's no better than my two move scheme, I think. The signer knows the resulting r that will show up in the signature so he can grind u to stuff bits into it.  I can't see how this can be avoided without blinding the signature but this would require a hard fork. |
|
|
|
|
Regarding the original problem: Have you checked if it's not a port forwarding issue? Maybe your DHCP lease expired and your machine got a new IP.
|
|
|
|
|
I removed my message while I was working out how to use uP|x. In my message I wrote k = uP|x which I realized later doesn't work.
Adam's modified version should work, shouldn't it?
|
|
|
|
|
All the security is based on the same assumptions. True, if you break the master key algo you can claim all the wallet contents. But it is as difficult to break the Armory algo than to break a single address. If an attacker knows how to do that, he could simply repeat the process with all your addresses. Actually he would go after the address that holds thousands of bitcoins and retire on his private island.
It does make your master key more valuable to protect. But it's easier to be careful about one key than to be careful about a thousand keys.
PS: Armory algo is public and has been peer-reviewed.
TL;DR - If you have ten locks of the same model on your door, it's not more secure than having a single one.
|
|
|
|
|
Try with curl first to narrow down the issue to JSON vs PHP.
|
|
|
|
|
As to why it is happening only when bitcoind is running: its database part is IO intensive. The OS cache should improve performance by quite a lot. In any case, this RAM is not claimed by other processes and would be sitting with garbage in it otherwise. When a process requests more memory, the OS will automatically reduce the cache size at nearly no cost (just maintenance of the page pool directory).
|
|
|
|
It should be used by buffers/cache not by processes. @OP List processes by memory usage ps -e -orss=,args= | sort -b -k1,1n |
|
|
|
|
10% used by bitcoind. Why do you say it eats the whole server ram?
|
|
|
|
I think the 51% problem is stated inaccurately here.
The actual problem is that with 51% hashing power, a malicious miner can refuse to mine on any chain which includes blocks mined by other miners, and can get away with it (i.e. his chain will be considered the real blockchain after some time).
Example:
(blocks mined by miner A, B or C are suffixed with a, b or c)
Miner A has more than 50% of hashpower.
All miners start with block 100.
- Miner A mines block 101a, broadcasts it, every other miner switches to 101a as the new head of the block chain.
- Miner B mines block 102b (based on 101a), he and miner C switch to 102b as the new head of block chain, A ignores it and stays with 101a.
- Miner C mines block 103c (based on 102b), which is used as the new blockchain head by B and C. A still stays with 101a.
- Miner A finally manages to mine block 102a (based on 101a), broadcasts it. Other miners ignore it since this chain is shorter than the 103c chain.
- Miner A manages to mine block 103a (based on 102a) before B or C mine a block, and broadcasts it. Depending on the calculations of the amount of work that went into each block, this may be accepted as the new head of the block chain, orphaning both 102b and 103c.
103a does not orphan 103c because it has the same amount of work. Work is calculated based on the difficulty not on the hash. However, a 51% miner eventually will be able to release a block before the rest of the miners. @OP, Bitcoin is essentially a senate. The blockchain is a recording of the laws passed. Normally, members will vote on the same laws and everything goes smoothly. If someone wants to disrupt the system by himself, he needs at least the majority. Without it, he can still succeed but his chances decline. He could also be sure to win if the other members don't agree. It's why it's important to have very stable software in a consensus system. |
|
|
|
|
You don't need to find them in a row, just faster than other people. They can add transactions but you can remove them by making their chain orphaned.
|
|
|
|
|
It'd help by trimming the addresses that have no unspent outputs but it'd take much more than 10 blocks. There are several million addresses in use and more than 1 GB of active data. The blockchain is at 27 GB, it's still a considerable win but it would take several days of downtime.
|
|
|
|
3.3 The user sends z, P = t*G to the signer
3.4 The signer selects k = u*P and performs ECDSA
It's not exactly the same. ECDSA security is based on the difficulty of the discrete log of the subgroup. AFAIK, I does not require the additional assumption of the difficulty of DH on the curve. But this does not seems to be a problem, since P is not published. DDH holds for EC over GF(p) provided it has a large embedding degree which as far as I know is the case for secp256k1. k|x should be indistinguishable from random. Then again, I'm not going to pretend I know this stuff so I'm most likely wrong. If it works, you wouldn't have to do an additional data transfer from offline storage which usually involves plugging/unplugging a USB drive - that's nice. |
|
|
|
|
You are linking to a page that states the conjecture is disproved. And by something related to bitcoin nonetheless.
|
|
|
|
Thanks for trying, I appreciate it. ECDSASigner is a bouncycastle class that accepts an optional provider for the nonce https://github.com/bcgit/bc-java/blob/master/core/src/main/java/org/bouncycastle/crypto/signers/DSAKCalculator.java. The implementation of ECDSASigner will pass the secret to the k calculator. It's done in val kGen = new RFC6979KCalculator
val signer = new ECDSASigner(kGen)
val params = new ECPrivateKeyParameters(secret.bigInteger, Bitcoin.ecDomain)
Then it comes to DSAKCalculator through override def init(q: BigInteger, x: BigInteger, m: Array[Byte]): Unit
which is Scala for /**
* Deterministic initialiser.
*
* @param n the order of the DSA group.
* @param d the DSA private value.
* @param message the message being signed.
*/
void init(BigInteger n, BigInteger d, byte[] message);
The rest is RFC6979. I think he meant code revision in general, not just for this single potential bug. You can't just review a Bitcoin wallet by reading it once or twice, it's way too complicated. So better stick with known code that has some user base actually testing it.
I wrote this wallet because there is no implementation that fits my need and that I feel confident enough with. Basically for the same reasons that you mention. The most popular wallets don't have the features I want and the others are not reviewed enough to qualify either. I tried to reduce risk as much as I could by using standard libraries where possible. It leaves BIP32, RFC6979 and tx serialization to write. It's hard but I wouldn't call this impossible to do. I welcome as much review as possible. Maybe you could take a look? Thanks, --h |
|
|
|
|
Show Posts
