Yes OP, that's how it works, but that's necessary for it to function.

The main problem is with your wallet.

It should warn you, but still let you, use an unconfirmed output as a new input, so that exactly your situation can be done with quickly.  I'm sure not you nor the place you were paying would care about the risk associated with unconfirmed payments for that amount.   Your wallet should also have let you pay multiple addresses in one tx, so that you could have just done it all at once.  And finally, the establishment should also give you the option of just paying everything to one address, and it keeps track of what's what, although it could still provide separate tipping addresses in addition.

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?

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!?

Seems finished to me.  They've got their word list chosen, the method for choosing randomly from it, or from converting to and from hex, they have a checksum, and they have the key derivation function to stretch it.  What more do you want from it?

mom top draft

thank furnace kiss voyage destroy file

trend elevator angry decade drive tribe cream echo vacant degree robust renew

easily sweet work kitten candy negative essence crumble client sell bronze end loop indoor six arm bracket victory cargo team fancy true olive symbol

orphan unhappy bronze shoe whale insane pyramid hotel clutch fantasy hunt predict mom arena craft eager success first rhythm step poet also visual heart siege chalk museum mean dinosaur clutch card raven dove shed approve enrich rich daughter lonely hold lens charge pyramid prevent mansion elite spider lend

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.

Yes, pretty much.  That's the entire point of mining.

Bitcoin-like things work because the earliest transaction is the valid transaction, and later ones are invalid and orphaned.  The trouble was how do you know what's earliest?  Your clock might be wrong.  Outside sources might lie to you.  Information propagation takes time.  And on top of it, when money is involved, you have to assume everybody else is trying to lie and cheat and steal from you.  And that on top of THAT, you want the system to be able to work with nodes coming on and offline, and they need to be able to download updates and KNOW, not trust, that they are accurate.  Sure, a signature could contain a timestamp, but the signer might have just lied, even if he had accurate information.

So how the hell do you solve that?

By not relying on time, but instead relying on WORK.  Churning through sha hashes until you find one within a specific range.  If we assume sha hashes are not predictable, then we know that if you found a specific hash, you HAD to have, on average, churned through some number of hashes.  And given that it takes TIME to calculate a hash, we know that it will on average take some amount of time to do that work.  Now we have a basis for coordinating our clocks.  We may not know the exact time, but we CAN quite easily verify that work has been done, and we know that that work HAD to have taken some amount of time.

So now we can all synchronize our clocks, not by time, but by the longest valid chain of work done, because we know that it could not possibly have been faked.  The work WAS done.  The valid hash is proof of that.  And now, we can have nodes coming on- and off-line, lying to us, and on and on, and all we have to do is get somebody, anybody, to send us the valid chain, and we'll know it's valid, because we can check it very easily, and we've all agreed ahead of time that the longest ("longest" meaning most work) valid chain is the real chain.

Yes, bitcoin mining's whole purpose is to solve the distributed time server problem in a TRUSTLESS manner.  The purpose of doing the work is to PROVE that time has elapsed.  The transaction with more work done on top of it is OLDER.  Thus, we can now verify which transaction came first.

If you can solve the time server another way, you will have done what nobody could do for decades until Satoshi.  Go for it.

FTFY

Do you have any CAD ukash and are you willing to use escrow?

I am looking to buy 300 CAD ukash.  What would that cost me in bitcoin?  Also, I would insist on using escrow via trusted forum member, or via us using a 2-of-2 multisig address that I would fund, and you would put a small amount in (to show your good intentions, and so you have incentive to complete the transaction fairly).

OP, please post or PM me if you are able to do this.

Yeah bitcoin security leaves people confused, because they've never actually had to do security before.  Literally everything else comes with implicit reversibility or insurance.  Forgot your e-mail password?  Answer your security question and send in your ID.  Somebody steal your stuff?  Even if not insured, it was a physical theft and police can usually help, and most criminals are dumb anyway.  Somebody hack your bank account or steal your credit card info?  That's automatically insured and reversible.

