Bitcoin Forum
April 21, 2014, 09:37:43 AM *
News: Due to the OpenSSL heartbleed bug, changing your forum password is recommended.
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [36] 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 ... 727
701  Bitcoin / Bitcoin Discussion / Re: Contrary to Mt.Gox’s Statement, Bitcoin is not at fault - Gavin Andresen 10/2/14 on: February 15, 2014, 05:43:23 PM
Does this mean that many Gox customers believe the price will fall that far on the other exchanges before Gox gets their bitcoin transmission going again? Or does it mean that they believe their dollars are safer on Gox than their bitcoins? Or what? I find it difficult to explain the price difference.

The later.  MtGox doubled paid attackers for who knows how many times and this has could have been going on for a month.  How many Bitcoins does MtGox owe customers?  How many do they have?
702  Other / Alternate cryptocurrencies / Re: Why aren't all coins, sha and scrypt based done like this..... on: February 15, 2014, 05:32:03 PM
Learn what mining actually does, why it is needed, and how the current solution works without centralized control.

Once you do that it is obvious why your idea makes no more sense than designing a toaster which also cures cancer and paints your house.
703  Bitcoin / Development & Technical Discussion / Re: Stuck transactions - possibly new attack? on: February 14, 2014, 06:47:02 PM
it isn't going to magically fix old problems. 
Well, actually—

Zapwallet will fix these cases, in a kind of blunt way.

There is also a patch forthcoming that will release stuck coins (after, by default, something like 144 blocks).


I just saw zapwallet.  Nice solution.  Kill all tx records and then rescan to pickup only the confirmed ones. Smart.
704  Bitcoin / Press / Re: 2014-02-14 BREAKING: Mark Karpeles posts to say MtGox is implementing a solution on: February 14, 2014, 06:20:11 PM
Gox is dead, Mark just doesn't know it yet.
I'm sure he already does know. I can't see how he can pull his business back from this. Why would people go back to gox once they've got their money out of there?

Why do people still buy preorder rigs from BFL?

705  Bitcoin / Development & Technical Discussion / Re: Stuck transactions - possibly new attack? on: February 14, 2014, 06:04:25 PM
OK thank you both. I can now understand the issue better than before.

Pywallet tool did not work well for me - it messed accounts, so I cannot use that. Looks like the only solution is to wait for bitcoin client update from devs. I hope they will modify client to clear&resend these old transactions too.

The pull requests on github are related to removing duplicates from display and preventing the spending of unconfirmed change outputs.  It will prevent FUTURE problems but it isn't going to magically fix old problems. 
706  Bitcoin / Bitcoin Discussion / Nobody spends their coins and that is killing Bitcoin, everyone "knows" that. on: February 14, 2014, 05:50:25 PM
How many times have you heard that (never backed up claim)?

Infographic in MIT technology review.

707  Bitcoin / Development & Technical Discussion / Re: Stuck transactions - possibly new attack? on: February 14, 2014, 05:46:09 PM
It is a known issue of mutated transactions. 
https://bitcointalk.org/index.php?topic=460944.0

The immediate fix is to delete the broken tx (using pywallet).  Make sure to make a backup first.
Then make sure the wallet is synced and all prior transactions have confirmed.
Recreate the broken transaction and it will go through this time.

In the future it would be best to ensure you do not attempt to spend unconfirmed change.  The next release of the client will have an option to ensure that doesn't happen but for now if you make sure all your prior txs are confirmed before making a new tx this can't happen (even if the prior txs are mutated).


708  Bitcoin / Bitcoin Discussion / Re: HELP BTC from Christopher Pau on: February 14, 2014, 04:37:35 PM
Quote
The number of people wanting to steal it is much higher than you can imagine.

including the OP.
709  Bitcoin / Development & Technical Discussion / Re: Stats on malled transactions on: February 14, 2014, 04:16:01 AM
I am curious as to how the client knows in the first place if a transaction has propagated, thus allowing spending uncofirmed changed output? I mean your ISP can MITM you or all the nodes  connected can just drop it, if you put your tinfoil hat on.

