Re: [Bitcoin-development] Looking for a good bitcoin script decompiler in Python
I have a library, pycoind (https://github.com/ricmoo/pycoind https://github.com/ricmoo/pycoind) you might find useful. import pycoind str(pycoind.script.Tokenizer('76a9143f320f852a51643d3ffbaa1f49bfe521dd97764a88ac'.decode('hex'))) 'OP_DUP OP_HASH160 3f320f852a51643d3ffbaa1f49bfe521dd97764a OP_EQUALVERIFY OP_CHECKSIG' On Apr 29, 2015, at 1:12 PM, Braun Brelin bbre...@gmail.com wrote: Hi all, I'm trying to find a good python script that will take the hash of the locking and unlocking tx scripts and output the actual op codes. Any ideas where to look? Thanks, -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ric...@geneticmistakes.com mailto:ric...@geneticmistakes.com www: http://GeneticMistakes.com http://geneticmistakes.com/ -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 65 and OP_CHECKLOCKTIMEVERIFY inquiry...
Heya, I was wondering about BIP 65 regarding the OP_CHECKLOCKTIMEVERIFY, and thought it might make more sense to instead have a OP_CHECKLOCKTIME which would simply push an OP_TRUE or OP_FALSE onto the stack? That way someone could include multiple OP_CHECKLOCKTIME conditions in a single script. It is trivial to always emulate OP_CHECKLOCKTIMEVERIFY by using a OP_CHECKLOCKTIME OP_VERIFY sequence. As a second question, would it possibly make more sense to, rather than relying on the nLockTime in a transaction, allow an opcode that would use similar semantics, but against an item in the stack? Then you could essentially include multiple nLockTimes in a single script and make arbitrarily interesting (complicated?) scripts based on block height and/or block timestamp. The OP_CHECKLOCKTIMEVERIFY can still be easily implemented, by using nLockTimeThatWouldBeInTx OP_CHECKLOCKTIME OP_VERIFY Just something that came to mind while reading about OP_CHECKLOCKTIMEVERIFY. Thanks, RicMoo .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ric...@geneticmistakes.com mailto:ric...@geneticmistakes.com www: http://GeneticMistakes.com http://geneticmistakes.com/ -- Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server from Actuate! Instantly Supercharge Your Business Reports and Dashboards with Interactivity, Sharing, Native Excel Exports, App Integration more Get technology previously reserved for billion-dollar corporations, FREE http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages
Oh, I see. I misread, thinking you wanted the dev team to have a private key and share the public key, similar to alerts. But each peer would have a public/private key pair and use something akin to ECDH for a symmetric key and transport using a block cipher? How would you share the public key? If I were a man-in-the-middle, I could intercept the public key, generate my own and pass that along and then decouple the pipe when the other side shares their public key. Also, you should not ignore your SSH fingerprint, as you exactly open yourself to mitm attacks. On Aug 19, 2014, at 11:11 AM, Raúl Martínez r...@i-rme.es wrote: Only messages between peers are encrypted, only during transit. Before sending a transaction to Node B you use his public key, so Node B has the key El 19/08/2014 17:05, Richard Moore m...@ricmoo.com escribió: If you encrypt all messages with an asymmetric cipher, how would each node make use of the blockchain in an encrypted form? Each node would be able to encrypt the data, but only the Bitcoin Core Dev could decrypt it? On Aug 19, 2014, at 5:49 AM, Raúl Martínez r...@i-rme.es wrote: Hi, I believe that all comunications should be encrypted by default, no matter that is public information (tx info), the only exception I would make would be block packets (to avoid increasing propagation time). I suggest that Bitcoin Core should generate a public/private key pair and share the public one with peers. This could provide privacy and integrity but not autentication. This way you can impersonate a bitcoin node (active mitm) but you cant just be passive and record all transactions send or recieved by an IP address. Today you can just watch for incoming/outgoing transactions to determine what tx are created in the Node, when you find one you can see the Bitcoin address inputs and outputs and track that person's bitcoins. As an example, SSH provides this kind of encryption, althogh Bitcoin Core should ignore fingerprint changes (caused due to reinstalls). Please feel free to disqus why this is not needed or why you like this idea. -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ric...@geneticmistakes.com www: http://GeneticMistakes.com .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ric...@geneticmistakes.com www: http://GeneticMistakes.com -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Another weird transaction question...
Hey all, Sorry to keep bugging you all, as I slowly verify the blockchain one transaction after another with my own implementation, but I have found another transaction that is obviously correct (as it is verified by the legit client) that has me seeking clarification. This multisig output script: https://blockchain.info/tx-index/12809044/0 (txid: 274f8be3b7b9b1a220285f5f71f61e2691dd04df9d69bb02a8b3b85f91fb1857) contains a public key: 00f2b7816db49d55d24df7bdffdbc1e203b424e8cd39f5651ab938e5e4a193569e Are invalid public keys permitted and silently ignored? Or does the 0x00 prefix have some interesting meaning? Thanks again, RicMoo .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ric...@geneticmistakes.com www: http://GeneticMistakes.com -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Signature with negative integer?
Hey all, I'm wondering if anyone can help explain to me tx 70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d... (https://blockchain.info/tx/70f7c15c6f62139cc41afa858894650344eda9975b46656d893ee59df8914a3d) The input signature script is: 304402206b5c3b1c86748dcf328b9f3a65e10085afcf5d1af5b40970d8ce3a9355e06b5b0220cdbdc23e6d3618e47056fccc60c5f73d1a542186705197e5791e97f0e6582a3201 Which decodes to: r= 48560432700441876832361368709121298776045893858160378595187765610521057848155 s= -22732680560694206332190468058638664750027418114195068375538144640549433890254 (http://lapo.it/asn1js/#304402206B5C3B1C86748DCF328B9F3A65E10085AFCF5D1AF5B40970D8CE3A9355E06B5B0220CDBDC23E6D3618E47056FCCC60C5F73D1A542186705197E5791E97F0E6582A32) The ECC library I'm using is failing to verify this, which I think makes sense, since I the point needs to be positive, no? But it is obviously valid, as it has been verified and spent. I have tried simply modulo curve.order to positive-ify it, but that didn't seem to work either. Given a point P (with Py 0) is there some fancy way to bring it into the elliptic curve space, such that Px = 0 and Py = 0? Thanks! RicMoo .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ric...@geneticmistakes.com www: http://GeneticMistakes.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck Code Sight - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Self-dependency transaction question...
Hey all, I'm working on the UTXO database for my Python implementation of bitcoind and have found a situation I did not realize was valid, but since it seems to be, had a quick question. If you look at block #546 the 4th transaction's first input uses its own block's 3rd transaction as an input. https://blockchain.info/block/5a4ded781e667e06ceefafb71410b511fe0d5adc3e5a27ecbec34ae6 My question is, would the other way be valid, that is, could the 3rd transaction of a block, use the 4th transaction from the same block as an input? Or are transactions processed strictly top to bottom? Thanks, RicMoo P.S. If it is valid, another question; what would happen if a transaction was self-referencing? I realize it would be very difficult to find one, but if I could find a transaction X whose input was X and had an output Y, would Y be a new valid utxo, without being a generation transaction input? .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ric...@geneticmistakes.com www: http://GeneticMistakes.com -- Want fast and easy access to all the code in your enterprise? Index and search up to 200,000 lines of code with a free copy of Black Duck#174; Code Sight#153; - the same software that powers the world's largest code search on Ohloh, the Black Duck Open Hub! Try it now. http://p.sf.net/sfu/bds___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP38 Encrypted Address Discussion
Hey all again, I am implementing BIP38 wallets right now, and had another idea I would like to put out there for discussion. Right now the scrypt pbkdf is (16384, 8, 8) for (N, r, p), but I was wondering if it would make sense to include an extra byte in the address which would encode the parameters used? For now, they are fine, as it takes over 3 minutes to to hash once in my pure-Python implementation in CPython (3 seconds in pypy). But with all the latest scrypt mining ASICS hitting the market, and the difficulty rising of the scrypt alt coins, it may become more profitable in the future to try hacking wallets to gobble up their funds. Currently all the hardware is tuned for (1024, 1, 1) and with adaptive-N, it only targets upgrading the N value, so having p =r = 8 certainly means that hardware won’t affect BIP 38… But who knows in the future if they start making Adaptive-N-r-p ASICS. It also provides a way to vastly secure more important master keys… Maybe for a key that is cold storage of millions of dollars that won’t be touched for multiple years, I don’t mind waiting an hour on commodity hardware to decrypt it. I was thinking, for example, if we used 1 byte, c, we could use a formula: N = 2 ** (c + 11) r = 2 ** c p = r Although, even a full byte is overkill… Maybe we can use the top three bits for something else? With 5 bits, the space becomes: c = 0 = (1024, 1, 1) (same as scrypt mining, albeit requires twice the dkLength) c = 3 = (16384, 8, 8) (current specs) c = 31 = (219902322,2147483648, 2147483648) (highest difficulty, requiring (5.6 * 10 ** 12) Gigabytes of memory per hash) Anyways, just thinking out loud… I think even this space is too large… We could also use the top 5 bits for N and lower 3 bits of r, p, if more granularity seems more useful (maybe somebody *wants* their passwords easy to parallelize but still difficult to break?) N = 2 ** (10 + ((c 3) 0x1f)) r = p = 2 ** ((c 0x07) * 3) Would put N = [1024, 2048, ..., 219902322] and r = p = [1, 8, 64, 512, ..., 2097152] The biggest issue would be backwards compatibility. The 6P should obviously stay the same, as it “requires something extra” and the thing required is a passphrase. But maybe we could use one of the reserved bits to indicate that the address is adaptive? The decoded length of the address will also change though, which could pose issues if, for example, bounds checks aren’t being done (bad, but it happens) or in the case of things like python implementations, might assume the length correct an use derived_half2 = decoded[23:] which would now come back with the last byte of derived_half1 and be one byte too long, unchecked, passed into AES, an exception is raised because it is not one 16-byte block. These however seem assumptions that the developer should guard against. This would retain backward compatibility though, as without the adaptive bit set, new and old implementations can decode the address fine (new implementations assuming c = 3); new implementations can detect the adaptive bit and select the correct kdrf parameters. old implementations on adaptive addresses would hopefully fail upon seeing the length is wrong or that the reserved bits are not 0, otherwise the checksum should fail… But if it does by some 1 in 4 billion chance match, the wallet may successfully import a newly created private key and address… Does this seem likely, or are current implementations ensuring the decoded length and bits are set to 0? Otherwise, we *could* if all else fails, use “6A” for adaptive, or “6p”… But I don’t really like polluting the namespace for a minor tweak. Randomly, RicMoo .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ric...@geneticmistakes.com www: http://GeneticMistakes.com -- HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing Easy Data Exploration http://p.sf.net/sfu/hpccsystems ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Future Feature Proposal - getgist
I was considering names like getcheckpoints() to use the terminology that already seemed to be in place, but they were too long :) I have been using getheaders() in my thick client to quickly grab all the headers before downloading the full blocks since I can grab more at a time. Even with getblocks(), there is the case for a getgist() call. Right now you call getblocks(), which can take some time to get the corresponding inv(), at which time you can then start the call to getdata() as well as the next call to getblocks(). With a gist, for example of segment_count 50, you could call getgist(), then with the response, you could request 50 getblocks() each with a block_locator of 1 hash from the gist (and optimally the stop_hash of the next hash in the gist) to 50 different peers, providing 25,000 (50 x 500) block hashes. Currently: getblocks() inv() getdata() block(), block(), block(), … (x 500) Saturates one peer, while leaving the rest un-used. Step 1 and 2 can be repeated and dispatched to different peers, but there is still the latency between the two calls. Gist: getgist() inv() getblocks(), getblocks(), getblocks(), … (x segment_count, 1 per peer) inv(), inv(), inv(), … (x segment_count, 1 per peer) getdata(), getdata(), getdata(), … (x segment_count, 1 per peer) block(), block(), block(), … (x (500 * segment_count), ie. 500 in per peer) Each peer can be saturated. I will try to run some experiments this weekend to get numbers as to whether there is actually any performance improvement using a gist, or whether the getdata(), block() latency ends up dominating the time anyways. RicMoo On Jun 4, 2014, at 11:42 PM, Mike Hearn m...@plan99.net wrote: Why do you want to optimise this? getheaders is used by SPV clients not full nodes. SPV clients like bitcoinj can and do simply ship with gist files in them, then getheaders from the last checkpoint (I wish I hadn't reused terminology like that but this is what bitcoinj calls them). In practice when I look at performance issues with current SPV clients, getheaders speed is not on my radar. .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ric...@geneticmistakes.com www: http://GeneticMistakes.com -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Future Feature Proposal - getgist
Bitcoin development team, I recently started implementing my own Python full-node, and had an idea, so I’m prowling through BIP 001 for this proposal, which says to e-mail you kind folks to make sure the idea is original (enough) and that there aren’t other existing means to accomplish what I was thinking. :) The only way to grab all the headers seems to be to serially get one, then the next and so on, as you need the last hash of a headers() call to the next getheaders(). But we are on a peer-to-peer network, potentially able to getheaders() from many peers simultaneously, if we only knew the hash to look for. What I was thinking is something to the effect of a getgist() command, fully backward compatible (any node not understanding it, can silently ignore it… Otherwise version or services could be used to announce the capability, but that seems like a little overkill). The inputs to getgist() would be similar to getheaders(); version, hash_count, block_locator_hash, stop_hash and an additional field, segment_count. The response would be a normal headers() message, except, not sequential block headers… Rather they would be spaced out, preferably 2000-block-hash-aligned from the first block hash. So, for example, if you have a blockchain with 198,005 blocks, and you passed it the block locator of height 0 (the genesis block), and a segment_count of 25, you would expect (approximately, the actual algorithm needs to be figured out), the block hashes at the following 25 (segment_count) heights: 1, 8000, 16000, 24000, 32000, 4, 48000, 56000, 64000, 72000, 8, 88000, 96000, 104000, 112000, 12, 128000, 136000, 144000, 152000, 16, 168000, 176000, 184000, 192000 Which can now be spread across 25 different nodes, fetching the block headers (albeit, out of order, possibly increasing the complexity of the local block chain database) but vastly increasing the speed the whole blockchain can have all headers synced. I still need to perform some tests to see what type of speed gains there are, but I would suspect it should be segment_count times faster. Existing methods could be to use checkpoint-ish nodes or bootstrap data files, but these begin relying on semi-cetralizenesses. Ideas? Suggestions? Concerns? Prior it-ain’t-gonna-works? Thanks! RicMoo .·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸¸.·´¯`·.¸(((º Richard Moore ~ Founder Genetic Mistakes Software inc. phone: (778) 882-6125 email: ric...@geneticmistakes.com www: http://GeneticMistakes.com -- Learn Graph Databases - Download FREE O'Reilly Book Graph Databases is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development