Bitcoin Forum
July 04, 2022, 12:16:21 PM *
News: Latest Bitcoin Core release: 23.0 [Torrent]
  Home Help Search Login Register More  
  Show Posts
Pages: [1] 2 3 4 »
1  Bitcoin / Development & Technical Discussion / Same private key for 02 and 03 key with same X coord? on: October 12, 2018, 01:12:12 PM
In this reddit thread, somebody is claiming that a private key can be used to derive two different public keys which share the same X coordinate.  i.e. the same private key can derive both an 02 key and an 03 key with the same X coord.

I was under the belief that was not true and that an 02 key is an entirely different key from an 03 key with the same X coordinate, and that a given private key will only ever correspond to either an 02 or an 03 public key.

Is my understanding mistaken?  Can a private key be associated with both a 02 and 03 key (that have the same X value)?

Edit:  Nevermind, it looks like he pointed me to where this was specified.  Thank goodness, I'm not going crazy.
2  Bitcoin / Development & Technical Discussion / How to place tx in own mempool without broadcasting? on: February 15, 2018, 03:43:34 PM
Is there a way I can add a transaction to my own memory pool without broadcasting it to the network?  Imagine I am mining my own transactions and want them kept secret from the network unless they are in a block.  (For example, a time-locked commitment that triggers another event which I want to make sure can only happen AFTER my tx is in a block.)

As far as I can figure, the only way to do this is to mine the transaction myself.  And right now, the only way I can think to do that is to run two nodes where one is a bridge "blocks only" node and is the sole node that the other (mining) node connects to.  Then I can add transactions to the mining node manually.  But then it won't know about any other transactions on the network that I might want to also include in the block I am mining.

Is there a way to accomplish this?  To have my transaction in my block template without broadcasting it?
3  Bitcoin / Development & Technical Discussion / Difference between version 1 and version 2 transactions? on: September 04, 2017, 09:55:43 PM
I've seen segwit transactions as both version 1 and version 2.  When should version 2 be used versus version 1?

Example version 2 tx:  c586389e5e4b3acb9d6c8be1c19ae8ab2795397633176f5a6442a261bbdefc3a

Example version 1 tx:  4ffb6404517ad30869f125b7f2f23a9058313d736a72a996b1381f1fe6f04e07

Both are in blocks on mainnet.
4  Bitcoin / Development & Technical Discussion / Off-chain proof of commitment for Bob to pay Charlie before Alice pays Bob..? on: July 22, 2017, 11:09:31 PM
Now that segwit is locked in, I'm thinking about designing some topology on top of the current lnd software.

I imagine a wallet software where the wallet software company is a hub that has an arbitrarily large amount of funds to dedicate to being locked up in payment channels. So the user downloads a wallet, and whenever the user requests one of his addresses to be displayed for deposit or payment, he's actually shown a payment channel multisig.  He doesn't know or care about this, it's just how the wallet operates.

So the wallet is a spoke that connects to the hub run by the wallet software company, which also maintains very large (in value) payment channels to various other hubs run by exchanges and large merchants and such.

Now, our user wants to make a payment to some other user who is connected some hub somewhere else.  For example, Alice and Bob have a channel, Bob and Charlie have a channel, and Charlie and Dave have a channel.  So when Alice wants to pay Dave, Alice pays Bob who pays Charlie who pays Dave.  Bob and Charlie are hubs in this example, and Alice and Dave are users -- although it really doesn't matter.

My question is -- is there a way for Alice to be sure that Bob will pay Charlie and Charlie will pay Dave?  Alice only has a channel with Bob, so if she pays Bob, Bob can just keep the money.  How can Alice be assured that Bob will pay Charlie (and Charlie will pay Dave), and be sure those transactions are committed to before Alice makes the payment to Bob?

(All of this is presumably off-chain since every player is involved in a current open payment channel with each of his neighbors.)

Are there current solutions to this that I'm just not aware of, or is this a problem I need to figure out how to solve?
5  Bitcoin / Development & Technical Discussion / What is in the pipelines for fixing SPV mining incentives introduced in Segwit? on: July 07, 2017, 04:41:40 PM
I am talking specifically about what Peter Todd talks about here:

I have been away from the space for a bit and would like to catch up on things, and I was hoping somebody could link me to any IRC chats or other things not just in the mailing list for me to read over.

I am not particularly worried about this, because I think there are enough fully validating nodes that invalid blocks will be caught, but still, it is a new economic incentive towards less security, which is of course a potential issue.

