Bitcoin Forum
June 22, 2024, 12:21:14 PM *
News: Voting for pizza day contest
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 [168] 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 »
3341  Economy / Marketplace / Re: [BOUNTY 20 BTC] Graphics Artist - Client logo and icons needed on: December 01, 2011, 10:39:27 PM
Good question... I haven't even thought about that. 
I suspect that aspect may be more important than actual pixel-size... I'd hope that the pixel-size is big enough to meet the maximum size I'd need (probably for a webpage), the question is more height-to-width ratio.  I would think something like 1000x250 would be the maximum I would need, ever and the 4:1 aspect is probably ideal for a webpage.   I guess anything more square than that might not be easy to include in clients and webpages...

Recommendations are welcome.

3342  Economy / Marketplace / [BOUNTY 20 BTC] Graphics Artist - Client logo and icons needed on: December 01, 2011, 10:23:42 PM
I am working on new client software, to be called BitcoinArmory.  But I am terrible at creating logos or graphics of any kind.  Hoping that someone on the forums here could do it for a few BTC.    First and foremost, I need a logo.  Security is a primary feature of the client, so a logo that has a lock, or treasure chest, or something like that.  It should be a serious logo, not cartoony.  I will pay 2 BTC for any serious attempts at a logo, even if I end up rejecting it.  15 BTC for a good one that I actually like and will use in the software.  If it's really good, I'll throw in an extra 5 BTC bonus.   

I will also need some icons for buttons, etc.  Unfortunately, I'm not entirely clear yet what kinds of icons I will need, but anything that you think should go in a client, I'll pay 1 BTC for a 64x64 icon if it gets included in the client software.  I'll post more specific requests for this as I start developing the interface.

Please PM me if you are interested.

DISCLAIMER:  By submitting images to me based on this post, you are giving up all rights to those images, and they will be considered part of my property/copyright.  None of the images will be used in the actual software unless you have received the 15+ BTC bounty for a logo, or 1 BTC for an icon.
3343  Bitcoin / Development & Technical Discussion / Re: [Bounty] BIP 0011 on: December 01, 2011, 05:22:38 AM
Is the BIP on github the most up-to-date one for 0011?   
What I need to know is if the OP_CHECKMULTISIG tx-type is going to end up as the standard multi-sig tx type?  Is this going to be the only standard way to do multi-sig transactions (besides OP_EVAL)?   I need to start writing code to identify and construct "standard" multi-sig transactions.  It would help to know how many/what variations I can count on seeing.

I am actually making tremendous progress on a usable client, and using BIP 0010 I believe I can get a multi-sig support integrated fairly easily.  I think I have a shot at the bounty!  <crosses fingers>  I just have to neglect my girlfriend a little bit more...

3344  Bitcoin / Development & Technical Discussion / Re: Elliptic curve math question on: November 30, 2011, 02:28:32 PM
I would love to get involved in this discussion, since I am actually a mathematician.  But, I am desperately short on time at the moment.  Until then, take note of this post:

https://bitcointalk.org/index.php?topic=23241.0

The post is in Russian, but the code works, and it was the base for all my ECC operations in PyBtcEngine (in my signature).  Definitely works.  And if you plug that page through a translator, it is clear that Lis is releasing the code into the public domain.

In PyBtcEngine, you can see how I wrapped his code to tie it into Bitcoin itself (starting at line 844, all the createFromPrivateKey, createFromPublicKey, etc).  Mostly just keeping track of private-key exponents, and public-key coords all as integers, then plugging them into his code. 

In the future I plan to write a primer on asymmetric encryption.  But, that is in the future...

-Eto

3345  Bitcoin / Development & Technical Discussion / Re: Poker and the shared pot at the table in a decentralised network on: November 30, 2011, 06:45:38 AM
I think that it doesn't matter, it can be viewed as sign that he is a very good player ... so he makes many hungry players.

I'm trying to find a good rule to easy catch a cheater from all the statistics, and make very difficult and taking time to build a reputation.

The IP limit and proxy list ( also, with everything else ) can be another good way.
If I see a table with many warning ( many players with the same IP and/or behind proxy, from the shared proxy list ) ... than I'll think 10 times before entering on the table.

All this stuff amounts to nothing in terms of a meaningful, credible poker environment.  While there are solutions to subsets of the overall problem, I do not believe it's possible to come up with a all-around solution that won't have holes that will be exploited to hell by determined scammers, and probably end up inconveniencing regular users more than it helps.  Or rather... as solution without third-parties and some kind of centralization...

