a couple more thoughts on proof-of-work and zero-knowledge-proofs for hash functions.

previously i was thinking that proof-of-work might be unfeasible because of the computational power differences between smartphones and large computers (eg botnets). however i wonder if this could not be substantially eliminated, if not fully eliminated by carefully choosing the proof-of-work method. for example, litecoin's hashcash-scrypt has properties which give all machines roughly the same computing power. sure there is variability but its no way near as big as sha256 where a single asic can be many orders of magnitude faster than a cpu.

so maybe careful selection of the pow algorithm could level the playing-field between devices and make this a valid method of cutting down on network dos attacks when using fawkes signatures. hashcash-scrypt does this by introducing memory into the algorithm, but another way might be to introduce milestones into the algorithm. for example, if we wanted to make it so that the proof of work always took 5 seconds to complete then maybe we could make it so that the algorithm had to fetch 5 consecutive pieces of information to complete the proof of work - one each second - as they come available on the network. i'm no cryptographer and i can already see exploits for such a thing, but maybe some algorithm like this exists. or maybe hashcash-scrypt would be sufficient for the purposes of such a cryptocurrency?

as for the zero knowledge proof of the hash function, i finally found the video which is mentioned in the crypto-stackexchange answer previously mentioned, however this seems to be specific for sha1. still, that might be a feasible algorithm and method

my bad. i'm new to the forum and i probably got the etiquette wrong. actually i thought i had posted in the wrong place but probably someone moved my post here haha

i'm also new to cryptography and bitcoin so i was mainly just checking that my understanding of how a guy fawkes signature would be implemented for bitcoin was correct. ecdsa is obviously fine for the next few years at least but if by that time bitcoin's market cap is in the trillions then the incentive to crack ecdsa private keys in under 10 minutes will be very great. is sure seems unlikely from where i stand, but i'd rest easier knowing there were post-quantum alternatives available at any time.

as you say, two possible fixes for the guy fawkes dos attacks are proof of work and zero knowledge signatures. for the pow i'm guessing this would have to be easy enough for a mobile device to implement, yet also difficult enough that a powerful computer could still not do dos attacks. i can see no solution using pow.

zero knowledge may offer some promise though. apparently there is a zero knowledge proof for a hash pre-image which does not involve disclosing the pre-image - http://crypto.stackexchange.com/questions/1767/proving-knowledge-of-a-preimage-of-a-hash-without-disclosing-it  i'm not sure if this is the type of zero-knowledge proof you mention, which relies on the same public key properties as ecdsa though.

finally regarding lamport signatures - this sounds like a good option but for the additional size requirements. if the blockchain were distributed in chunks across many nodes with much redundancy then this would open a lot of doors to implementing signature schemes which take up more space.

i like the simplicity of the guy fawkes signature algorithm but i have some questions. firstly, is this how it would work?

1) i generate some private keys (just large random alphanumeric strings)
2) the corresponding public keys are just a hashes of the private keys and the addresses are just the base58 encoded public keys
3) i create a transaction string (tx1) which has:
- input scripts consisting of private keys which evaluate to the previous transaction's output addresses
- hashes and indexes for each txin to locate the previous txouts
- output elements containing bitcoin values and recipient addresses
4) i hash tx1 to get tx1hash. now create tx2 = tx1. remove all private keys from the input scripts of tx2, place tx1hash somewhere in tx2 - probably as the first input script. maybe place something like op_nop for the remaining input scripts in tx2 (to conserve space).
5) i broadcast tx2 to the network. nobody yet knows whether it is valid.
6) i wait for a safe number of blocks to be confirmed on top of tx2 then broadcast tx1 with the private keys fully visible to all.
7) miners confirm that the hash of tx1 indeed evaluates to the input script of the first input of tx2 and so they include tx1 in the blockchain aswell

if this is how it would work then:

- would step (5) create the possibility for ddos on the network? it seems that nodes should relay the transaction without knowing whether it is valid. there is no way to check whether tx2 is valid or not until tx1 is broadcast at a later date. with bitcoin at the moment this validation is handled by scriptsigs, but this would not be possible with fawkes signatures i think?