I'm sure it's already been dealt with or is being dealt with, and I am hoping somebody can link me to the most recent advances in that regard, so I can get all caught up.

6  Bitcoin / Development & Technical Discussion / List of past soft forks and OP codes? on: April 21, 2017, 03:54:52 PM
As a learning exercise, I am writing a full node from scratch.  I am currently writing the transaction validation logic, and I know that there have been numerous soft forks and changes/updates to assign NOP's to something useful, but I want to make sure that I don't use the current OP code definition for a time period when the definition was still a NOP.  Is there a list of soft forks and OP code changes I can reference, or do I just have to research that myself and estimate based on the blockchain history and whatever other info I can find..?

I am also wondering how P2SH was originally implemented.  Obviously OP_HASH160 doesn't include the code for "oh and check if the stack object is a script, and if it is, verify it".  Did the "OP_HASH160 <hash> OP_EQUAL" output just automatically require checking redeem scripts when it was implemented?

Thanks for the help everybody.
7  Bitcoin / Development & Technical Discussion / [Closed] Help generating segwit txcopy for signature verification on: September 07, 2016, 04:20:31 PM
Using this guide, and the segwit BIP, I feel like I'm reasonably comfortable constructing and verifying transactions in the new segwit format.  Except for the life of me, I cannot figure out how to format the transaction to the format that gets hashed for the signature.  Can somebody help me out and paste the txcopy for the example transaction in the link, so I can see where my error was.  I have no trouble making txcopies for non-segwit transactions, and I'm not sure what I'm doing wrong here.  (And also, maybe somebody can tell me what changes are needed, given that the example uses a P2SH-wrapped segwit output.)

Thanks for the help guys!

EDIT:  I just now found out that BIP 143 exists and explains exactly my problem.
8  Bitcoin / Development & Technical Discussion / Quick stupid question on OP_NOTIF on: August 17, 2016, 10:03:42 AM
Can OP_NOTIF begin an if/else block?  That is, is the following code valid:

<true / false stack item>
    <some script to be executed>

Or does an if/else block need to always begin with an OP_IF?

I assume I am correct that you can begin with OP_NOTIF, and that the above script code is valid, but I wanted to double check.
9  Bitcoin / Development & Technical Discussion / Double check my relative locktime script on: July 19, 2016, 09:02:52 PM
I just want to make sure I am writing the script correctly, and was hoping somebody could point out my errors or let me know it's correct.  I have 2 keys, and I want to require both keys' signatures or wait 2 weeks after inclusion in a block and require 1 signature.

The keys are:


My understanding of the RLT BIP is that 2 weeks would translate to 0x40093a.  So the script I came up with is:


which I believe translates into the redeem script hex of:


for the address 3B6X5FyVdm3qS8J2CNbX2n8M2JyzXhQw8L.

Alternatively, I changed the relative locktime to be 2016 blocks instead of two weeks, for a redeem script of:


and the address 3DDPMrpPeL81WEb4u8cVgRAGZyGanVCVVp.

Are those redeem scripts correct?  And to spend from them, I would need to set the sequence of the input to match what's in the redeem script (but filled to all 4 bytes in the case of the 2016 block example).. is that correct?  And the scriptsig would look like this:

0 sig 1

or alternatively

0 sig1 sig2 0

Do I have everything correct?

Please don't send money for me to test.  (Not that anybody was going to.)  Those keys are NOT the actual keys involved!  I made them up for the purposes of posting here.

Thanks for the help!

Edit: Random thought... Could I remove the OP_DROP and the 1 from the OP_IF and use the OP_TRUE stack item produced by OP_CHECKSEQUENCEVERIFY as the OP_1 for the multisig m-keys-required?
10  Bitcoin / Development & Technical Discussion / Protocol or Paper for Joint Random Secret Sharing (JRSS)...? on: March 09, 2015, 07:44:42 PM
I read the paper on threshold signatures and I thought it would be a fun project -- and immense challenge, since I'm not an expert programmer or cryptographer! -- to try to write a Python module to implement it.

However, one aspect required is deriving shares of a random number (the K value, and also the initial private key) without ever having or revealing the fully constructed value.  They mention this is possible but don't show the protocol for it.

Instead, they reference the paper "A robust threshold elliptic curve digital signature providing a new verifiable secret sharing scheme" by the authors M.H. Ibrahim, I. Ali, I. Ibrahim, and A. El-sawi.  This paper supposedly includes the protocol for JRSS

