Yes, it could, transactions rely on other transaction's hashes (TXID), you can mutilate a transaction without invalidating it, and, change it's hash (TXID) before it's in a block (or, even after, but, you'd have to generate a longer chain, so, considered super hard/impossible at that point). It's really not recommended to send any transactions that rely on unconfirmed transactions due to the fact that they'll rely on a transaction that could easily be changed, on top of that, it's basically a "no." to chain transactions to different users using transactions that aren't confirmed, like:-

Address A sends transaction1 to AddressB and customerA
Address B sends transaction2 to AddressC and customerB

Now, if transaction1 is mutilated, then, transaction2 is invalidated. Either batch transactions if you have zero confirmed TXIN (Really? Are you that poor? Get more spread out funds for your system), so, transaction1 sends to lots of customers at the same time (And thus, you don't have to rely on different transactions as often, as, you batch them up), make your system delay transactions until you have TXINs that are confirmed, or, simply have more funds spreadout, next time you're transferring money to your system, instead of putting in 50BTC at once, send it a transaction that gives it 500 0.1 inputs, that way, it can always have an unspent input of > 0 confirmations.

EDIT:- Imagine this:-
Key:-
Black = You
Red = Customer(s)
Green = Invalidated due to upstream issues


You, 1MyAwesomeAddress sends money to customer one (1CustomersAddress) in TXID#1, however, some ass changes your transaction and rebroadcasts it as TXID#2, now, before either one is confirmed, you send TXID#3 to 1SecondCustomersAddress, but, rely on TXID#1. TXID#2 is now confirmed, and, TXID#1 is now orphaned, this means anything downstream from TXID#1 is also orphaned, I.E., TXID#3. Customer one still gets their money, and, you still keep your change in 1MyAwesomeOtherAddress, but, any customers in the chain onward from there are fucked, and, you'll have to spend quite a while to go through your logs to try and work out what you owe who (Not a fun job).

How is this useful at-all? It's not even an entertaining thread, just someone who can't follow a chain.

What's probably happening is you're confusing addresses and wallets.

A wallet is a collection of addresses, purely client-sided (I.E. nobody else knows that address A is also in the same wallet as address B), most wallet software adds all unspent inputs in all the addresses in the wallet to get the grand total, meaning if you sent from one address in the wallet to another address in the wallet, the wallet balance wouldn't change.

Can I confirm this isn't happening?

So far, assuming what RGBKey says is true, you've:-
1. Declined users to use a larger keyspace
2. Emailed confidential details over insecure transport mechanisms

Now, I'm no web-developer (Although, I'm a self-programmed hobbyist programmer), but, even I know that's bullshit.

As for provably fair, I think the majority of people here understand how basic cryptography and mathematics works. Not very professional of you.

I've got to agree with that.

Letters and numbers only? Next you'll be emailing me my password when I forget it and using base64 to 'encrypt' it.

I'll gzip & seed it for a price. I would do it for free, but, it's not free for me. Bandwidth costs money, so does thirty odd gigabytes worth of space.

Now do:-

Thanks, this transaction seems to be a huge chain of non-broadcasted transactions, I have a feeling we'll get to the end and see some transaction having been double spent.

If I'm honest, the other one is more important than this one. This one basically is just telling us that you're transferring 0.02262079 to 1MorjW7nxrnACk29QtomrrQSD3kXnWaddT and 0.10318701 to 19Kz33UpsnQhBKAWQukQFwvxKFZh7XSnqi, but, it's relying on txid 17392d74a8dcf0ddec3183664bc6c564ca69224c4eb0b07cd774dccc6b015b92, without that, we have very little information about what's going on.

I mean if it's something you don't publicly want to share with the world that's bound to your username (Although, at this point, it's pretty much already is once it's confirmed as you've posted the hash).

Like, personally, there's a few transactions I do that I wouldn't want bound to my name, for one reason or another.

Check to see if it's already been spent (On a site like blockchain/blockexplorer), if it has, confirm it's not a mutated version of the same transaction, if it isn't, and, it's spent, contact the guy who sent you the money and complain he double spent your money. If it's not spent, just broadcast the transaction again (sendrawtransaction, https://blockchain.info/pushtx, https://coinb.in/send-raw-transaction.html, http://eligius.st/~wizkid057/newstats/pushtxn.php)

