|
Mmmm - well, it bootstraps, syncs and validates the blockchain. It passes the acceptance tests from Matt too. As a relay node, it keeps a tx pool, validates, relays new tx and you can trim old blocks just by deleting files. I've been running for a while.
At about 2k lines of code, it fits my requirement of small code that I can fit in my brain but I understand it's not 100% compatible and will never be.
|
|
|
|
|
Good advice but that defeats the reason I'm running my node. I'd like something small, light on memory usage and disk space that still does full validation. I ended up writing it myself.
|
|
|
|
|
Yes, it's done in CheckBlockHeader called from CheckBlock preventing the block from being cached.
|
|
|
|
Orphan blocks are a different case than an 2hr shift. When dealing with bitcoin edge cases are very common and sometimes not very well handled. What if half of the miners rejected the block and half accepted the block due to different local times? Then you would have different parts of the network contributing to different forks which is not as cut and dried as an orphan block. It would not be impossible, though highly unlikely.
It's even harder to accomplish because the 2h are relative to the client's current time. As time passes by, a previously rejected block has a higher chance to get accepted. |
|
|
|
First of all, I don't think they are many people who do not rely on bitcoin core professionally. Some run a different implementation for personal use but when money is at stake the risk of loss is too high. Even if it is a small bug that makes you miss a transaction, it could be a very large transaction that ends up costing you your business. So alternate implementations are mostly for side projects, and even if they fork, their impact on the consensus is too small to provoke a split. In fact, the current opinion is that none of the alternate implementations are fully compliant with bitcoin core ( https://bitcointalk.org/index.php?topic=923409.0). In deciding what to do regarding a potential fork, I think we should ignore the impact on alternate implementations. Since you talk about a bug in bitcoin core, it is a different story altogether. Let's say someone found a major difference which would split the chain. If only client nodes are affected, it would mess up network propagation. If miners are affected, it may split the blockchain. Most likely, people will lose money and they don't care whether it helps fixing bugs or not. I wouldn't care either. I don't think the damage on the credibility of bitcoin is worth the extra kick in the anthill though I have the opposite opinion if we were talking about an altcoin. |
|
|
|
|
In a classical collision attack, you don't get to choose the messages. You found two messages that hash to the same value but they would not parse as a transaction. A chosen prefix collision attack is much stronger.
|
|
|
|
|
If SHA-256 is broken in such a way that I have an algorithm that instantly tells me what to change in a block of bytes so that the hash = anything you give me:
1. I pick a transaction that you have already signed in the past.
It has a valid signature but it's only valid for a given tx hash.
If you are using the same pub key, there is some other unspent output
I create a tx that sends that to me. The tx hash will be different to start with.
But I can adjust the output and use that as a nonce - I just have to add
an OP_RETURN. By changing the content of that output, I will change the
tx hash. If I know how to reverse sha-256 I know how to make the new
tx hash match the one from the tx that you signed and your coins will be
sent to me.
2. Mining aims to find a block hash < target. If I could find a nonce that makes the blockhash equal to anything I want, obviously the target doesn't matter.
Basically, this is equivalent to have unlimited hashing power. While other people have to work by trial and error, I would have a crystal ball that locates what they are looking for.
But that's a big if. Note that even the previous hashes didn't fail in such a catastrophic way and yet were retired. The crypto community is very cautious.
|
|
|
|
|
@grau & @justus, no offense but your debate is quite off-topic. If you must discuss the pros/cons of alternate implementations on altcoins, could you create your own thread?
|
|
|
|
|
I ran Matt's test harness on bitcoin core 0.9.3 and an assertion was raised. Then I tried on my code and realized that the test harness relies on a specific message order or it deadlocks. After that I started debugging the test harness and got a headache. Maybe it is time to surrender.
|
|
|
|
You could be right, but if that's the case then either these alternate implementations do not pass all of your consensus tests (in which case they are definitely at fault) or the bitcoin core product must be considered to have one or more serious bugs in either the code or the consensus test suite.
Bugs are acceptable in consensus code. English has plenty of exceptions in grammar and spelling but as long as we follow them we understand each other. I would bet any amount of money that none of the complete reimplementation that I am aware of are consensus consistent.
If you're doing something for educational purposes, then obviously the stakes are less severe. If the prospect of inventing novel ways to assure consistency excites you, then you should do so enlighten the world... but if it doesn't, why are you implementing a Bitcoin full node? Effectively, achieving consistency _is_ the tasks, if you don't enjoy that tasks you'd probably be better of finding a project to work on that where you do enjoy the work of it.
I'm implementing a full node for a couple of things. 1. to make sure i have a complete understanding of the implementation that goes beyond reviewing code. For me, it's like reading a book versus writing one. 2. all the implementations i have seen follow a similar logic specially wrt blockchain management and scripting. i wanted to do it my way to see if it's better or worse. 3. i'm aiming for short. no wallet, no mining, no dos protection. These goals in mind, it is clearly not fit for wide distribution. It's working fine though - being able to sync up from the beginning while validating, holding a mempool content identical to the core client and etc. But it's reaching a point of diminishing returns. The consensus rules I know I'm not implementing add weight but aren't particular challenging. So I was thinking about looking at another guy who faced the same problem to see where the road ends and whether it's worth going the extra few miles. If no one is consensus consistent then I need to revisit my plan. |
|
|
|
I think the best answer is "we don't know". Even bitcoin core has been found to not be 100% compatible with itself ( https://bitcoin.org/en/alert/2013-03-11-chain-fork). I believe that btcd( https://github.com/conformal/btcd) passes all known consensus tests and I have been running a node for months without forking. I don't know exactly what you are trying to accomplish, but your best approach is likely to pick a client that meets your needs and automate what you want to happen if/when a fork occurs. Even if you are on the "correct" side of the fork, if there are 2 competing forks the most prudent behavior is likely to shutdown until one fork significantly outpaces the other. Like several people I am writing a full node for educational purposes and I want to do a good job. Its structure is quite different than other implementations (I reviewed a few) because it's in a functional language and therefore I'm sure it's not the same as bitcoin core. Unfortunately, testing is difficult because verifying a block is biased towards accepting. If your implementation rejects a block that has a valid hash, you are wrong simply because no miner would produce a bad block today. So you might as well have 'return true'. Bitcore has a series of tests but i'm not using c++ and I'd need to port them. Your link refers to some trip test that I will try out. Any suggestions are welcome. |
|
|
|
Compatible in what way? RPC, P2P, consensus code?
consensus code |
|
|
|
|
100%... not 99.999%. I know it's very difficult.
Do the miners actually use bitcoin core too?
|
|
|
|
Or was there some way of assigning bit values to the cards? I left it out of my suggestion, because I couldn't remember how to do it.
You probably could but it would be tedious. I never came up with any such system. At some point one needs to trust something. Still if one absolutely needed to generate the private key by hand only then the simplest (although not the most efficient) would be to just look at the suits but it would require at least 3 (4 is probably better) passes through the deck. It is possible to assign a bit value to permutations, but I couldn't tell you exactly how to do it. You can't assign bit values directly to cards (at least in the way I'm thinking), because 52^52 > 2^256. It is very similar to Project Euler's Problem 24. By analogy for a 3-card deck: assign each permutation a number value. 1: 012 2: 021 3: 102 4: 120 5: 201 6: 210 Represent this as a 3-bit value. That's your private key, with ~2.6 bits of entropy. This analogy can also show you why a straightforward conversion like "represent each card as a base 3 digit in the number, then convert to binary" won't work: 222_3 = 26, which would require 5 bits to store in binary, not just 3. If you use permutations of a deck of cards you get 52! possibilities which is <2^256. You need a few more cards. To convert a given permutation to a number with a pen and paper you can do this using 1 2 0 as en example - go from left to right, write the digit you see and then change the number to the right by subtracting 1 to every number that is greater than that digit 1 2 0 -> first digit 1, rest is 2 0 -> write 1, update the rest to 1 0 -> now we have 1 1 0 1 1 0 -> second digit is 1, rest is 0 -> write 1, the rest doesn't change -> final list 1 1 0 - ditch the last digit => now we have 1 1 - keep an accumulator. set it to 0 => acc = 0 - go left to right, pair the digit with a counter that starts at the length of the list (here 2) and decrements by 1 => + every step, sum the digit with the acc and multiply by the counter + store the result in the acc => step 1: acc = 0, cnt = 2, digit = 1 => acc = 0 + 2*1 = 2 => step 2: acc = 2, cnt = 1, digit = 1 => acc = 2 + 1*1 = 3 The final value of your acc is your permutation number. perm :: [Int] -> [Int]
perm [] = []
perm (top:rest) = top:perm [if x>top then x-1 else x|x <-rest]
permN :: [Int] -> Int
permN deck =
let trim = init(perm deck)
n = length trim
in foldl (\acc (c,d) -> (acc+d)*c) 0 (zip [n,n-1..1] trim)
|
|
|
|
@johoe: sorry, didn't want to steal your post. I waited 30mn  Just a precision - doesn't have to be linear, any algebric equation between the k and you are good to go. |
|
|
|
Only, if the k values are . . . not independent (e.g. first k is random, second is k+1), then the private key can be computed.
Are you sure about this? I thought I read otherwise, but I might be thinking of something else. Yes, as @dabura explained, the main point comes from the definition of s = (z+dr)/k: 1 equation, 2 unknowns (d and k). Therefore an infinite number of solutions. If you add another signature, you now have 2 equations and 3 unknowns (d, k1, k2). BUT if you happen to have a relation between k1 and k2, now you can solve it. It's trivial if k1=k2, just a bit harder if k2 = k1 + 1. @Evil-Knievel: if you sign a transaction that has several inputs with the same address, the signed messages are still different since the signing algorithm takes the position of the input to be signed into account.
This doesn't sound right at all. Can you provide a link to a source that describes how the position of the input effects the resulting signature? When you sign the tx, you replace part of the tx with the previous pubscript and blank out the other scripts. So if you do that for the 1st txin, the resulting tx to sign is different than if you do it for the 2nd... |
|
|
|
|
The signature doesn't check out. How did you make it?
txHash should be "73b3b2795aa0826233122d6c0992e5a051562d10bc9e84700daf4a1329c47981"
|
|
|
|
The multi-sig is not on the part of the user, it is between Bitstamp and BitGo. While they haven't revealed any details on their precise operation, it is most likely something like this:
Bitstamp has 2 keys to addresses associated with their hot wallet and deposit addresses, BitGo has one and all addresses are 2-of-3 multisig. Bitstamp keeps 1 key for each address offline and 1 on its hot wallet machine. When a transaction is required, Bitstamp generates the tx, signs it with their online key and sends it to BitGo (through some API that they offer). BitGo applies some rate limit or other type of sanity check and if all works out, signs the tx and broadcasts it.
If an attacker obtains Bitstamps online key, they can't do anything unless they have the required info to submit tx-requests to BitGo masquerading as Bitstamp (how hard/easy that is depends on the details of the implementation). BitGo may or may not have some sort of algorithm in place that tries to detect fraudulent activity before signing off on a tx.
It's not a perfect solution, but it solves the most basic attack vector of "steal wallet.dat -> get coins".
I don't think that's that either. There is a page http://bitgoinc.com/guides/add-bitcoin-from-bitstamp-guide/ that explains how to make your wallet multisig with bitgo. |
|
|
|
I know there is no they I am just making figure of speech, you were missing the joking point. But the problem was not a bug in my Electrum it was as if it was stuck.I say stuck also as a figure of speech. You see I was sending the money to someone and the money did not arrive for 12 hours but now it did.This makes me feel a little bit nervous about bitcoin because the fee to make the transfer was paid but it was very delayed.I hope this does not happen again
It has arrived to that someone. The -1 confirmation is a known Electrum bug that only affects the user of the wallet. It's usually fixed by restarting or connecting to a different Electrum server. |
|
|
|
|
x = SHA-256(offchain data)?
So you can refer to arbitrary size data, right?
|
|
|
|
|
Show Posts