I cannot find a copy of that paper online, and I was hoping somebody else might be able to find it, or already have it, or simply know the protocol for generating shares of a random value without anybody knowing the random value (aka JRSS).
11  Alternate cryptocurrencies / Altcoin Discussion / SPV for namecoin names..?? on: December 23, 2014, 10:11:07 PM
Is this possible?  I know SPV works by proving the tx through giving you the hashes to reconstruct the Merkle Tree, which means it can prove a tx is in a block, which isn't good enough for namecoin names, since proving a name doesn't prove that a new update hasn't happened.  I'm trying to figure out if there's a "lite client" way to prove a current name, and before I spent days thinking on it, I wanted to make sure the problem hadn't already been solved.  Has somebody figured this out yet?

If they haven't, and if I can (a big if), that would have huge implications for user experience, since sites and lite clients could use BIP0070 or BIP0072 payment requests, and the address books and lite clients could just show the user the name aliases rather than addresses, and users could register their own aliases via the client.  (And aliases could be registered with stealth addresses instead of static addresses for privacy reasons if you wanted.)  In combination, that would mean the user experience of Bitcoin could be *entirely without seeing addresses*, which would be a big deal for the average Joe's normal use.  It would mean that "lite servers" would have to run Electrum, SPV-Namecoin, and Obelisk servers, but I think that's worth it...  I'd run that tuple.

Idea sparked by this thread.
12  Bitcoin / Development & Technical Discussion / How to compute stealth address prefix compatible with Dark Wallet on: December 05, 2014, 01:50:21 AM
I'm trying to understand this explanation and for the life of me, I cannot understand it.  I understand that we're churning through nonces and double-sha256 of the entire output script including the nonce that's being tested.... but I don't understand what to compare it against or what to do with the double-hash once I have it.  Even in this seemingly simple function, I don't get what the bitsize is, or how that output is compared with the nonce.  Can somebody help me and explain in plain English, or Python code, how to calculate the prefix for stealth OP_RETURN data?  I truly feel like I dunce here, but it's just not making sense.
13  Bitcoin / Development & Technical Discussion / Differing S values from test vector on: December 02, 2014, 09:14:55 PM
I'm verifying a signing function I've written against DeathAndTaxes test vectors here.  I'm getting the correct K values, but somehow different S values, and yet all the signatures my function spits out are valid.  (I've tested them against other verification functions that I didn't write.)

The function is:  sign_hash( hash, privkey ), and you can view the code (minus some input format checks and other misc error checking) here.

Here's my doctests:

(As you may have guessed, I like my hexstrs)

    >>> sign_hash(sha256(bytearray("Satoshi Nakamoto",'utf-8')),"0000000000000000000000000000000000000000000000000000000000000001")

    >>> sign_hash(sha256(bytearray("All those moments will be lost in time, like tears in rain. Time to die...",'utf-8')),"0000000000000000000000000000000000000000000000000000000000000001")

    >>> sign_hash(sha256(bytearray("Satoshi Nakamoto",'utf-8')),"FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364140")

    >>> sign_hash(sha256(bytearray("Alan Turing",'utf-8')),"f8b8af8ce3c7cca5e300d33939540c10d45ce001b8f252bfbc57ba0342904181")

    >>> sign_hash(sha256(bytearray("There is a computer disease that anybody who works with computers knows about. It's a very serious disease and it interferes completely with the work. The trouble with computers is that you 'play' with them!",'utf-8')),"e91671c46231f833a6406ccbea0e3e392c76c167bac1cb013f6f1013980455c2")

    >>> sign_hash(sha256(bytearray("Everything should be made as simple as possible, but not simpler.",'utf-8')),"0000000000000000000000000000000000000000000000000000000000000001")

    >>> sign_hash(sha256(bytearray("Equations are more important to me, because politics is for the present, but an equation is something for eternity.",'utf-8')),"fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140")

    >>> sign_hash(sha256(bytearray("Not only is the Universe stranger than we think, it is stranger than we can think.",'utf-8')),"fffffffffffffffffffffffffffffffebaaedce6af48a03bbfd25e8cd0364140")

As you can see from the signature, the R values correspond to the correct deterministic K values, but my S values do not match the test vectors from the link above.  I'm hoping somebody could give a potential reason for that.  (Or rather, I'm hoping somebody will tell me DeathAndTaxes' S value is wrong, since I've actually validated these signatures I've made.)
14  Bitcoin / Development & Technical Discussion / help transforming signed tx to unsigned for OP_CHECKSIG on: November 26, 2014, 10:50:49 PM
I'm attempting to use this picture to transform a tx in order to manually verify the signature.