Or, if the transaction isn't private, just post the output of these two commands:-

And I'm sure someone will be able to give you more info.

Okay, here we go. Imagine this is our current blockchain, awarding people 25 bitcoins per block find (Obviously not included crypto/signatures/etc...), hashes are direct SHA256, we're also assuming that we don't need any proof of work, for simplicity:-

Block one:-

Block two:-

Now, block three (two, counting from zero), we're going to spend the funds we got in block one:-


Grand. Now, finally, block four, based on block three, we also make a payment using the funds we mined in block 2, and, the funds we just transferred in block three:-

Grand, now what we have is a four-block long chain where:-
Block:-
#1 Generates 25 bitcoins to address "AddressOne"
#2 Generates 25 bitcoins to address "AddressTwo"
#3 Generates 25 bitcoins to address "AddressThree", and, spends the 25 bitcoins from "AddressOne" (Generated in Block #1)
#4 Generates 25 bitcoins to address "AdddressFour", spends the 25 bitcoins from "AddressTwo" (Generated in Block #2), and, spends the 25 bitcoins in address "OurFirstTransactionAddress" moved there by the first transaction in block #3.

Do we agree? If not, stop reading, as, everything from here on out depends on the above being true.

Now, imagine I'm 51% of the network (or, any part of the network that can generate blocks as such a speed that SOMETIME in the future, my blockchain will be longer than your block chain (You being 'legitimate' miners)), and, I dislike the fact that you spend block one's money in block three, and, I want to move it back. What do I do? I just start off back there and imagine it never happened.
So, let's ignore block three (onwards) ever happened, and, start back at block three.

There we go, valid block, it generates 25 bitcoins and puts them in address "AddressThree", however, nobody will jump to me yet as I'm still not the longest chain. Let's continue, block four:-

There we go, still a valid block, as, all we've done is remove any transaction that happened to now be void due to our previous changes, and, (If it were bitcoin), brute forced a nonce that hashed the block into the correct amount of leading zeros. However, still nobody will jump to us. Why? Although we're an equal length valid chain, peers are configured to stick to the first chain they see unless there's a larger one (Equal length doesn't count). So, finally, if we can beat the current chain in a race, we win, people accept us, so, block five:-

There we go, our chain is now the longest, still valid, chain, while kicking out the previous blocks. Here's a few real-life examples (Granted, not that long):-
https://blockchain.info/orphaned-blocks

Here's a stackexchange post talking about the longest fork:-
https://bitcoin.stackexchange.com/questions/3343/what-is-the-longest-blockchain-fork-that-has-been-orphaned-to-date

All you'd need to do is cause a longer fork, and, bamb, everyone would jump, unless I'm really misunderstanding the entire bitcoin network.


Point is, the blocks would be valid, the only difference is that it's selectively chosen not to include the MTGox transaction, and, any based on them. I'm not saying we take the currently block chain, and, rip the MTGox transaction out, as, that'd obviously be invalid, I'm saying we could generate a new blockchain, starting from where MTGox lost their bitcoins (Assuming they still know the private key to at-least one of the addresses it was originally in), and, build on that chain from there, copying the transactions over (But, still, regenerating the blocks from scratch).

Transactions would still be valid, as, they don't depend on the blocks, the blocks depend on the transaction. If you had enough power you could generate new blocks, with, valid hashes, that, exceed the length of the current chain, if not, explain why not. To me, it seems absolutely standard, if it weren't valid, then, what'd happen if two people generated blocks at the same time based on one previous block? In your situation where peers never jumped, not even if there's a longer chain, then, there'd forever be forks of bitcoins, happening every couple of hours, which, obviously there isn't (Well, there is, but, we jump to the longest one selected by the next miner who mines a valid block).

I'm also not talking about changing the source, no idea where you got that info. I'm just talking about generating a legitimate chain longer than the current chain we all use, where, we never put the transaction where GOX lost their money into any blocks.


Obviously any transactions based on anything invalidated due to the swap (I.E. gox BTC, or, transactions based off miner rewards that are now invalidated) would also be invalidated.