- i'm not too familiar with the protocol, so hopefully this isn't a dumb question, but would any code changes be necessary to get this working as bitcoin currently stands? what are the criteria for a miner to include a transaction into the block? this seems like the critical aspect.

yeah i did use install-sx.sh but it had a lot of problems for me. firstly with zeromq then with obelisk. i got it working by downloading these from git then installing manually before running the sx installer again. anyway its working now

is there a way to check the progress when running the history command?

hmm well i got obelisk to install after all, like so:


and now sx has installed too

i'm trying to install sx. i get close i think but it dies as there is a missing file in obelisk:


i'm on debian wheezy. grebit you may have had a similar error?


can you explain what modifications you made to get it working?

i did actually think the process was the same so thanks for the clarification!

it looks like etotheipi made the diagram in that page on the wiki. and it also looks like he has a python bitcoin library - https://bitcointalk.org/index.php?topic=27179.10;wap2 - here - https://github.com/etotheipi/PyBtcEngine

cheers for the lead!

hi all, newbie here

i asked this question previously in the newbie area, but i think this section is more appropriate.

i am trying to understand the bitcoin transaction verification process in depth. as i understand it, it is possible to prove that a transaction has legitimately claimed the output of a previous transaction - ie that a transaction is legitimate. to do this, i would need to perform an operation on the transaction and obtain as a result the previous output address. since the transaction is not mine, i do not own the private key of the output address, so it seems that all the information i need is purely contained within the transaction and the output of the previous transaction (which can be identified via the txid hash and index specified within the later transaction).

i found this code which has a function called "verify_message" - https://github.com/nanotube/supybot-bitcoin-marketmonitor/blob/master/GPG/local/bitcoinsig.py

will this function verify that a transaction is legitimately linked to a previous output address? if so then what are the inputs that need to be used? the address i know, and i'm guessing that the signature is the scriptsig of the latest transaction, but what is the "message" argument? is it something like the hash of the latest transaction?

can someone please help. i'd like to actually implement a test in python using a real transaction from the blockchain.

apparently this is a process which miners do before including new transactions in the block (http://bitcoin.stackexchange.com/a/9461/2116) so if there is any python mining code that somebody could link me to which actually does this natively that would be really helpful.

i've looked all around the web for the code which computes the address from the tx input script and previous txout elements in python. i think i found some in c# (http://stackoverflow.com/questions/19665491/how-do-i-get-an-ecdsa-public-key-from-just-a-bitcoin-signature-sec1-4-1-6-k) but i'm not experienced enough in c#, like i am in python, to actually try it out.

i'm really just keen to fully understand how bitcoin works at these nitty gritty levels. many thanks in advance!

hi

yes i'm guessing the miners would perform this verification before allowing the transaction into a block. a quick google shows that this guy agrees too - http://bitcoin.stackexchange.com/a/9461/2116

i've looked all around the web for the code which computes the address from the tx input script and previous txout elements in python. i think i found some in c# (http://stackoverflow.com/questions/19665491/how-do-i-get-an-ecdsa-public-key-from-just-a-bitcoin-signature-sec1-4-1-6-k) but i'm not experienced enough in c#, like i am in python, to actually try it out.

i'm really just keen to fully understand how bitcoin works at these nitty gritty levels.

hi all, newbie here

i am trying to understand the bitcoin transaction verification process in depth. as i understand it, it is possible to prove that a transaction has legitimately claimed the output of a previous transaction. to do this, i would need to perform an operation on the transaction and obtain the result of the previous output address. since the transaction is not mine, i do not own the private key of the output address, so it seems that all the information i need is purely contained within the transaction and the output of the previous transaction (which can be identified via the txid hash and index specified within the later transaction).

i found this code which has a function called "verify_message" - https://github.com/nanotube/supybot-bitcoin-marketmonitor/blob/master/GPG/local/bitcoinsig.py

will this function verify that a transaction is legitimately linked to a previous output address? if so then what are the inputs that need to be used? the address i know, and i'm guessing that the signature is the scriptsig of the latest transaction, but what is the "message" argument? is it something like the hash of the latest transaction?

can someone please help. i'd like to actually implement a test in python using some data from the blockexplorer.com website.

many thanks in advance!