Seriously, if you even solve this problem 99%, the scammers/cheaters/colluders will figure out how to leverage that 1%, throw a bunch of resources at it, make a significant profit, and most likely cause all sorts of credibility issues for the system as a whole.  And players are skeptical enough, already of online poker...  At least a centralized poker site has the power to police itself, and promote their service with promotions and rake-back deals, etc.  A faceless, decentralized system will need to be airtight in order to survive amidst all the scandals without a PR dept.
3346  Bitcoin / Development & Technical Discussion / Re: Transaction time in the cient on: November 30, 2011, 06:36:02 AM
For transactions that were already in the blockchain, it should be easy enough to just display the timestamp (formatted properly) of the block in which the Tx was included.  It may not be exact (i.e. when the tx was actually broadcast), but it's plenty good enough for display purposes.
3347  Bitcoin / Development & Technical Discussion / Re: Wallet encryption issue on: November 30, 2011, 06:33:32 AM
So, that was a good idea about editing the original post to explain that this problem has been fixed.  I just did that and included a quote from the release notes about corrective actions to protect your wallet.
3348  Bitcoin / Development & Technical Discussion / Re: Wallet encryption issue on: November 30, 2011, 06:08:29 AM
Hi zellfaze,

Not that it's entirely secret, but I have no interest in posting a HOWTO-exploit-users-who-haven't-updated-yet....  I will, for historical and educational reasons, update it in a couple weeks after there has been more time for people to become aware of the updated client and fix their wallet.   Remind me if I haven't done it by then.

Perhaps I'm being too conservative, but I did make this issue public a little earlier than I should have, and realized I should've disclosed it to the devs first instead of posting here.  I don't want to post information on the attack vector earlier than "necessary", whatever that means.

-Eto

3349  Bitcoin / Development & Technical Discussion / Re: Poker and the shared pot at the table in a decentralised network on: November 29, 2011, 10:56:27 PM
Idea:
Can you add a p2p database where every user can give a +1/-1 to others?
This DB will be common between all peers, and everyone will have a private key and public key.
Then if I chose to give a +1 to another one, I will be able to see his +1 and -1. So I'll chose make my choices to enter or not in a table by seeing these votes.

I'm thinking about a community driven poker system ( decentralized/serverless/anonymous )

You wont have a perfect solution to go against the problem, but you will give to the community all the tools to protect itself and blacklisting bad players.

This requires people to make an "identity" system in a anonymized service.  Not only will players always choose to use a new identity for every table they sit down at, but blacklisting a player is pointless when there's trillions of other anonymous identities anyone can use.  Not only that but,
  • (1) When do you assign someone a +1?  When you win a hand against them?  When they lose all their money?  When they make a witty comment?  There are plenty of scammers who will go months looking like a regular player without any reason to suspect them.  Frequently it's only long-term statistical analysis that can identify the cheaters -- which is pretty tough when players are constantly changing their identity and there's no central authority to police it.
  • (2) There is really no way with this system to avoid having packs of colluders (or 100 identities attached to myself) all +1'ing my other identities.  In fact, almost no matter how you design this idea, the scammers will figure out how to be the ONLY ones with 100,000+ ratings...

The only answer I have been able to come up with for an actually viable pokersystem using Bitcoin is just a normal, centralized one, that accepts Bitcoins instead/in-addition to USD,etc.  That may be a great idea, but it's not what we're looking for, here.
3350  Bitcoin / Development & Technical Discussion / Re: Poker and the shared pot at the table in a decentralised network on: November 29, 2011, 09:22:10 PM
I have given a lot of thought to this problem in the past, starting with commutative encryptions for decentralized deck-shuffling (which is possible, btw).  When Bitcoin came out, I thought it was the final piece of the puzzle to creating completely anonymous, decentralized poker for "real" money.  However, the one part I couldn't figure out was how to stop players from colluding with themselves.   The more focus there is on anonymity, the less possible it is to prevent someone from filling 7 seats of a poker table themselves.  Forget other people...if I have 7 windows open at the same poker table, I'm going to run over the other 3 players no problem, and it's going to be more profitable with the near-zero rake of a decentralized service. 