It doesn't it will just keep rebroadcasting periodically.  If you are concerned about that scenario, ensure you have a high number of peers and use a vpn tunnel to get "past" your ISP.  No client does this but you could design a client so that it only broadcasts a tx randomly to some of its peers.  If the tx fully propagates the network the other half should inform you about it.  If they don't that would be a warning sign.  The node could also rotate peers to make isolation even more difficult.

For a commercial entity this can be taken a step further by putting a number of geo diverse listening nodes out that which communicate with your main node via an out of band channel.  We use a setup similar to that to troubleshoot customer reports of "transaction not showing up".  The listening nodes can also be used by 0-confirm merchants to look for things like double spend attempts.  If you imagine a 0-confirm merchant who has 8 listening nodes setup around the world each with an average of 2,000 peers connected, there may be some overlap put lets assume that gives the merchant 10,000 or so unique peers.  If any one of those 10,000 unique peers is relayed the double spend, then it would be relayed to one of the listening nodes who would alert the main node.


710  Bitcoin / Press / Re: 2014-02-13 California Bill to Legalize Bitcoin [Source] on: February 14, 2014, 03:38:49 AM
This bill is funny because it already is legal to own and sell bitcoins. I guess the only difference is that now exchanges will have a foothold to help ensure their security, and of course the price is going to skyrocket when this passes  Cool

It actually isn't that uncommon.  Since the laws on the books are written over the course of centuries the particular status of something can sometimes been undefined.  While no law previously in CA explicitly by name declared Bitcoin illegal, the existing laws of "lawful money" brings up at least the question on if Bitcoin violates those.

A company would much rather have a situation where a law explicitly defines something as lawful then a scenario where it "probably is lawful because nobody has had all their assets seized by the state ... yet".  My guess is some business interest in California lobbied to get this passed.  Putting something in explicit black and white is always a good thing (well as long as you are favor of what is written).

