I'd welcome some paper though, that would allow some kind of coin mixing services, so one could launder his coins, without using a third party, but only a widely accepted protocol. But I guess that will have to be done one day together with off chain transactions. Obviously this system is not going to process 100tx/sec - if anyone believes that, he must be insane  |
|
|
|
|
Mining is the voting - everyone knows that.
And as for the homework I should supposedly do: what is so obvious that I don't know?
|
|
|
|
as long as I agree with the keep it simple idea, the others like "sliding blockchain with fixed block sizes, the redistribution of dead coins with an unforgeable lottery, enforced mixing, and miner ostracism" - this is some crazy shit why would any sane person want to e.g. redistribute dead coins? how would he even know if they are actually dead? so yeah, keep it simple. and the bitcoin core - the blockchain parser - should have been a separate app long ago. no wallet, no mining just API to allow it. untouchable - unless like once a year, upon voting. but it wont be as such - not for a long time. instead all the shit satoshi client does, will be mangled together with the chain parsing protocol. |
|
|
|
I just want to know when a few transactions I will make have hit 4 confirmations/ So you basically want to send a tx, from you wallet, and then get some alatm clock tiggered, when it reaches 4 confiscation. How much secured you need to have ii? If not, I belvbe any block explorer would ro. Thanks what's the easiest or fastest way to build my own block explorer.. or can bitcoinj do what is required if it knows the transactions to watch.. or does it require keys of some sort? So what are you going to do, after the alarm clock triggers the 4th confirmation? |
|
|
|
I just want to know when a few transactions I will make have hit 4 confirmations/ So you basically want to send a tx, from you wallet, and then get some alatm clock tiggered, when it reaches 4 confiscation. How much secured you need to have ii? If not, I belvbe any block explorer would ro. |
|
|
|
|
I mean, I dont want to be mean, but if you explain you application maybe we could explain you better.
|
|
|
|
In that case, why do you bother extracting the pubkey? The satoshi client just compares the script to a stored copy of the script that matches a key.
So it's building up: OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG and just matching on that? yes. but in the first block, they were using different scripts |
|
|
|
I just wonder, why do you even need it? Watching a set of transactions and their number of confirmations as they rise - seems pretty crazy for me  |
|
|
|
|
I guess you only need to analyze the data from pk_scripts, from unspent outputs - the input addresses will just be tx ids (who cares).
They (txout scripts) are in general pretty much straight forward,
Recently a hash, with something.
Previously there was the entire public key.
|
|
|
|
Hi everyone, Is there a best practice method of extracting addresses from the sigScript and PkScript? For example, is it safe to assume that data pushes of 20 bytes are addresses and 33 / 65 (if starting with 0x02 / 0x03 for 33 and 0x04 for 65) are public keys? I know that there are transactions that don't have addresses, like this one: https://blockchain.info/tx/a4bfa8ab6435ae5f25dae9d89e4eb67dfa94283ca751f393c1ddc5a837bbc31bBut are there transactions that have more than one? Do i have to run the scripts in order to find out which one is actually used? I also read somewhere that it's possible to get the public key from the signature or is that not the case? Ultimately the is no such thing as the address. Yes you can do these things and they will work in 90+% of cases, but never for all of them. If you sell it to a miner, you can introduce a tx that can create a new address format - whatever you can think of. I guess you should be able to name it then As for extracting the address from the signature - it's somehow possible, though from what I recall the output might be an address that is a false one. So it only makes sense if you have the right one, so you can check. |
|
|
|
FWIW I'd suggest you consider removing script evaluation from your library entirely for now. Keep the rest of the scripting code - you need it to create transactions after all - but make it clear that the only way you know that a transaction is valid is if a miner mines it. This is more in-line with the guarantees SPV clients can provide anyway, and will save you an enormous amount of work that is probably wasted until we have better testing infrastructure for third party clients to use.
Oh, no! Thanks for the advise to make my life easy, but switching the validation off, after I had spent so much effort on validating the txs, is like admitting that I failed on the most important part. I know that there are still things that will make my code fail, eventually somewhere in a future, but that is exactly where I need people like you, who try to break it now, while I seem to be the only user, thus with no big consequences. So please keep up the good job, and let me handle whatever you break |
|
|
|
Thanks! The vectors from the json file helped me a lot today. And the tx_invalid.json also turned out to be useful. Who would have thought that cutting off the signature from a message that gets hashed is such a complex operation (talking about the length prefix here). Though, the Matt's block tester - I did not even try to build it, not too mention figuring out how to use it.. Maybe some day. You're welcome to go through those test cases and summarize the more subtle ones, but frankly I don't see the point: any change, no matter how small, triggers a hard fork. Perfect compliance with those tests is a necessary but far from sufficient requirement. Sure - but at least this many less to go BTW, it would be nice to a have a test tx that triggers this code: // In case concatenating two scripts ends up with two codeseparators,
// or an extra one at the end, this prevents all those possible incompatibilities.
scriptCode.FindAndDelete(CScript(OP_CODESEPARATOR)); |
|
|
|
|
The only question is: where is the money?
Someone obviously took it, and IMO pirateat40 was just a poor sucker, in all this scam.
|
|
|
|
The main reason why the 10 min doesn't change is that the network does not agree on it. If you could convince 50+% of miners to change the protocol, I have no doubts that they'd be able to handle a forked client which does it for them - whoever would had stayed on the satoshi branch would have been doomed. Or on any other branch. If they had enough hashing power nobody would be able to stop it, in such case, but same applies to you trying to change the protocol. But miners don't seek new rules in this protocol - they like the money as it is. At least they are sane So no worries |
|
|
|
hash of the combined transactions - indeed. and good solution, btw. but I bet, there are so many ways to build a story around it, how to interpret the winning hash... and some of the stories might be exploitable, if you don't think them through enough. or I should say: if they don't think.. |
|
|
|
But what will be the winning criteria? If you make it like "whichever hash is lower, then it's quite exploitable, no matter a method". Bit if you make it smart, like e.g. satoshidice, then it can be pretty secured and fully auditable. Its usually enough to just xor two hashes together to get a unique enough value - unless you want to keep the combining algo secret. But people who gamble don't like secrets, not that I'd known any |
|
|
|
|
Just as a general comment, to anyone reading this: please always, whenever you discover such a case, do whatever you can to public any possible sources of hard forks that can be a consequence of an existing implementation, that is not an obvious design decision, but rather a hard to spot, implementation specific whatever (a bug or a feature).
As they say it: knowledge is power.
And knowledge of how you can attack a 1+bn USD worth of a currency is a power worth exploiting.
So if you are honest people, and I think you are, please do not withhold such an important info, but rather advertise it as much as you can - embedding test cases in the block chain is the perfect ultimate solution.
|
|
|
|
Live with it ok, but we need to know what is the good behavior!
Doesn't this look like a crazy hack/bug?
Thus my question. For me it seems like someone has overlooked it at some point; "return 1" was supposed to indicate an error, but it was somehow overlooked and now it implicitly gets cast to (uint256)1 which is a pretty valid hash value, so C++ compiler does not complain and so nobody has noticed.. Don't you have the same problem in Armory? I cannot imagine reproducing the same behavior in python, just by repeating such a mistake. This was noticed a long time ago. It is just now being re-noticed by others I discovered this over a year ago while rewriting everything into python: https://github.com/jgarzik/python-bitcoinlib/https://github.com/jgarzik/python-bitcoinlib/blob/master/bitcoin/scripteval.pyCan you spot the problem? Man, you should have put it on the wiki then, or at least as some comment in the source code. Unless your goal is to make sure that the clients you develop keep the monopoly. Then its probably a good strategy, to not make such an info public. |
|
|
|
I believe Peter created these transactions, and I think that was a good idea. Go Peter! Yes. As much as I don't get along with him in general, thank you @Peter for bringing these txs to the network! I was always worried about different implementation/language related technicals that could be exploited to create a hard fork, so I was designing my node to be less strict in any checking, for such cases. Since it is not a mining node, it should not matter much, but Peter has actually managed to find a case where my implementation was more strict.. And now I have at least one less to go |
|
|
|
Live with it ok, but we need to know what is the good behavior!
Doesn't this look like a crazy hack/bug?
Thus my question. For me it seems like someone has overlooked it at some point; "return 1" was supposed to indicate an error, but it was somehow overlooked and now it implicitly gets cast to (uint256)1 which is a pretty valid hash value, so C++ compiler does not complain and so nobody has noticed.. Don't you have the same problem in Armory? I cannot imagine reproducing the same behavior in python, just by repeating such a mistake. |
|
|
|
|
Show Posts
