This however is the wallet where we expect to see different implementations. The purpose of the standard here is to enable interoperability across implementations. I think the JSON file I provided is a reusable piece of data for any other implementation's unit test and the algorithm I wrote helps to clarify what is evtl. not obvious in writing. Let me know if more is needed to have "a" reference.
I should probably read a bit more before asking what is the "interoperability across implementations", in this case  |
|
|
|
|
Man, you cannot do such things, if you don't even understand where to start.
Bitcoin is dealing with money and if you loose someone's money, because you had something broken, someone may be very angry.
But since you asked: yes, in one of a possible solutions you would need to have a running bitcoind, though VPS might not be trusted enough.
And then interface with the bitcoind, from your web app, using the RPC protocol - not a console.
|
|
|
|
Peter, can BIP32 be changed to a status of Final on the wiki now? I've made it 'Accepted' by now, as per BIP 01, 'Final' requires a reference implementation... What makes an implementation a reference implementation? I think it means that it needs to be an implementation in the official bitcoin client. Otherwise all the BIP ceremony would not make any sense, since there had been different unofficial deterministic wallet implementations, and pretty 'Active' ones, for like years already. It's actually quite funny because this topic is already over 2 years old, and let's be serious; implementing a deterministic wallet seems more like a 2 month job. Maybe even 2 days... It's actually easier than the current wallet. Unless you work for a bank - then of course, you need a flowchart, even for going to a bathroom It is sort of a bank though, at the current stage. It should be split into independent components, so bugs in one part would not affect the core (meaning: the blockchain protocol) - then it would be faster to improve things. |
|
|
|
Slowly as in not comparable to say the transaction speeds you can accomplish with a credit card.
I've been searching for answer to this. Is there a specific component like network propagation that severely effects processing time?
The main factor is decentralization. You cannot have both; decentralization and quick judgement on who is trying to double spend. If you choose to go for the quick judgement way, then you will end up in hell. Where you come from, so no worries here. |
|
|
|
Does there exist a set of blocks that can be used for unit testing? I'm thinking something like a few thousand blocks that is representative of everything a node would need to implement.
testnet3 chain is very good for this. it does not have everything, but I believe it has enough to keep you busy for awhile... |
|
|
|
Wow, it's great. 187us versus OpenSSL's 1008us, on my test laptop. Sipa for president! |
|
|
|
|
I though a block must be like 2 minutes max in a future, to get accepted, but not 3 hours
|
|
|
|
Your solution is indeed simple. But it doesn't do the same job that checkpoints do. Checkpoints are not about forks in the present or future, they are about helping clients avoid dead end forks in the past, while they are doing their initial sync. Checkpoints help new nodes catch up to the network with minimal annoyance for the node operator, nothing more*. So you are saying that checkpoints don't actually prevent my node from downloading, storing and routing an alternative block that would refer to the genesis? Or are you saying that they do prevent it, but the important thing here is that I should care more about those who are just downloading the chain and dont know yet which branch to choose? |
|
|
|
(Note that there is a subtle and unimportant bug in the code that throws the calculation off by a small fraction of a percent. The bug is symmetric, so no one can use it to tweak difficulty in the long run, so it isn't a security issue.)
What bug? |
|
|
|
I'm glad you managed to dig up and read my proposal for exponential difficulty reorgs, and that you find it superior. Not surprising, considering that yours is a degenerate case of mine where the exponent is infinite.
But it really isn't a checkpoint system. The checkpoint system is all about the past, while both your proposal and mine are useless in that domain.
I wish I did, but as you figured, I didn't. I'm a man of simple solutions. Checkpoints that are there now, in the bitcoin client, are stupid. My idea - may be simple, but at least it would do what it has to do and close the problem once and for all. And it's surely much simpler. Your idea - I believe it's impressive, but why to complicate things that are simple and do the job? |
|
|
|
I was just wondering what component of the Bitcoin network controls the Difficulty? Is it included in the code of each of the Bitcoin clients like Bitcoin-QT, Bitcoind, etc?
Its the blockchain protocol that controls difficulty. All the clients must comply to it. |
|
|
|
P.S. No one particularly likes the checkpoints, the devs least of all. There has been much discussion about removing them, or switching to a soft system (config file, etc). So far, no one has come up with a really good solution.
I can come out with a really good solution, if you want  Just make a rule that the client would not accept any forks deeper than N blocks back from its currently known top. Set N to whatever constant you want, but I think more than a week time would be exaggerating. No, that sucks. Sorry. Yeah, I'm sure your checkpoints idea is much better. I'm actually even ashamed mentioning something such stupid |
|
|
|
Do you understand that checkpoints completely violate the entire purpose of Bitcoin? I understand that they violate some purpose of bitcoin. But I am also a pragmatic person and so I prefer to have a system that violates some very unlikely to happen purposes, as long as it is a way to keep my resources away from spammers. What they do is introduce a form of approval(consensus) about the state of a chain. This form of authority could certainly be abused, and it runs counter to practically every design principle of Bitcoin. But your concerns are 100% theoretical and it isn't really possible to start a fork like 2000 blocks back and get with it to the top. And even if it was possible, would you really want it? Because I would not. at the most fundamental level, the client code should not have ANYTHING to say about the block chain. Whether this is required in order to operate is irrelevant. The reason people use Bitcoin is *because* it's peer-to-peer.
Again: the node, and the network, must protect itself from DoS attacks. What are you even trying to achieve forbidding people doing this? If you one day manage to create a branch that would beat their chosen checkpoint - then I will agree with you. But so far, I don't get your problem, though I appreciate your innocent ideas. |
|
|
|
|
I think you don't understand.
Checkpoints are not there to fight proof of work - they are there to protect your node from attacks.
Do you understand that if there were no checkpoints, anyone with a graphic card could just keep mining blocks that link to the genesis one, and this way fill up your hard disk? Also stuffing the net with useless data.
|
|
|
|
P.S. No one particularly likes the checkpoints, the devs least of all. There has been much discussion about removing them, or switching to a soft system (config file, etc). So far, no one has come up with a really good solution.
I can come out with a really good solution, if you want Just make a rule that the client would not accept any forks deeper than N blocks back from its currently known top. Set N to whatever constant you want, but I think more than a week time would be exaggerating. |
|
|
|
P.S. Does anyone have much interest in a c# implementation? I started this mostly to educate myself, but I'm making more progress than I was expecting.
If you started, just finish it - turn it into a full node. It will give you a great satisfaction and the community need other clients. Bittorrent would have never became a success if people would have stuck to the original python download dialogs. Personally I believe that the future of bitcoin is not in the official client - the official core is just too important and no sane developer will want to risk breaking it, which will surely paralyze its further development. Since it will be harder and harder to add new features there, sooner or later alternative clients will just beat it on the functionality and a speed of development. As for your further possible concerns, since I've been there I can tell you that the biggest challenge, besides the ECDSA performance, is a proper database for UTXO. Forget about anything SQL based. Unless you want to make a node for testnet only |
|
|
|
It didn't used to be slow at first but now whenever I open bitcoin-qt it takes a long time for the wallet to open.
If you think its slow now, wait until they raise the max block size limit... And start collecting money to buy some more memory, waiting for it. |
|
|
|
yeah, I agree with you that it goes against an important principle, but as gmaxwell said, it does have some actual purpose, protecting your storage from being flooded by forks that would suddenly start to appear at low block numbers. though, it does not make any sense to have multiple checkpoints (instead of i.e. a one that moves by itself), but well... who are we to argue with a solution chosen by the best bitcoin developers that satoshi left behind? |
|
|
|
who makes the checkpoints?
The bitcoin core devs so ultimately, the state of the block chain depends entirely on them. not really. they only put checkpoint for blocks that are buried at least few hundreds deep already - unlikely to be reverted by honest means. but if you disagree with any checkpoint they add, just don't upgrade your node and you will be fine. |
|
|
|
|
IMO, the guy is doing a great job creating long forks, that allow people to test stuff which they cannot test on a real net.
He does include transactions. And besides its only 1GH/s, so I doubt it is an ASIC - rather some graphic cards from his scrapyard.
|
|
|
|
|
Show Posts