711  Bitcoin / Bitcoin Discussion / Re: Silk Road 2.0 hacked through malleability, ~4000 BTC STOLEN on: February 14, 2014, 03:13:01 AM
The good news is nobody had their Bitcoins stolen.   The site now long has the means to repay the bitcoin IOUs it issued (because of the alleged and possibly made "hack", but if you don't have the private key for "your coins" guess what?  You never had any bitcoins.

Not sure how many thousand more of these hacks and "hacks" it will take before that concept sinks in.
712  Bitcoin / Bitcoin Discussion / Re: What you need to know about Transaction mutability ... on: February 14, 2014, 12:15:29 AM
It's one of those things, that makes me feel like the empirical reliability of zero-conf tx allowed too many businesses to build services around them, which can't be supported now.  Technically, you could do an ETF from your bank to pay for your doughnut, or pay with gold flakes, but we don't because the timelines and convenience make it infeasible.  I would argue that Bitcoin should be treated somewhat the same way, and it was only a matter of time before the illusion fell apart.

I am confident that eventually tx ids will be immutable.  Sipa proposal seems to be a good way forward and it can be done gradually (favor "better over "worse", then consider "worse" nonstandard, then eventually "worse" is invalid at the protocol level).  It is a complex issue because there are multiple ways to mutate a tx.  

Long term goal should be immutable tx ids.
Short term goal should be to minimize the disruption caused by tx id mutability.

As a side note alt-coin designers if you actually want to improve on Bitcoin and not make a pump and dump, don't make the signature part of the transaction input have it follow the tx body and sign the entire transaction.

Bitcoin
-----------------------
<some stuff here>
Inputs (including signature inside)
<some extra stuff here>
Output
<some extra stuff here too>

Better
--------------------------
Header
Input(s)
Output(s)
Signature(s)

The tx body is the header, inputs, and outputs.  Hash the body you get the tx id.  Use the same hash and the private key for each input to produce the signatures.  Append the signatures to the tx body and broadcast the whole thing.   You don't even need to provide pubkey in the input as it can be reconstructed from the signature.  I am not really sure if Satoshi was drunk the day he came up with how to sign transactions but it has to be the most overly complex, convoluted system which really provides no benefit and lot of edge cases.  Compared to the elegance of other parts of the design is seems out of place.  I can't think of a cryptographic system where you sign a payload and then put the signature back into the payload.  It is normally payload & signature.

713  Bitcoin / Development & Technical Discussion / Re: Who is mutating transactions? on: February 13, 2014, 10:56:30 PM
Quote
1. Is there a precise and unique canonical form for every legal bitcoin transaction?

No.  The "solution" involves restricting tx such that there is only one form but it is a non-trivial change.  

See here for some more info:
https://bitcointalk.org/index.php?topic=459678.msg5128555#msg5128555

Disclaimer: it is intended for general information as opposed to a developer implementation guide.  For brevity and simplicity some things have been abstracted.

Quote
In the context of cryptography the requirement for canonical forms in data representations has been known for decades.

Two of the three issues relate to the fact that other cryptographic systems are not canonical.  When it is all done Bitcoin will be more restricted than the underlying systems is relies on.

714  Bitcoin / Bitcoin Discussion / Re: What you need to know about Transaction mutability ... on: February 13, 2014, 10:50:12 PM
It sounds to me like the way for wallets to handle this (like Armory), is to popup a warning if a user sends one transaction, and then later attempts to send a second transaction that requires unconfirmed change.  

-- If they are not spending unconfirmed change, nothing needs to be done.  User is not inconvenienced.
-- If they are, pop up a message to the effect of:

Quote
This transaction may have problems reaching its intended recipient(s) if you send it right now.  You might have to re-create and sign a replacement unless you wait for your previous transactions to be confirmed by the network.  

To avoid these issues, please wait until all previous transactions in the ledger have at least one confirmation, and then restart the "Send Bitcoin" procedure as before.

[Send Anyway] [I'll Wait]

I suppose a better alternative would be to hold the key data in RAM until your tx is confirmed, and sign a new transaction with the new txid, if the first one is mutated.  Perhaps even broadcast the first one, but immediately sign and broadcast the replacement if the first one is invalidated.  I prefer the first one though (where the software just waits before doing anything), which is a bit cleaner.

Quote
This transaction may have problems reaching its intended recipient(s) if you send it right now.  You must wait for your previous transactions to become confirmed.  If you click "Send when Ready", Armory will queue the transaction to be sent at that time.  If you close Armory before you see it appear in the transaction ledger, you will have to re-send it next time you start Armory.

[Cancel] [Send when Ready]

I think either one would be fine and far superior to the wallet without warning creating a tx which it "knows" may be broken in the future.  Personally I prefer the first one only because I am "security paranoid".  The second option is more user friendly but the jump to creating and broadcasting tx automatically shouldn't be taken lightly.  Either way advanced users if they have a specific need could always disable this warning via an option in the menus (i.e. [ ] Do not warn on creating transaction with unconfirmed input).

This limitation is most likely to affect users with a small number of confirmed unspent outputs.  A way to improve the user experience would be for the client to be a little proactive about "output management".

A user who has 100 BTC as a single unspent output spends 1 BTC.  Most clients today would make that In: 100BTC, Out: 1 BTC & 99 BTC.  However if the client seeing this tx will reduce the "unspent output pool" below some safety margin would instead make it Out: 1 BTC, 49 BTC, 50 BTC.   Now once this tx confirms the user could potentially two more txs before, even being presented with the warning.

Just an idea.  It is far less critical than what I put in the OP but sometimes solving a problem means making the problem less likely to occur in the first place.
715  Bitcoin / Development & Technical Discussion / Re: Stats on malled transactions on: February 13, 2014, 10:17:14 PM
What about a soft fork: pools don't include malled txs and clients don't relay them. I think this would very quickly solve the problem.

What is a malled tx look like?  There are many ways that a tx can be mutated that makes identifying the "correct" one impossible.  Most nodes and pools already drop the duplicate the issue is the duplicate is getting to the pool before the original.  It wouldn't end up in a block otherwise.

If you have two tx each are equally valid and correct, how do you know which one was mutated after sending?   You can't so you do what you already do.  You keep the one you receive first and you drop the other one.  That means if the mutated tx gets to a miner's memory pool first, it will get included in a block.

I thought it was possible to determine if a tx looks like it was created by the standard client or not. Should this not be possible or there are too many different legitimate tx styles out there then I guess we will have to deal with malled txs.

All that really needs to be done is for transactions to be reformatted to standard format and txids generated from that. Any other txid would be invalid. Surely?

That is a rather large "all" by itself as the input script is rather "loose".  That isn't all you need to do though.  ECDSA signatures are not immutable - Ouch. You also need to restrict signatures to a single "form" (DER) as OpenSSL (which Bitcoin uses) validates a variety of forms - double ouch.

To produce immutable hashes you need to:
a) Limit signatures to DER.  OpenSSL verifies non canonical forms of signatures.  Initially Bitcoin was no more restrictive than OpenSSL.  Since v0.8 Bitcoin, non-DER signatures are non standard and are not relayed by nodes running v0.8+.  This was MtGox problem their "Goxxed v0" custom client was creating non-DER signatures and thus the tx were being dropped by most nodes.

b) Make ECDSA Signatures immutable.  ECDSA signatures are not immutable, they were never designed to be and they never will be.  ECDSA will produce the same signature with both S and -S for a given payload and priv key.  So same tx data, same signature, different hash.  To resolve this "Bitcoin signatures" will need to be more restrictive than ECDSA signatures.  In other words all (future) valid Bitcoin signatures are valid ECDSA signatures, but not all valid ECDSA signatures will be valid Bitcoin signatures.

c) Allow only one form of input script for a given outcome.  The Bitcoin protocol is rather loose when it comes to op-codes in the input script.  It is possible to make some changes to these and still produce the same output (just like 3 + 2 = 3 + 2 +0).  Fixing this aspect will require tighter rules on what is a valid input script.


