Re: [Bitcoin-development] Looking for a good bitcoin script decompiler in Python

2015-04-29 Thread Richard Moore
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...

2014-11-27 Thread Richard Moore
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

2014-08-19 Thread Richard Moore
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...

2014-08-13 Thread Richard Moore
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?

2014-07-18 Thread Richard Moore
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...

2014-07-13 Thread Richard Moore
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

2014-06-09 Thread Richard Moore
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

2014-06-05 Thread Richard Moore
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

2014-06-04 Thread Richard Moore
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