Sure, you can try doing IP filtering, or various kinds of magic, but smart players will get around it, and a poker site with "real money" needs strong credibility and a customer support system.  The more anonymous you make it, the less credible it's going to be.  To make it credible enough, I believe you're going to have to add centralization and remove anonymity -- which destroys the whole spirit of this discussion.

I do find DeathAndTaxes' comment about Rush Poker to be an interesting one.  I used to play a lot of poker, and that was an interesting experiment....arguably I didn't care much for it either, but it does offer a very narrow, niche solution here.  If you can force players to constantly cycle tables, and the player pool is large enough to generally dilute collaboration that exists at any one table, then it will work for those that want to play Rush Poker....

But unfortunately, that's a serious niche.  Part of the edge of a good poker player is being able to sit down at a table (virtual or real) and start figuring out which players are weak and how to exploit them, not tangle with other good players, etc.  Playing a completely generic game with different players every hand is really not going to satisfy any generalized "online poker" market.

I looked at this very seriously about 6 months ago when I stopped playing so much poker and started getting into Bitcoin.  It's a fantastic thought experiment, but I think it's just that.  There's just too many pitfalls to make it actually viable.
3351  Bitcoin / Development & Technical Discussion / Re: On-the-wire byte map & OP_CHECKSIG diagram (knowledge donation!) on: November 22, 2011, 06:36:22 AM
Awesome diagrams! I am really getting interested in scripts.  This cleared up some grey areas for me on the "basic" transactions. Thanks!
If you're interested in scripts, you might find the following links interesting.  The first one is literally every non-std script from the testnet.  I was looking for non-standard transactions for testing my scripting code in PyBtcEngine -- and it turns out there's quite a few on the testnet:

https://github.com/etotheipi/PyBtcEngine/blob/master/testnetNonStdScript.txt
https://github.com/etotheipi/PyBtcEngine/blob/master/scriptEvalStackState.txt

The second link is a few multi-sig transactions, with the stack state at every step of script evaluation (as produced by my code once I finally got it working).  It is a variety of scripts not currently considered "standard" but may become standard in the near future.  Seeing the script-evaluation chain for complicated transactions is quite educational (and critical for debugging!).

Thanks for the hard work.  Usually the work of documenting software can teach you better than almost any other way how it actually works.
Thanks crispy.  It was actually the act of implementing all this stuff in code that really taught me about it, and the documentation was my way of giving back for all the knowledge I gained from for the forums.  I wish I had documentation like this when I first started down this development path 4 months ago.

P.S. - if you found any of this useful, please consider donating.  This stuff took a lot of time!

3352  Bitcoin / Development & Technical Discussion / Re: Multi-signature transaction interface suggestions on: November 21, 2011, 05:24:03 PM
I wrote the spec to have human-readable components to it.
I may have missed it.  The only human-readable components I could perceive would suffice to inform me that it was a proposed transaction, but would offer no idea what the transaction was.  It looked more like a PGP message.  I see no problem with a PGP message being un-human-readable, since that's the purpose of PGP.  I don't think that virtue applies here.
...With arbitrary symbols/words in the format, it can lead to deceptive practices of giving people TxDPs that look like one thing to the eye, but turns out to encode something else...
Can you provide an example of what a deceptive one might look like?  I suppose the comments could be deceptive, but that could be handled by eliminating or forbidding them.

My biggest concern is redundant information:  an attacker could lie about the type of input transactions, and/or the output amounts and addresses (among other things).  I can construct a TxDP that has encoded all the outputs going to me, but the human-readable part suggests they're all going to you.  Or, I manipulate the amounts so the number of output transactions look the same, but I've shifted two of the decimal places in the actual transaction to redistribute the outputs more to myself -- hoping you won't notice, because you based your decision to sign it on the human-readable parts forget to examine it closely in your client before signing.

You can avoid this by removing all serialized data, and requiring the developer to reconstruct the output based on just the human-readable parts, but that leaves open the possibility of some clients re-constructing (and thus signing) slightly different transactions, not to mention it requires them to implement more logic to implement TxDP handling.   My proposed serialization contains the exact scripts/tx that we want signed, and the developer only has to blank out the other input scripts to sign their part of it.

I think the human-readable parts should solely be for developers and advanced users that are interested in "debugging" or casually inspecting them, but no one should be trusting the human-readable parts of it if it comes from another party that is untrusted.   