The tx I'm working on is 60b20eca2285b7ed8b64a1f98277c16fcc205b9e21413d6a72545880d2a3f341, which is the full signed tx of:


After some research, I've been able to break down the entire tx:

01000000  -  byte_reverse(Version: 1, in hex, 4 bytes long)
02  -  Total number of inputs (starts at 1, not 0, so for this tx there are 2 total inputs not three)
17cbf067a9ad71b2f69ea66a1c94d04cee26f856b5b4bdccaeccb59761419668  -  byte_reverse(input_txid)
01000000  -  byte_reverse of vout num for prev_tx (starting at 0, so this is the second output from that tx)
8a  -  total byte length (in hex, 0x8a = 138) of following signature + pubkey, (plus prefix bytes to indicate length)
47  -  total byte length (0x47 = 71) of following signature
30  -  DER encoded signature
44  -  total byte length of following signature info
02  -  first value is an integer, represented in hex (DER format calls that 0x02 apparently)
20  -  byte length of first value (0x20 = 32 in decimal)
735364aea32db724e7f0179f48e4ad5a63a3b04f733e82ca5215097a91aa7123  -  r value (pub X coord of random nonce)
02  -  next number is also an int
20  -  next data is 32 bytes long
15846041c9564ff96fb269cb5e9b2f24dac003299e5d16d34fb9c699d55825c7  -  s value (signature for nonce,data,privkey tuple)
01  -  bitcoin signature type SIGHASH_ALL
       (tells miners how to verify signature.  some sig types sign only certain inputs or outputs, like in coinjoin tx's.  the standard SIGHASH_ALL signs the entire tx so no modifications can be made)
41  -  byte length of following public key (0x41=65)
04617f9e26b7f6f776e30cb4aa24ebef9e183caf6da25684862a32446589be20a53c2b37a7283430033bdfd2f31a96edaea88bf9ebf07498476cb34d16b47887ed  -  pubkey which is the key for the input address and which corresponds to the privkey used to make sig
ffffffff  -  sequence number, assigned just now in this tx, to this last input, for use with nlocktime in this tx
877a5dd62eab9f1fd28739a9ae7c68fcb0f075b2c2ede13cb3acff15d362e271  -  second input byte_reverse(tx_id)
01000000  -  second input byte_reversed vout number.  (again, starting at 0, so this is the second output)
8c  -  length of full signature and pubkey
49  -  length of following signature info
30  -  DER encoded signature
46  -  length of following signature info
02  -  first number is der int
21  -  length of first number data plus 00 prefix
00  -  I'm unclear about what this is or why it's here or if it's necessary
d0af9e17b678ad7823ad331a04d5b50f2dc173715949718ef974314f9ddbf0fa  -  r value
02  -  next number is int
21  -  length of next number and 00 prefix
00  -  again, no clue
98de23b9c6daad57e7c8a8748718c56ec8d20cd2686aa652c4fb85091a39c690  -  s value
41  -  length of following pubkey
04617f9e26b7f6f776e30cb4aa24ebef9e183caf6da25684862a32446589be20a53c2b37a7283430033bdfd2f31a96edaea88bf9ebf07498476cb34d16b47887ed  -  pubkey for prevtx vout, which should be the same one used for the signature
ffffffff  -  sequence number assigned to input
01  -  total number of outputs, in hex, starting at 1 not 0.
709cc90100000000  -  byte_reverse of (number of satoshis in output represented in hex), zfilled to 8 bytes long
19  -  number of bytes for output script
76  -  OP_DUP, duplicated previous stack data (which will be the hash160 when this script is used to spend the money)
a9  -  OP_HASH160, the ripemd160(sha250(pubkey)) for the output key
14  -  length of the hash160 data
ea0fcd06c9c62e590a8975627d0165b514568a5a  -  hash160 of address's public key
88  -  OP_EQUALVERIFY, does OP_EQUAL which puts TRUE on the stack if sig is valid
       then does OP_VERIFY which stops the transaciton and marks it invalid if the top stack item is not TRUE
ac  -  OP_CHECKSIG, makes sure the data that has a valid sig is actually this tx's data.
00000000  -  nlocktime

And using the pic I linked to above, as well as this page and this page, I've attempted to create what the picture link calls "verifyThisStr", replacing the scriptsig with the previous tx scriptpubkey:


However, the double hash for that is 6379ec988e87a690521a2bafe96fd035fc28ad451f3d1b65bf80d25bdb322057, which does not pass signature verification.

I was hoping somebody could point out the error in my unsigned tx "verifyThisStr", so that I can manually verify the tx.

Thanks for the help everybody!!!
15  Bitcoin / Development & Technical Discussion / 0x00 prefix for R and S values in DER signature on: November 26, 2014, 08:43:12 PM
I've noticed that some scriptsigs have a 0x00 prefixing the 32 byte R and S values in the signatures, and some signatures do not have that.  I was hoping somebody knows the reason behind that and can explain to me if and when the prefix is necessary, and why.
16  Bitcoin / Bitcoin Discussion / Petition for web wallets and exchanges to have official Tor hidden services on: November 05, 2014, 12:18:11 PM
There's a new trend of Tor exit nodes MITMing bitcoin sites, and even using self-signed certs, which fool users who don't know better into thinking that they are now "safe" because they have an https connection.

I propose that web wallets and exchanges officially publish hidden services.  Because the service is listed on your site and otherwise verified to be yours, users will know that it's the correct site.  Because it's a hidden service, exit nodes can't fuck over users.

It's a win-win.  The exchanges can still have full AML/KYC/whatever other privacy invading things they need, because they know who the users are when the users log in.  And the users can be confident it's the right site because you the site have widely publicized the correct official hidden service URL.

To their detriment, many Bitcoin users are simply not tech-savvy enough to use Bitcoin safely.  To attempt to mitigate their incompetence, they often hold their funds with websites they trust.  They also attempt to use privacy software that is uncomplicated enough that they can figure out how to make it work.... Like the Tor Browser Bundle or the TAILS live OS.  So when they are on an unsecured wifi or using another computer and they are scared about their bitcoins being hacked, they turn to such things in the hopes and expectations that they will help protect them.

These users may not fully understand the limitations of these tools-- what they can do, what they can NOT do, and where the potential risks and threats may be.

Having common Bitcoin sites have official Tor hidden services protects users.  It's a very obvious step that needs to be done in order to increase user security, at no extra cost to anybody.

It's frankly shameful that more sites haven't done it already.  (And kudos to those that have.)
17  Alternate cryptocurrencies / Altcoin Discussion / Can somebody upload their Windows scrypt python site-package module? on: October 06, 2014, 08:14:35 AM
Trying to install python scrypt wrapper module in Windows 7 x64 and running into all kinds of problems.  Apparently nobody has been able to do it on x64 Windows, but a few have had success on win32 and just copied the site-package module folder over and that worked.  I was hoping some kind soul who has it working on Windows, x86 or x64, could upload their scrypt module folder for me, since the pure Python implementation of Scrypt (module "pyscrypt" if you're interested in testing) is about 300x slower than the C implementation wrapper....
18  Other / Meta / Request for new board: Tech Support for Bitcoin-related software on: August 31, 2014, 03:06:44 AM
I've occasionally had questions about certain bitcoin related tools and software that don't have their own thread, nor a board that is fitting, and I was hoping we could add a tech support sub-forum for misc bitcoin related software and other tools.  Or is there one already and I've just missed it?
19  Bitcoin / Development & Technical Discussion / Help with Casascius Escrow Scheme 'identifier31' on: August 31, 2014, 02:43:02 AM
Edit:  Mods, if this is not the correct place for this, which board should I post similar questions in in the future?  Is "technical support" more appropriate?

I've been fooling around with various bitcoin apps, including Casascius' Bitcoin Address Utility and its Escrow functions, and trying to recreate a lot of what they do in Python, just to help me learn Python.  As a first sample test, I looked at the code for generating the initial escrow components, which was mostly matched at a website which implements it.

However, for the life of me I cannot seem to output the correct prefix referred to as "constant plus identifier31".

I was hoping somebody might be able to see the problem with my code.  I've triple and quadruple checked the functions and variables being used, so I assume the code must be wrong somewhere in here, but it's reasonably simple and for the life of me I can't find the error.  I was hoping somebody else's eyes might spot the problem.  Why doesn't escrowA_actualprefix match escrowA_decodedprefix!?

einva = "140bebc0a12ca9c6"
einvb = "140bebc16ae0563b"

escrowA = "einvaALiXnuThMYVpu7Gz6FJgEj7xvwtcA15ss29cMv7UMa1kgBmvcQtgjSd93AJ7Zadh1k3m3Adxzyw2MtDL3F43Kz1cqBye8rqWAtm6s"
escrowB = "einvbALiXnsHWdyJ8soFrrw4ZNCp4ftM5yGqkU5jQkrZUqdFXLK6ubxK56g7YyRfFoVK9o7cjgyDb51cbynmrpSnkJh9nMGJRJFZXuXFdH"

# base58_decode output is hex string without checksum. e.g. "VZL8ExEXUaC" becomes "aabbccdd"
keyA = int(base58_decode(escrowA)[18:-66],16)
keyB = int(base58_decode(escrowB)[18:-66],16)

keyAB = (keyA * keyB) % N

keyABx, keyABy = ec_multiply(Gx,Gy,keyAB)

keyABx = str(hex(keyABx)).rstrip("L").lstrip("0x")

keyABy = str(hex(keyABy)).rstrip("L").lstrip("0x")

keyABpub = compress_pub_key_str("04" + keyABx + keyABy)

hashGxy = str(hashlib.sha256(hashlib.sha256(binascii.unhexlify(keyABpub))

identifier31 = str(hex(((int(hashGxy[:2],16) & int("3f",16)) << 24)
             + (int(hashGxy[2:4],16) << 16)
             + (int(hashGxy[4:6],16) << 8)
             + int(hashGxy[6:8],16))) \

escrowA_actualprefix = base58_decode(escrowA)[:16]

escrowA_decodedprefix = str(hex(int(einva,16) + int(identifier31,16))) \

print (einva)
print (escrowA_actualprefix)
print (escrowA_decodedprefix)

20  Bitcoin / Development & Technical Discussion / Does Casascius Bitcoin Address Utility confirm cfrm38 codes for compressed keys? on: August 15, 2014, 08:39:05 PM
I've been trying to teach myself Python, and as part of that effort, I made my own implementation of BIP0038 from reading the wiki.  My encrypted private keys decrypt just fine, both EC multiplied and not, and confirmation codes for uncompressed addresses are handled without error, and in my own implementation the compressed keys work just fine as well, but in the Bitcoin Address Utility app, for the life of me I can't get it to confirm a cfrm38 code with the compression flag added to the flag byte!!!  Lot/sequence, no lot/sequence, makes no difference.

Can anybody else confirm this?  Here's a couple example tests, both for compressed keys:

Password: "test"
Use lot & sequence:  no
Intermediate code generated: passphrasersABUMjrzivGVNvYLTdpjCqfRuh7C5HRe5aLB6oYGGSTZWUta6QhWqj7ViYYVh
Encrypted address generated: 6PnUgftup4jXcP3iwbfK7kASooouTdMNioY8X3pg8UX6JNkLATmFPmkpSy
Confirmation code generated:  cfrm38VUVh7yArqgxZFD5FaS48x8pnsh2EZKKPUwcckVG5JHkmPfBmNzmTSTa7jSWFRkGrtZ6jb

Password: "test"
Use lot & sequence:  yes, lot = 234567, sequence = 8
Intermediate code generated: passphraseZKN1wyUNP3hhEn2L6PNS3nShfHEGGbYJYWv6XhBG9Ugxr1TehfDMCmmMQ8AozB
Encrypted address generated: 6PoPdExKREgv8d35ew5P6HVct3EWm9wYQnBoCvzeWoAXSaodYyGZ1ZnJYC
Confirmation code generated:  cfrm38VXUCiGi9gYG2dvZyikcef3tEtGFuCz4hCCRZSUhnYB1GoH6j2oPNotamefsstTYoytxDR

I was originally hesitant to post my code, because it's very sloppy in the sense that I've created a bunch of my own functions. Early on, I switched from Python 2 to 3, and got all of the "your code isn't nearly as clean sanitized as I'd like" exceptions thrown at me.  I also really like working with strings.  So I have functions like "hexX()" which converts input to an string of hex characters, and "strr()" which sanitizes strings so I don't get yelled at by the compiler.  And of course "printt()" and "inputt()" which checks the Python version and does the appropriate function given the version.  Anyway, what I'm getting at is be prepared for very unprofessional code.  I'm just learning Python, and I don't yet know all (any) of the conventions, and I whipped out silly functions to do what I wanted so I could focus on the part of the coding I enjoyed rather than constantly sanitizing everything.  So without further ado, here is the relevant portion of the code doing the private key encryption and the confirmation codes.
Pages: [1] 2 3 4 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!