However, once you have all the inputs into the transaction, the node can do the verification without needing a database of all the transactions. But what about the volume checks? Each UTXO has a specific BTC value associated with it and each transaction must not spend more then the sum of all its inputs. Even if it is properly signed and even if it got mined into a block with a valid POW - it must still verify the transaction volumes which I do not quite see possible if you don't have the full database. |
|
|
|
With pruning, all transactions in the the UTXO set must be stored. There is no point in all nodes storing all this info. How do you see a node being able to verify a validity of a new block, if it would not have the entire UTXO database? |
|
|
|
What you should have said is "Bitcoin OMG is just backporting patches from Bitcoin 0.9, I'm not actually writing these things." because it seems some people think otherwise!
Sounds like you're jealous that your super-team (aka the bitcoin elite) cannot manage to make it before him. My advise: less patronizing - more work... and maybe one day you will become equally efficient in pulling patches. Doubtfully, but maybe...  |
|
|
|
I found this news somehow relevant to the discussion we had at the previous page, so I will post it here.
“We cannot trust” Intel and Via’s chip-based crypto, FreeBSD developers sayDevelopers of the FreeBSD operating system will no longer allow users to trust processors manufactured by Intel and Via Technologies as the sole source of random numbers needed to generate cryptographic keys that can't easily be cracked by government spies and other adversaries. The change, which will be effective in the upcoming FreeBSD version 10.0, comes three months after secret documents leaked by former National Security Agency (NSA) subcontractor Edward Snowden said the US spy agency was able to decode vast swaths of the Internet's encrypted traffic. Among other ways, The New York Times, Pro Publica, and The Guardian reported in September, the NSA and its British counterpart defeat encryption technologies by working with chipmakers to insert backdoors, or cryptographic weaknesses, in their products. more: http://arstechnica.com/security/2013/12/we-cannot-trust-intel-and-vias-chip-based-crypto-freebsd-developers-say/ |
|
|
|
I feel like OMG is not thought of as an addition or bleading edge thing, but tries to get people away from the official reference client?
You see it upside down. The official reference client tries to get people away from itself. Pretty effectively, in fact. |
|
|
|
Nope, no plans to re-implement. Just want to see how it works, learn how some of the other interesting alt coins work, and see where that leads. Maybe even contribute something useful someday. It will be a slow process as I only have so much free time. But it will be fun.
In such case your topic's title is very misleading |
|
|
|
I guess "what needs to be signed" is the ever lasting bitcoin question I believe this took me the most effort to implement tx sign/verify in my client - there is no decent documentation on this. The best you can do is to reverse engineer the satoshi's implementation. Or or some other implementation that works... w.g. have a look at the function SignatureHash() here: (starts at line 102) https://github.com/piotrnar/gocoin/blob/master/btc/tx.go |
|
|
|
I believe he wants to re-implement the protocol.
As many people have done, I guess it qualifies as learning experience. It also qualifies as a lot of fun and satisfaction - I know what I'm saying |
|
|
|
Approximate point in time this will happen, unless there is a hard fork:
In the 2030s. You will need to replace your HDDs (which live about 5 years) 3-4 times until then.
You obviously missed the fact that lifting the max block size is also on the agenda... Plus imagine how much time it will take to download the blockchain, starting from block #1 in the 2030s. That's of course assuming that we will keep relying on the bitcoin elite to solve our problems. Which we obviously won't, because we are not crazy to delegate such an important tasks to such a lame and corrupt developement team  |
|
|
|
|
That is why I do not defend purging and never have.
I do think though that it is very important to solve the scalability issues, likely through some method of the chain's compression...
Yet before the blockchain grows up to 1TB of data.
55-60 GB of transaction data per year is not a problem for you - well, that's great man, but for me it seems a bit extreme, to say the least.
SPV clients are not a solution, since they don't contribute to the network - they only look at it.
|
|
|
|
|
What is on the agenda here, forcing most of the nodes to switch into SPV mode - this is an indirect attack on the decentralization, which is an extremely important property of this currency and a major factor in its market value.
You can pretend having a good intentions, but your objective is clearly hostile.
|
|
|
|
Yeah, give us more reasons why implementing a chain compression isn't important at all - and thus will take you so much time as I said it would... Plus, we need more patronizing from the bitcoin elite, because they are the ones who know how to write a bitcoin software, while we obviously know nothing about it. SPV clients is the future of bitcoin and the key to the solution of its ever known scalability issues. After every node (except the ones run by Google) switches to SPV mode everything will be just perfect and all the problems will be gone once and for all |
|
|
|
at the other hand, it seems that both the sigScript are inconsistent - so that is probably the reason. 01000000 - version
02 - two inputs
201ac3bea02ec2c3dcc86b123e5e0c53290e58ea5f7bf47154afbaec4f25c007-00000000 - 1st input txid-vout
fd:fe00 - length of sigScript 0xfe
00 - push null
00 - push null
47 - push 0x47 bytes:
3044022022240b411509a86d9d092d0d
fab636e981d36a19a5d3d20017f77017
3a3170ac02204fa7276400f3edea34b4
9edc9b0363e1be1ecdb017e8c74ba3ce
56119715e2df01
48 - push 0x48 bytes:
304502205cd3a7972a7a4253b24b5607
a18d60bdbc8d749de03ae1e68452ce5b
0b559e75022100d929fb1cbf6191be76
f379d4a24f6c5e89a58a4c45c437f3fe
af27597688f33b01
4c - push 0x4c bytes:
695221031d11db38972b712a9fe1fc02
3577c7ae3ddb4a3004187d41c45121ee
cfdbb5b7210207ec36911b6ad2382860
d32989c7b8728e9489d7bbc94a6b5509
ef0029be128821024ea9fac0
6f - push 0x6f bytes:
666a4adc3fc1357b7bec1fd0bdece2b9
d08579226a8ebde53058e453ae
[... where is the rest of the 0x6f bytes???]
ffffffff - sequence
2312503f2491a2a97fcd775f11e108a540a5528b5d4dee7a3c68ae4add01dab3-00000000 - 2nd input txid-vout
fd:0101 - length of sigScript 0x101
00 - push null
00 - push null
49 - push 0x49 bytes:
30460221009f705343b234ce23814fb2
487468bada931a87038194010dcb897e
5fea48926e02210088e5fba6c25660fa
dc3f45f62590dbbf61eda188b42ecfca
a3f429405d31921e01
49 - push 0x49 bytes:
30460221008ecf4cb533f31f160dcf14
75fbfdb08768e8d89d058c61a3416ac6
9f7dda73e1022100829e47757b481413
790846bb8c4f35ced12a52169eb53f3c
ecb39eaa618af09501
4c - push 0x4c bytes:
695221031d11db38972b712a9fe1fc02
3577c7ae3ddb4a3004187d41c45121ee
cfdbb5b7210207ec36911b6ad2382860
d32989c7b8728e9489d7bbc94a6b5509
ef0029be128821024ea9fac06f666a4a
dc3fc1357b7bec1fd0bdece2b9d08579
226a8ebde53058e453ae
[... seems 2 bytes are missing here as well]
ffffffff - sequence
02 - 2 outputs
a086010000000000 - value 1
19:76a914c9b99cddf847d10685a4fabaa0baf505f7c3dfab88ac - out script 1
7011010000000000 - value 2
17:a914b1ce99298d5f07364b57b1e5c9cc00be0b04a95487 - out script 1
00000000 - lock time
|
|
|
|
I think it's because the output script from the second output is kind of weird: a914b1ce99298d5f07364b57b1e5c9cc00be0b04a95487 |
|
|
|
welcome to the party |
|
|
|
My pleasure, man. Since I am just a regular bitcoins user, with no woman whatsoever, these kind of contracts are not my domain of interest Though I am pretty sure that you can do all kind of a weird stuff with the bitcoin scripts. Whether such transaction would be routed/mined or not - that's a different topic, but in theory the protocol is pretty open and you can mine whatever is not against it, as long as you find a miner which does not censor your script just because it is "non-standard" according to rules arbitrary defined by the bitcoin elite. I know people around here have been working on solving all kind of strange contracts. So if you ask patiently enough, eventually someone will show you the right way, not just pretend to know that he thinks there is one...  You definitely ask a smart questions - that's why I don't want to give you a stupid answers. |
|
|
|
Are there transactions that are somehow reserved? By 'reserved' I mean they are not spent, but I would not be able to spent the money at the address somewhere else.
For example if I have a crowdfunding tx with SIGHASH_ALL | SIGHASH_ANYONECANPAY on the input and Alice buys in, but then spends all the money on a shopping spree before I collected all the moneys, her crowdfunding contribution would simply be invalidated, right?
I am not sure if I understood the question but if I did... Bitcoin transaction are not like credit cards - your girlfriend Alice cannot go on a shopping spree with your money if the money in her purse does not exist. Using an analogy, it's more like a pre-paid card. The only form of the money in her bitcoin purse is a set of a so-called "unspent outputs". The way how an unspent output can be spent - that's a different topic. A pretty huge one, in fact.. You can for instance use the multisig transactions - so it would require e.g. 2 of 3 keys to spend the output and this way Alice would not be able to spend the money without a second signature. It's probably not what you were asking for, but feel free to precise the question. |
|
|
|
this is really useful - more people need to understand the mechanics of how Bitcoin works because they can then understand the potential!
I couldn't agree more. Reading some economical experts - e.g. like Bill Fleckenstein, it seems pretty obvious that they have no clue what bitcoin is and why its security is much stronger than any army can give. If the guy was really smart, as he pretends to be, he would have known that it is a solid money that builds an army and not the other way around... Eric King: “Bill, Bitcoin, do you have any thoughts on that?”Fleckenstein: “Yeah, it’s a giant chain-letter. Everyone will lose all of their money that puts money in it. It’s a complete joke. Even a crappy currency has government taxing ability behind it, or some sort of a standing army or something like that. Bitcoin is nothing. It’s dot-com mania 3.0 just moved one step over, right? People are so enamored with communication with their phones and online commerce and all of that. Now they’ve invented what they call a currency to mess around with it, and people are speculating in it the same way they speculated in this other crap. It’s not a currency at all, it’s a complete joke.” http://kingworldnews.com/kingworldnews/KWN_DailyWeb/Entries/2013/12/6_Fleckentstein_-_Global_Meltdown_%26_Why_Bitcoin_Will_Go_To_Zero.html |
|
|
|
But it is not an audit of the silicon - it is just a test of an entropy of the data that it outputs. You can design a hardware in a way that it will output a high entropy data, though according to your pattern. And then, when you know the secret pattern - you can predict what it would generate... Of course its just a theory, but theorizing is what we do here. But in any case hardware random number generators are in general unauditable - you don't know what they do and how they do it. You need to trust the manufacturer and most of them are big corps that should not be trusted, as Google itself has already proven with their SecuredRandom class implementation in Android - I'm old enough to know that you don't usually make such a serious "screw ups" by mistake. If you build your own hardware and then test it for entropy - such a hardware you can trust. But usually its just easier and cheaper to trust yourself with picking a random seed-string |
|
|
|
flip 256 coins, then use those bits (heads/tails) as private keys.
that's also a method. but I think hitting a hundred of random keys on your keyboard - and then getting e.g. sha256 hash of it, is usually much faster. just don't use a wireless keyboard |
|
|
|
|
Show Posts