If you look more closely at my serialization, nearly every part of it is identifiable to someone by eye who takes a minute to figure it out.  Most importantly, its "block" form makes it easy to identify where the TxDP starts and ends, fitting into the least amount of vertical space possible.
3353  Bitcoin / Development & Technical Discussion / Re: Multi-signature transaction interface suggestions on: November 21, 2011, 04:08:14 PM
Wow, you took my statements to an extreme that doesn't match what I have been promoting.  I wrote the spec to have human-readable components to it.  I think it's critically important that the block is not entirely opaque.  But I think ease of implementation by developers and handling blocks to be highest priority, with the ability for a human to visually parse it be next.  No matter what, it is still going to have to be signed by a computer, which means it will be parsed by a piece of software that will be presenting it in a much more human-readable form, anyway.  To me, it's not critical to make it "pretty," and we can respectfully disagree about that. 

I'd actually prefer it look a little more code-like and encourage only advanced users examine it by eye.  Not only will humans-reading it never be the norm, but trying to make that the norm opens up small issues with the encodings.  With arbitrary symbols/words in the format, it can lead to deceptive practices of giving people TxDPs that look like one thing to the eye, but turns out to encode something else.

In reality, none of this is critical.  Your way would work fine as long as we add line-wrapping to fit it into 80 columns.  Because I think it's important that it doesn't force horizontal scrolling if it is posted inline in an email or in a forum post. 

 
3354  Bitcoin / Development & Technical Discussion / Re: Multi-signature transaction interface suggestions on: November 21, 2011, 02:30:13 PM
Why isn't this machine readable?  I find this very easy to parse, and would consider writing code to parse it very elementary.

All of the lines are of the following construct:

Name: Value

Parsing the block is as simple as splitting it on CR/LFs, discarding the comments, looking for a colon on each line, taking everything before the colon as name, taking the rest as value.  And if the line starts with a space, treat it as a continuation of the previous value.

Your suggestion isn't that hard to parse, I agree with you.  But it could be easier -- just think of C++ using ">>" operators to read the data in:  there's going to be a lot of "dead" strings, where the implementer is going to have to count how many fields to skip to get to the next useful field...for every field.  I just think we'd be best to prefer compact and dirt-simple to parse, and let the client make it human-readable.

However, I do like the idea of having comment lines in the TxDP, then the person reading it can just preprocess the block by throwing out all lines beginning with '#' (or whatever comment character is chosen). 

Cutting and pasting text is so much safer than having people open file attachments.

I technically agree with you, but like Mike Hearn said-- that's not going to be the standard use case.  I definitely think the standard should support all ASCII, clipboard-able data (which you have), to support all use cases.  But it should be tailored towards the most common one, which is that average users won't ever be seeing these code blocks.  They will be parsed by client software and presented to the user in the client-specific way.  It may be less safe, but it's going to be by far the most common way for users to interact with it.


It would be awesome if we succeeded at this -- and it's completely within the spirit of Bitcoin to have a system that can be usable without third-parties, even if most users will end up using one.
I dont' think third party can't play a part in bitcoin, when bitcoin can play without third party.

There are third party everywhere: 
SilkRoad is a third party
MtGox is a third party
Bittorrenz is a third party
GLBSE is a third party

I am not saying that third-parties won't be involved, I just want to make sure that it's possible to use this system without third-party services and without needing 3 months experience developing Bitcoin to do it. 
3355  Bitcoin / Development & Technical Discussion / Re: Multi-signature transaction interface suggestions on: November 21, 2011, 02:03:52 PM
Other than preferring Base64 over hex, this is how I envision it:

Code:
----- BEGIN BITCOIN TRANSACTION -----

Funding source 1: 47cf51a4fb5f6dd6ed3169a78601e1ad10bcae27e00c7c0e126f67bb6cf06fb3:1
Funds: 0.79 BTC
...

Funding source 2: bcd1b6acc8d5980970ad993ab57f86da7259d5c4a4816a75065544d87b5eac50:1
Funds: 0.4 BTC
...
# Total funds: 1.19 BTC

Disbursement 1: (A AND B) OR C
...
Funds: 1 BTC
#Comments:
...
----- END BITCOIN TRANSACTION -----

Casascius, I think the number one priority for TxDPs (or whatever we want to call them) should be machine-readability.  That's not to say your suggestion is terribly difficult to parse via code, but it's definitely much more focused on human-readability--which I think should be one of the lower priorities.  I think the standard use case will be users getting this TxDP as an email attachment, and then their client will automatically detect it and display it in human-readable form anyway. 