Bitcoin is the first technology that they've ever used that doesn't allow for user error.  Uses have never had to actually practice competent security until Bitcoin.  Additionally, a lot of bitcoin thieves, by nature of being early bitcoin adopters, are tech savvy and smart and less likely to make a lot of the errors most criminals make.  Bitcoin is heavily prone to user error, and with many users who have no prior experience with actual good security, and with criminals who are actually smart-- well, it's a situation ripe for exploitation.  Having inter-connected multisig clients, like a desktop app that you need to hit "allow" on your phone before a send goes through, will be one of the big important steps in adoption, because as much as many would like to deny it, bitcoin is too difficult for the average user to use securely and thus adoption is stifled because new users get robbed or just lose their private keys, and that turns them off of bitcoin.

"What do you mean I can't get them back!?"

I downloaded, sandboxed, re-encoded it, and then listened to it.  It's just the end of his famous recent speech:

https://www.youtube.com/watch?v=joITmEr4SjY

but with some light techno music behind it.

Here's where the sound clip begins:

https://www.youtube.com/watch?feature=player_detailpage&v=joITmEr4SjY#t=1631

OP if you liked that clip but haven't watched the whole vid, you'll love the whole vid.

I generated a thousand random keys on an offline computer and made a thousand 2-of-3 multisigs with them, with the keys of my brain wallet hashed a million times, a newly generated key in my bitcoin-qt app on my online computer, and the new random key generated by the computer.  I then bip38'd the private keys for all the random generated keys, and pgp-encrypted the combo of bip38+redeemscript for the key and then have the multisig address as the comment for the pgp data.

Now I just have a file on my online computer with a bunch of PGP messages with multisig keys as the comment, and the only time the private key or the whole redeem script will be known is when I'm getting ready to spend them.  And since each address has less than a bitcoin, I'll find out pretty quickly that my machine is compromised, without losing too much, when I try to spend some of them.  (I always send the multisig back to myself in my QT wallet first, and I do each multisig one at a time.)

(The PGP messages and my encrypted bitcoin-qt wallet are also backed up various places.)

So when I want to spend them, I decrypt and import the one key into my qt-wallet, and then that key plus the key already in my wallet are enough to spend it.

If anybody reads this thread, I'm also trying to buy vanilla mastercards.  Please PM me if you have any to sell.  Trying to get a couple hundred CAD worth.

Stopped reading after the fifth sentence


A 51% attack is a very real problem, but if the person writing the article doesn't understand how the attack works or why it's a problem, then there's really not much point in reading the rest of it...

Looking for 200-300 CAD on a Vanilla Mastercard.

Will pay in bitcoin using btc>cad exchange rate as listed by google at time of trade.

Either you will send first or we will create a 2-of-2 multisig, which I will fund first and then sign a tx to you after I successfully register the card on the vanilla website.

PM or post here if interested.  PGP use is highly encouraged.

(If you want to go the multisig route and know how multisigs work and wish to use that for faux-escrow and you want to expedite the process, use 0252865fa8553e7314deaa058b45349969a53df2a4825a9e8ba314236fe6bfd6c4 and just include the redeem script in your message to me)

You don't need ECC encryption to use an ECC key as a password.  As was pointed out, you can generate an ECC DH exchange-- which is shared secret in the stealth address documentation.  Then once you have the shared secret, you use any kind of symmetric encryption algorithm you want with this 256 bit shared secret as the password.  Or you can XOR the secret itself with a short message, or generate multiple ECC ephemeral keys, and XOR over the chain of shared secrets, and just concatenate the chain of public ephemeral keys, and then digitally sign the whole clump.

Oh shit noice!!!  Now we just need Bitcoin Core to integrate it too, then namecoin, bitcoin, and bitmessage can call be used without addresses, but with a single namecoin id.

Excellent, thank you all!  I actually just now subtracted them and found the difference was N... although I didn't know what to make of that.

Thank you all so much for your help!!!

Ahhhhh, I didn't understand that it was just "normal" modular arithmetic.  Thank you very much for the very helpful reply!

Now I just need to figure out why when I add af4afaeb40810e5f8abdbb177c31a2d310913f91cf556f5350bca10cbfe8b9ec and d39758028e201e8edf6d6eec6910ae4038f9b1db3f2d4e2d109ed833be94a026, I get 82e252edcea12cee6a2b2a03e5425113498af16d0e82bd80615b79417e7d5de3 but casascius' utility gets 82e252edcea12cee6a2b2a03e54251148edc14865f3a1d44a1891ab3ae4718d1.

But I'm at least no longer pulling my hair out trying to figure out what I'm supposed to do!  Thank you!!!