That is a lot to do, test, and get right.  Think of the "upgrading a plane in flight" analogy.

It can be done is phases to provide a safer path to the hard fork.
First the improved rules would be implemented in new version of clients (i.e. all clients would always use a +S instead of a + or -S) but clients wouldn't treat the "worse" tx any differently.
Next clients would favor "better" form of the transaction (i.e. if a node receives duplicates it will keep the one with the +S).
Next clients would consider the "worse" forms to be non-standard and would refuse to relay them (i.e. -S = non-standard, and tx is dropped by an upgraded node but still valid if in a block).
Finally clients would tx which break the new "better" rules to be invalid (i.e. after block # XXXXXXXXXX a tx with a -S is invalid, a block containing a tx with a -S is invalid).

It isn't going to happen overnight so in the interim mutable transaction ids are just a reality for Bitcoin.
716  Bitcoin / Development & Technical Discussion / Re: Stats on malled transactions on: February 13, 2014, 09:56:50 PM
How do we explain to Bob that he doesn't get his donut without resulting in a fist fight, a discrimination lawsuit, an all day seminar on the technical workings of the blockchain, giving away a free donut, and/or potentially losing Bob as a regular customer?

You probably won't be able to so the only solution is to prevent it from happening to begin with.


So basically stop accepting 0-conf transactions for all purposes, even from trusted customers, until all wallet software has been updated to not spend unconfirmed change?  This seems like an extremely severe setback for bitcoin adoption and its utility in general.

The issue isn't 0-conf transactions.  It is 0-confirm tx which use as their inputs the unconfirmed outputs of another transaction.

All Bitcoin clients ALREADY prevent the client from spending unconfirmed outputs for lots of very good reasons.   However since the wallet can "trusts itself" they wallet makes an exception for unconfirmed CHANGE.   Obviously no user is going to double spend themselves.   So the prior tx will eventually confirm and that means the change will eventually confirm as well.

Except if an attack mutates the original tx, then the original will never confirm, the duplicate will.  That means the change output is now invalid and the subsequent tx will never confirm.

Simple version:
This isn't about 0-conf tx.  This is about transactions using the as their input 0-conf outputs.
717  Bitcoin / Bitcoin Discussion / Re: What you need to know about Transaction mutability ... on: February 13, 2014, 09:42:42 PM
Can someone please elaborate why the unconfirmed-change-spending issue is a real problem? To me, it sounds like it may cause some users to accidentally reverse subsequent zero-confirmation transactions, and that's it.  But the community has been pretty darn vocal about telling people/merchants not to accept zero-conf tx, and there's plenty of ways to intentionally double-spend them without this bug/quirk.  It seems that this particular part of the problem is simply making it (more) painfully obvious why they shouldn't be accepting zero-conf tx.

What am I missing?  

(Of course I know there's bigger problems with transaction mutability than just spending unconf change, but that seems to be the only issue Armory currently has ... if it's a real issue)


It isn't a security issue it is a usability issue.  Traditional double spends require the SENDER to be malicious.  That is a rather narrow security scope.  For a duplicate tx to break a subsequent tx which uses unconfirmed change output only requires that a single third party on an anonymous global decentralized network is malicious.   That is a rather asininely large security scope.  It becomes "Are there any bad/mean people in the world right now?  If no then you are fine nobody can break your tx. If yes then your tx might break randomly".

Example
I create a tx with a hash of "A".  It send 1 BTC somewhere and 4 BTC back to me as change. A malicious user looking to just create chaos mutates it so that it has a hash of "B". For this tx there is no possibility of the payment being broken.  Either A or B will be confirmed and the receiver will get their 1 BTC. 

The problem is created when I create a second payment (tx "C") before "A" or "B" confirms and my wallet uses the change output from "A".  As far as it knows (due to relay rules) tx "B" doesn't even exist so of course it is ok to use "A" we aren't going to double spend ourselves.  This makes tx "C" dependent on tx "A" being confirmed.  If "B" confirms then "A" never will and as a result "C" never will either.

The user is honest, he is following the rules, creating a valid tx (proper fee, no spam, etc), the merchant is being safe and waiting for a confirmation, essentially both parties are doing the "right thing".  However the payment just breaks due to the actions of a third party.  Can it be resolved?  Sure delete Tx "C", create a new Tx "D" which is identical to C except it uses the change output from "B" not "A" and send again.  Now try to explain why you "randomly" need to do that sometimes to a non-technical user.

To a non-technical user it simply looks like the Bitcoin network "breaks" randomly and then you need to pay again, sometimes.  Not exactly confidence building huh.  Sometimes after you pay it will just break and then you need to pay again.  On top of that imagine you believe you paid a merchant and then they ask you to pay them again because Bitcoin broke.  It seems suspicious right?   I just makes the tx flow counter intuitive.  

Until transaction ids are immutable, allowing users to spend unconfirmed change outputs is just going to cause chaos.
718  Bitcoin / Development & Technical Discussion / Re: Stats on malled transactions on: February 13, 2014, 07:37:50 PM
How do we explain to Bob that he doesn't get his donut without resulting in a fist fight, a discrimination lawsuit, an all day seminar on the technical workings of the blockchain, giving away a free donut, and/or potentially losing Bob as a regular customer?

You probably won't be able to so the only solution is to prevent it from happening to begin with.

Quote
Honestly until tx ids are immutable, the use of unconfirmed change outputs is just going to cause mass chaos.

The client waiting until change is confirmed isn't "ideal".  The ideal solution is to make tx ids immutable but that is a long term fix.  In the interim a user (possibly) having to wait for the change to be confirmed is far superior to transactions randomly breaking and non-technical users and merchants trying to figure out why it seems to just fail randomly.  The later is just going to kill adoption. 
719  Bitcoin / Development & Technical Discussion / Re: Stats on malled transactions on: February 13, 2014, 07:34:22 PM
What about a soft fork: pools don't include malled txs and clients don't relay them. I think this would very quickly solve the problem.

What is a malled tx look like?  There are many ways that a tx can be mutated that makes identifying the "correct" one impossible.  Most nodes and pools already drop the duplicate the issue is the duplicate is getting to the pool before the original.  It wouldn't end up in a block otherwise.

If you have two tx each are equally valid and correct, how do you know which one was mutated after sending?   You can't so you do what you already do.  You keep the one you receive first and you drop the other one.  That means if the mutated tx gets to a miner's memory pool first, it will get included in a block.
720  Bitcoin / Bitcoin Discussion / Re: What you need to know about Transaction mutability ... on: February 13, 2014, 06:32:11 PM

And here, for the other issue (duplicates counted in the balance)


I had no doubts that it would get done.  Reading the comments though shows it is a challenge.  Looks like a bug already exists where if you have sufficient confirmed outputs to cover the amount sent but not the amount of the fee, the fee will be paid using unconfirmed output which breaks the "fix".

Hopefully the OP helps "non programmers" to understand the issue and what to expect.
Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 [36] 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 ... 727
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!