As someone who runs a few services that automate bitcoin related things, I also have this issue, so far five people have contacted me about my service not recognizing their payment, four have used blockchain.info (Last one using Coinbase, and, coinbase was just delaying to combine multiple withdraws together).

Granted, it's normally auto-solved after two or three blocks once Blockchain rebroadcasts their user's transactions that aren't confirmed yet.

Yes, it's client dependent on what coins it chooses to spend. If you have a 50BTC input and a 1BTC input, then tried to spend 5BTC, you'd 100% spend the 50BTC input, as, 1BTC doesn't cover it, it'd then return 45BTc change, and, you'd have a 45BTC input and a 1BTC input, unless, specifically told otherwise, in which case it'd use both (50BTC input & 1BTC input), and, get change of 46BTC, as, a singular 46BTC input, although, no client would do this automatically as it'd reset the priority of the address, lose anonymity, and, be absolutely worthless.

Means a transaction you're relying on doesn't exist in their DB, can you run:-


Please?

Yes. I would, and, yes, I have. I'd obviously prefer not to know, but, some guy offered me huge discount on some BTC I was buying, I asked why, he said they were stolen. My reply was basically "I didn't steal them, and, I'm getting a discount. If I don't buy them, someone else will, so, why can't I get a discount?".

SHA216? But:-


But that's not 216.

K, any transactions based on the transactions of the gox BTC would be invalidated, but, any that weren't would just be just-as-valid.

Imagine we're on block 20, and, gox lost their coins on block 15, and, in block 15-20 five transactions occurred. Gox sent money from their controlled address to an unknown one (#16), the unknown address sent money to another unknown address (#17), some random user sent money to his friend (#18), his friend send money back to the random user (#19) and I donated some money to the EFF (#20).

If we go ahead and imagine all the miners said "Right, fuck everything after block fifteen, let's start again", they'd go back to block fifteen, GOX would have their coins, and, they'd just need to regenerate the blocks from there on, however, since they know about the five transactions, they could just pack it all into the first block, minus the gox ones, so:-

#16 is invalid, as, we don't want to do it (It's where gox loses their money)
#17 is invalid because it relies on #16
#18 is still valid, so, drop that in the first block
#19 is still valid, so, also drop that in the first block
#20 is still valid, so, also drop that final one into the first block.

Grand, now we're 16 blocks deep, and, we're still valid, with MTGox keeping their money. Now all we have to do is generate five more ($chainOne.length - $chainTwo.length + 1) blocks before the miners mining the first chain mine one, and, all nodes would jump to us as we're the longest chain, and, also a valid chain.


...at-least, that's my understanding.


Users can choose, but, unless it faults the checkpoint system that bitcoin has in place (here's a list), then, by default, bitcoin-qt/bitcoind will auto-jump to the longest, valid, chain. In this case, assuming miners can generate a longer, valid (But ignoring gox's transaction), chain before the miners on the current chain can extend it, then, we'd all auto-jump and orphan the other blocks.

EDIT:- Source to back me up:-
https://github.com/bitcoin/bitcoin/blob/f60e49d49c72908356d70d05ae30c6e63be2192d/src/main.cpp#L2001-L2005

I admit, I didn't just read the entire bitcoin source, so, I'm going mainly off comments & function names.

As long as the transaction is valid (I.E. script returns a positive value, transaction is signed, inputs aren't spent, etc...), then, the transaction can be broadcasted at any time.

A node could delay payment, but, each node on the bitcoin network is connected to eight other nodes, randomly selected from nodes they've heard of before, at-least, if not more. It'd be somewhat hard to become all eight nodes to block all communication to the outside world. If you do spend some money, then want to take it back, the only way is to invalidate the transaction you previously signed, most likely by just spending the inputs (And hoping it gets confirmed first, but, in your case it would).

Anyway, why'd you be sending money then wanting your money back? This is a selling point of BTC, no chargebacks.

Generate a longer chain fork starting from when MTGox lost their coins.

It'd require all the miners to agree on the change, though. Or, at-least 51% (Even at 51%, it wouldn't change over for a long time for the other 49%)


I completely agree, I'll drop my entire pool of bitcoins instantly. If pool miners (Honestly, that'll be who's choosing) decide that they have the right to change how the network works, the majority of people will jump off that pool, if it's successful, the majority of people would jump off BTC.