As such, I believe that we should definitely have a format that has minimal whitespace, extra words and punctuation.  And we should definitely limit it to 80 columns to make sure that identifying and copying it by hand is super easy (I hate getting emails where text is running off the right side of the screen... it's should be a compact representation).  After these two priorities are satistified, then we should start adding stuff for human-readability for those of us that might be inclined to manually inspect it.  But I think, even for advanced users, the code blocks will usually be loaded/copied-into a program that will present the data in a pleasant, human-readable form, and thus, we should focus on ease of client implementation, not human-readability.

I believe including the TxIn amounts and a comments field is a good idea.
3356  Bitcoin / Development & Technical Discussion / Re: Multi-signature transaction interface suggestions on: November 21, 2011, 01:51:55 PM
The goal should be very simple - the user should never see any codes at all. That is the UX a professional software company would be aiming for and Bitcoin should be no different.

This is a higher-level implementation detail.  For someone writing a client or starting a service for helping people to do multi-sig transactions, they should implement it in such a way that the user never sees a TxDP block.  But that doesn't mean that we should ignore the use case where advanced users might actually find it useful to work with raw blocks.  The goal of BIP 0010 is provide a compact way to represent the data that should work well for all use-cases.  It's up to the client/app implementer how much they want to expose to their users..

If someone is trying to make a super-simple client for average users and it requires them to copy these code blocks around, it's not going to be very successful.  But there's no reason that BIP 0010 can't also support the advanced users that might actually prefer to copy the code blocks around, while at the same time defining an interoperable way for all users to accommodate it.  For instance, a "simple" user can send me a .txdp via email attachment without ever seeing any code because their client can create an Outlook/Thunderbird email window with the attachment already there.  I could install software to automatically detect and handle this attachment without exposing any of the code to me... or maybe I'll open the attachment myself and manually inspect and sign it with my CLI tools.  It costs us nothing to support all these use cases, and it really does support all use cases and guarantees interoperability, there's a good chance other developers will use it.

Gavin is on the right track - files or magic URLs that can be handled by the software the user is running are the way to go here. For escrow setup, the user should be presented with a list of escrow providers that the merchant finds acceptable and some useful data about each one (logo, name, link to their website, some promotional text, etc). Then you just select one and the rest is automatic. 

Again, third-parties handling these things is a higher-level implementation detail.  I really want a "standard" that is usable without a third party (even if only by advanced users) , and then the third-party services can step in to accommodate the less-advanced users.  I believe that with some kind of ASCII encoding as defined in BIP 0010 (or Cascasius' suggestion), it's possible to write client software that requires only a few steps to execute a multi-sig transaction without a third party.  It would be awesome if we succeeded at this -- and it's completely within the spirit of Bitcoin to have a system that can be usable without third-parties, even if most users will end up using one.
3357  Bitcoin / Development & Technical Discussion / Re: Multi-signature transaction interface suggestions on: November 20, 2011, 05:35:44 AM
First, would the recommended approach be to add calls to the API?  For example, a call that allows low-level crafting of the transaction or at least the script could be used by multiple UI's so that the presentation is separated from the inner workings.

What you said is essentially what I envisioned.  Any kind of multi-sig transaction can be serialized in this way, and then anyone who follows this wannabe-standard can interoperate with others who do the same.  If someone wants to set up a service for exchanging these blocks, they can, or someone can just make a client that recommends sending them inline in emails.  I just wanted to define a consistent way to circulate information that works in ASCII fields and is usable by even the most lightweight clients (no blockchain needed, to use sign it).

Second, the case of buyer-seller-mediator can be handled with a 2-of-3 signature transaction.  My question is: does the mediator get paid in a separate transaction?  What if the mediator expects a small fee if the transaction goes properly, and a larger one if he has to intervene?

I don't know if I'm at the bleeding edge of this field, but I envision that there would be a third-party service that freely gives out addresses.  The buyer will put up 110%-120% of the cost of the merchandise into the multi-sig tx, and then the buyer will get that 10% back when the transaction is complete (thus giving him incentive to finish the transaction, even after he receives the goods/service).  If something goes wrong, the buyer and/or seller can contact the third party to mediate, and the third party would get the 10%.  It's only when something goes wrong that the mediator gets involved or gets any money.

Arguably, this isn't ideal because it means the buyer is always paying for the mediator.  You could have buyer and seller both put up 5%-10%, but that would require another multi-sig tx in order to seed the transaction, in addition to the one to unlock the funds afterwards.
3358  Bitcoin / Development & Technical Discussion / Re: Wallet Import Format on: November 17, 2011, 06:07:32 AM
Also, I was wondering in your diagram what SCRIPT_PART4 refers to? is that a nonstandard transaction type? or am I really completely lost? all the scripts I've seen so far end with OP_CHECKSIG

My diagram is showing an arbitrarily complex script, which would definitely not be standard.  In fact, we were just having a conversation on IRC about how we're not even sure if OP_CODESEPARATOR scripts can actually be useful in any application (I'm sure there is, we just couldn't think of it)!   For your purposes, you can ignore everything in subscript except for that chunk of standard TxOut script:
Code:
OP_DUP OP_HASH160 <ADDR> OP_EQUALVERIFY OP_CHECKSIG

If that's all I put in the diagram, then steps 2-4 would do nothing since they have no effect on standard scripts.  I figured that was too boring, so that's why I added the other stuff.

I am really busy right now, but if you haven't solved your problem by Friday I'll dig in a bit to see if I can help.  Good luck!

3359  Bitcoin / Development & Technical Discussion / Re: PyBtcEngine: BTC backend in Python (with C++/SWIG) on: November 17, 2011, 01:57:40 AM
Thanks fivebells, I'm so glad that someone else is getting some use out of this library.  It will eventually be used for a client (I'm getting really close to having all the tools I need!), but  if it helps others understand Bitcoin in the meantime, then all the better!  Python is always easier to understand than C++ Smiley

And thanks for reminding me to update the status on this page!   I have all sorts of new stuff in there, though most of it isn't for education -- it's mostly stuff that will be needed to implement a client:  secure binary data handling, encryption, key-derivation functions, wallet formats, and a spiffy new SelectCoins algorithm for tx construction.  I have had this stuff floating around in the dev branch, but forgot to merge it... until just now. 

3360  Bitcoin / Development & Technical Discussion / Re: Wallet Import Format on: November 16, 2011, 10:38:30 PM
I don't know if it helps at all, but here's my python code for verifying signatures (which is the same for signing up until step 10).  Default output for all numbers/values is little-endian.  The "binary_switchEndian" call at the end converts the hash to big-endian just before signing.

You can double-check your process against this, as this method is works reliably on real data from the blockchain.

Code:
def checkSig(self, binSig, binPubKey, txOutScript, txInTx, txInIndex, stack, lastOpCodeSep=None):
      # 1. Pop key and sig from the stack
      binPubKey = stack.pop()
      binSig    = stack.pop()

      # 2. Subscript is from latest OP_CODESEPARATOR until end... if DNE, use whole script
      subscript = txOutScript
      if lastOpCodeSep:
         subscript = subscript[lastOpCodeSep:]
      
      # 3. Signature is deleted from subscript
      #    I'm not sure why this line is necessary - maybe for non-standard scripts?
      lengthInBinary = int_to_binary(len(binSig))
      subscript = subscript.replace( lengthInBinary + binSig, "")

      # 4. Hashtype is popped and stored
      hashtype = binary_to_int(binSig[-1])
      justSig = binSig[:-1]

       # 5. Make a copy of the transaction -- we will be hashing a modified version
      txCopy = PyTx().unserialize( txInTx.serialize() )

      # 6. Remove all OP_CODESEPARATORs
      subscript.replace( int_to_binary(OP_CODESEPARATOR), '')

      # 7. All the TxIn scripts in the copy are blanked (set to empty string)
      for txin in txCopy.inputs:
         txin.binScript = ''

      # 8. Script for the current input in the copy is set to subscript
      txCopy.inputs[txInIndex].binScript = subscript

      # 9. Prepare the signature and public key
      senderAddr = PyBtcAddress().createFromPublicKey(binPubKey)
      binHashCode = int_to_binary(hashtype, widthBytes=4)
      toHash = txCopy.serialize() + binHashCode

      hashToVerify = hash256(toHash)
      hashToVerify = binary_switchEndian(hashToVerify)

      # 10. Apply ECDSA signature verification
      return senderAddr.verifyDERSignature(hashToVerify, justSig)
Pages: « 1 ... 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 [168] 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!