Bitcoin Forum
February 27, 2015, 09:11:07 PM *
News: Latest stable version of Bitcoin Core: 0.10.0 [Torrent] (New!)
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: « 1 ... 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 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 [107] 108 109 110 111 112 113 114 115 116 117 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 ... 796 »
2121  Other / Beginners & Help / Re: Sent bitcoins not showing in blockchain, already been 8hour.. how come? Help pls on: February 13, 2014, 03:23:48 AM
It doesn't exist on the network.  Your "great trusted platform admin" is incompetent or crooked.   You haven't been paid.
2122  Economy / Trading Discussion / Re: Is there a way/method to buy bitcoins using paypal? on: February 13, 2014, 12:30:56 AM
if you're into bitcoin for the long term, we could sign a contract where you'd get the bitcoins after 180 days from payment (longest paypal chargeback period I know of) when it's quite safe to release bitcoins for paypal payment. if the payment is charged back in the mean time, contract is void. it's that easy. i would even move the coins for you so they have a footprint in the blockchain just would not let you have the private key sooner. sorry but paypal is really bad money to buy bitcoins with.

if you search the forum you might find sellers releasing coins immediately but they are rare and usually won't deal with users without a background check (ebay id with feedback, verified paypal account, web of trust rating, successful trades with forum members in the past).

if paypal is your only option, then the 14% fee via virwox might be the way to go (and be happy to buy bitcoin with pp at all)

You would still get scammed.

Buy $x worth of Bitcoins using PayPal.  If the exchange rate goes up don't dispute.  If the exchange rate goes down file a dispute.  Guaranteed profit for the scammer, either he gets $x back or he gets >$x worth of BTC.
2123  Bitcoin / Bitcoin Discussion / Re: Let's stop all transactions, right now! on: February 12, 2014, 11:39:12 PM
I understand it can't be with BTC where there isn't a regulator, but we shall not fear, nor be surprised if at times, there are things we do not understand, or that things are causing reactions we hadn't expected, so much that the safest thing to do may be to stop everyhting.

I called Satoshi.  He turned the master bitcoin key to off so blockchain should be stopping shortly.  Thanks for the heads up that was a close one.


2124  Bitcoin / Bitcoin Discussion / Re: Enjoy? on: February 12, 2014, 11:31:02 PM
According to the last 10 news posts at blockchain.info, there is a lot more to it than a penny in someones mailbox.. it seems to be a little more complicated than that

You are saying that you believe that send you a satoshi is the same thing as the ongoing DDOS attack?  There is a real attack going on which has absolutely nothing with this thread.
2125  Bitcoin / Bitcoin Discussion / Re: Enjoy? on: February 12, 2014, 11:18:44 PM
So it turns out my concerns were semi-legit?   Cheesy

No, however you deserve credit for riling up the clueless.

Bitcoin addresses are public knowledge much like postal addresses.  Say one day I felt stupid and decided I wanted to mail 1 US penny to 10,000 random postal addresses.

Do you know what could happen? You might open your mailbox one day and .... HOLY CRAP there would be a penny in there.  How could this happen? You didn't ask for a penny and it was mailed from some anonymous mailbox?  What the hell is going on?  Has the security of the postal mail system been broken? Is someone tracking you?  What if this is part of some 51% postal attack?  I heard they are "dusting" your finances with this penny so when you deposit it then they can hack your bank account from the inside out.  OH NOES! CALL HOMELAND SECURITY!  We need to stop this.  Someone should put penny detectors on all mail drops to ensure hackers aren't able to destroy the world economy by mailing pennies.   We need to act now.   The entire postal system as we know it could collapse within days if people can just mail things to other people and stuff.

This is the digital equivalent of that, and the reaction is just as silly.
2126  Bitcoin / Mining speculation / Re: Could the Bitcoin difficulty go down? on: February 12, 2014, 10:59:48 PM
Yes.  It has on more than one adjustment in the past.

Is it likely that it will go down anytime soon?  No.
2127  Bitcoin / Bitcoin Discussion / Re: Overstock getting close $1million sales in bitcoin on: February 12, 2014, 09:45:21 PM
Are they? I'm not sure if the company is, but the CEO himself holds a lot.

I hadn't seen any news about this. If this is the case though, I'd be very intrigued to see how this is reported in their financials. And I wonder what BTC sales and holding BTC would fall under in their EBITDA.

Um Huh it is in the article that this thread is about.

Quote
Overstock’s recent decision to keep some bitcoin on its balance sheets could also find the company playing the role of newsmaker once again. Byrne suggested that should Overstock be holding bitcoins at the time of its upcoming first-quarter fiscal reporting, it will likely be required to report this action to the tax authorities.

“That’s an issue that the sec and the accounting wizards have not opined yet, so we could be the test case.”

Byrne indicated that he has already been contacted by several outside accounting firms that have voiced an interest in being part of this process. The agencies, he said, are interested in participating because it could set a precedent for how publicly traded bitcoin merchants will need to disclose such holdings.
2128  Economy / Service Discussion / Re: Has someone calculate the volume of Gox double payments? on: February 12, 2014, 09:32:43 PM
Or was this error in the Gox payment system exclusively exploited by criminals?

This.

At the time there was no mass mutation of transactions.  The attackers were mutating their own transactions something like this:
1 ) Attacker request withdraw.
2 ) MtGox generates tx id A (likely defective in a host of ways making the rest of the attack easier).
3 ) Attacker grabs a copy of the "busted tx" and cleans it up (mutates it). Call this tx id "B".
4 ) Attacker pushes mutated version (tx id "B") to a miner.
5 ) Tx id "B" is included in a block.  Attacker has been paid.
6 ) Attacker contact MtGox stating they had not received withdraw (this is made more believable because MtGox broken wallet had created tens of thousands of legit broken transactions).
7 ) MtGox checks blockchain and tx id "A" does not exist.
8 ) MtGox pays the attacker again.

So distilled down the only way you got double paid was if you did all of the following:
a) you noticed MtGox was generating broken transactions
b) you used their API to pull a copy of the tx (because it was being dropped by relay nodes)
c) you modified the transaction to clean it up
d) you received payment and then contacted MtGox claiming you didn't.

It didn't happen by accident.  Even if someone legitimately cleaned up (mutated) their transaction because MtGox was generating broken garbage, they still wouldn't get paid again unless they then lied to MtGox and told them the transaction never went through so MtGox would cut another payment.  

There is no way of knowing how many times attackers did this, or even how many people working together or independently tricked MtGox into overpaying them.  The withdraw issues (legitimate complaints about unconfirmed payments due to MtGox broken wallet) have been going on a month.  Did the attackers realize on day 1 or only a few days ago?  Only MtGox knows.
2129  Bitcoin / Development & Technical Discussion / Re: Malleability in a nutshell on: February 12, 2014, 09:18:21 PM
bitcoind gives you a txid when you send coins. bitcoind has "gettransaction <txid>" to look up transactions. This being broken means that it is all there as a trap to cause you grief. And as a great tool for social engineering to steal your coins. What you are basically saying is that you want bitcoind to contain broken tools so that people will have problems and lose lots of money, and then you can later laugh at them and call them stupid. I don't think that's a good future for bitcoin.

Nobody competent and knowledgeable is saying mutable transaction ids are a good thing.  The trolling and clueless might but who cares.  The long term goal is immutable transaction ids but there are a lot of technical challenges.  It isn't going to be done overnight.  In the short term the way clients handle/report duplicate transactions will be improved, however the reality is that tx ids are mutable for the immediate future.  

So (and I say this tongue in cheek I have used your pool for years) you can either learn to handle mutable tx ids or you can shutdown for 6-12 months and at that point you likely will be able to rely on unconfirmed tx ids being immutable (but even then could be changed by the sender).  To make unconfirmed tx ids immutable will require a core change to the protocol.  There is still disagreement on what is the best way to achieve that goal.   Then extensive testing that will need to be done.  Miners will probably have to show support, clients will have to be soft upgraded, and a deadline put in place.  Just like adding P2SH support,  in a distributed decentralized consensus system there is no fast and easy way to make a breaking change.

So if you want to run a Bitcoin related business in 2014, mutable transaction ids are simply a reality, like the possibility of a double spend, or a 51% attack, or a DDOS attack, or a hacker breaching your hot wallet.  It is just another reality that makes all this a challenge.  I am pretty sure you understand this but for anyone else, the blockchain is the canonical reference of transactions.  Unconfirmed transactions are not guaranteed to be accepted by all nodes. The transaction ids of unconfirmed transaction being mutable are just a manifestation of that reality.

2130  Bitcoin / Armory / Re: Armory and transaction malleability on: February 12, 2014, 08:05:56 PM
Any plans to add an option so that unconfirmed change is not spent?  There are pulls in github to add similar functionality to the QT client.  The fact that Armory favors spent over unspent means it is less of an issue unless the wallet has no/few confirmed outputs.  Do you agree users should have the option of disabling this potentially undesirable behavior?
2131  Bitcoin / Bitcoin Discussion / Re: Overstock getting close $1million sales in bitcoin on: February 12, 2014, 08:03:29 PM
I didn't know they are holding some of their acquired Bitcoins.  That is even bigger news.  Any gain (i.e. difference between value of BTC at time of sale and time of report) is reported separately.  Since they are a publicly traded company they will have to report it.  That would be a first.  If it becomes large enough it might even become its own line item in the quarterly and annual reports.
2132  Bitcoin / Armory / Re: Armory and transaction malleability on: February 12, 2014, 07:56:28 PM
Sorry guys, I haven't been seeing notifications on these threads, and I've been on travel so I hadn't noticed it..

Armory does not have any problems with transaction malleability.

There are no security issues with this.   Armory does not rely on transaction IDs for anything except transaction comments.  If the transaction ID changes out from under you, Armory will silently replace the transaction in the list, and the only thing that will be different will be TxID you see when you double-click on it.

The one problem someone might have is that if it's an outgoing transaction and you created a comment/label for it, that label will not show up on the mutated transaction.  Note, that this already happens with offline transactions, because Armory doesn't know what the final comment/label will be until the signatures are added.  I had actually thought about using the pre-broadcast ID to store comments to solve this problem for offline transactions.  It would also solve it for mutated transactions.

When I first learned about malleability 1.5 years ago I did a review of the code and determined there was nothing to be done.  When Armory sees a new transaction in the blockchain that conflicts with a zero-confirmation transaction in the memory pool, the blockchain tx wins and the conflicting mempool tx is removed.  It all comes down to the fact that Armory only pays attention to TxIns and TxOuts for computing balances, etc, not TxID.


That means it is immune to one of the two problems facing most clients listed here.  A well earned kudo on that.
https://bitcointalk.org/index.php?topic=460944.0

However what about the issue of breaking transactions which rely on unconfirmed change output. 
Does Armory not spend unconfirmed change outputs? 
Does it provide an option to require a certain number of confirmations before change outputs are unlocked for spending?

2133  Bitcoin / Bitcoin Discussion / Re: Should the foundation apologize to GOX?! on: February 12, 2014, 07:40:42 PM
If you aren't the sole controller of your private keys, you don't have any bitcoins.

This can't be said enough.  If "your" bitcoins are under someone elses control you have an IOU for bitcoins, not bitcoins.   Bitcoins can't be defaulted on, IOUs can.  Bitcoins can't be blocked, IOU redemption requests can.

This is one reason why BitSimple never holds user bitcoin balances.  I feel Bitcoin is more secure when users take control of their own wealth.  With instant rate lock there, I need liquidity is no excuse anymore.  You can sell Bitcoins directly from your wallet (any wallet) for dollars in seconds.
2134  Bitcoin / Bitcoin Discussion / Re: What you need to know about Transaction mutability ... on: February 12, 2014, 07:35:37 PM
Having many unspent outputs in a wallet helps speed up spends, but transactions get bigger, as they contain more inputs. This may accelerate dust generation, if there's a bias in favor of never consolidating inputs. Wallets may have to become smarter about when to divide and when to consolidate inputs.

Not necessarily.  A compliant wallet should not generate dust outputs.  It should use proper coin selection to ensure all outputs (including change) are above the dust threshold.  Any spend consolidates outputs.  Outside of niche applications it doesn't make any sense to consolidate outputs.   If you have a large number of small outputs and need to make a large spend then the tx will be larger.   If you conolidate them to avoid that then the consolidation tx will be large.  More outputs (within reason) shouldn't significantly increase transaction size.  Imagine two hypothetical wallets with 100 BTC in confirmed unspent outputs.

Unspent outputs (100 BTC total)
-----------------------
"A" 100 BTC

vs

Unspent outputs (100 BTC total)
-----------------------
"A" 1 BTC
"B" 3 BTC
"C" 3 BTC
"D" 6 BTC
"E" 7 BTC
"F" 20 BTC
"G" 25 BTC
"H" 35 BTC

If I make a withdraw of 0.8 BTC, 6.7 BTC, or 23 BTC either wallet can handle it with a single input. The second wallet would need a second input if I wanted to withdraw 50 BTC but that will not change the transaction size significantly.  I would always prefer to have the later wallet as it can handle all four hypothetical transactions without either waiting for change output to confirm or taking a risk and spending it while unconfirmed.

For a large exchange "output management" is going to be important.  Having all your funds in a single unspent output is going to kill real time transaction processing.


2135  Bitcoin / Legal / Re: Lawsky Says New York Will Adapt Money Transfer Rules for Bitcoin on: February 12, 2014, 07:10:21 PM
In fact if a single state out of 50 decides not to regulate that could be enough.

Sadly it isn't.  BitSimple for example is incorporated in SC however prior legal battles have been fought over the fact that many states statutes indicate that even if your company is NOT in the state (or even in these United States) that if you offer your services to residents of that state you are required to be licensed.  One could certainly argue this interferes with interstate commerce but so far the states have won this battle.  Are you willing to risk your freedom and net worth on winning that battle?  If the state wins, your life is over, if you win the state says "ok" and you are still stuck with the massive legal bill.  

This is why the current system is so burdensome.  It isn't getting regulated in one state, it is getting regulated by 50+ regulators in all the states, each of which may change the laws, regulations, and procedures on any particular day.   Keeping track of the forms, procedures, requirements, and current statutes of one state is a challenge, now multiply that by fifty.

But it doesn't stop there.  The biggest issue is the "unknown".  There is a lot of regulatory uncertainty right now.  No bitcoin exchange has a money transmitter license in NY, are they breaking the law?  On advice of counsel, we have voluntarily chosen to not do business with residents of NY due to the fact that NY could say we are operating an unlicensed money transmission business "in" NY although the company, all its servers, asseets, and employees are hundreds of miles away.   However at least NY has spoken out, that provides us some information.  Most states are an opaque unknown having not said a single word on the applicability of existing statutes to virtual currency exchangers.  Hell the basic definitions of money, currency, and transmission aren't even the same from states to states.  Some states don't even define the words.  Kinda hard to believe you can have a law about "money transmission" and not define "money" or "transmission".  I guess that means the law can be whatever the state wants it to be, whenever they want it to be.   Of course you could always fight them in court.  A legal team will tell you the costs will run into the six figures pretty quick.  So if your company just raised a million dollars you ready to potentially flush a quarter of it down the drain to fight one state in court.  Even if you win, what about the other 49?

The following hyperbolic example is to illustrate a point which don't necessarily reflect reality and shouldn't be taken as legal advice.  NY may says explicitly you need to be licensed, FL has made no such statements but has arrested suspects for running an unlicensed MSB (even after the arrest there have been no statements), the law in PA might not ever apply to virtual currency even if regulators want it to due to the way it is worded, the same thing could be true in MO, but your company is unaware that right now they have an bill being voted on which will change the regulatory scope, CA issues a cease and desist against the Bitcoin foundation a year ago and then there is no followup (were they right or wrong?  I guess you can spend another quarter million and sue them to find out), etc, etc, etc, <insert another 40+ etcs here>.

Starting to see the issue?

The "meta-problem" is regulators often write regulations for large cap companies.  Companies which can spend $10M a year on legal and compliance and it amounts to 1% of revenue.  In the Senate hearing the regulator even shared a story about a small upstate local town bank which complained they had MORE EMPLOYEES WORKING ON COMPLIANCE than all other employees combined.   The shocking thing is although he seemed to share sympathy the regulatory burden hasn't gotten any lighter.  So it is almost like the attitude is "wow, that is bad.  I have no idea how they can even stay in business.  ok lets see what other regulations we can pass today".   I mean it is a head asplode disconnect between the needs of small business and the burden being imposed on them.


On edit: Reading this now makes me sound like I think the world is over, it isn't.  I am optimistic this will eventually be resolved, or the US will simply fall behind other nations where regulation is at least coherent, and compliance is possible for a company with less than a twenty man compliance & legal team.  Bitcoin is the honey badger of money, it doesn't care.  If the system is broken it will find a way to route around the damaged parts.


Quote
What I'm concerned about is anyone looking to extend regulation to anything other than exchanges which makes no sense.

The good news is AFAIK no regulator anywhere at any level is talking about regulating entities which don't exchange virtual currency for real currency.   So far they all seem to see a company accepting Bitcoins is no more a regulated activity than a company accepting credit cards.



2136  Bitcoin / Development & Technical Discussion / Re: The malleability attack is creating a lot of trouble, we need a quick fix on: February 12, 2014, 06:54:44 PM
Exchange can still send bitcoin at any time, just don't try to spend unconfirmed change. Anyway, it is always a good idea to pay multiple clients in one transaction

Yeah, but the issue (I would guess?) is that exchanges were paying one client, then using the unconfirmed txid with their unspent output to pay the next client, and so on and so on... if you have a lot of money paying one client (+ change to yourself) and then are waiting one at a time for a block to confirm your last client's tx is a bad idea, because you'll lock up lots of your coins and slow down your withdrawals to a crawl (one client per 10 minutes, ouch!).  You also don't want to split your coins into tons of different key pairs because then you're accumulating expensive tx fees.  So ideally you should be doing per block settlements (which most exchanges like btc-e already were, I think).

The number of keypairs (unqiue addresses) holding the "funds" doesn't affect the size of the transaction.  The number of discrete inputs (and outputs).  Spending two outputs send to one address isn't any smaller than spending two outputs sent to two addresses.  An exchange is going to have one input in their wallet for each deposit.  Generally that means the exchange will have hundreds of confirmed outputs.  Now depending on the value of the outputs it may take more than one per withdraw but a properly setup exchange (or other service provider which make outbound payments) should be able to process a large number of withdraws using just confirmed outputs.

So it isn't one withdrawal per block.  It is multiple withdraws each using different confirmed outputs and then next block those new change outputs will become confirmed allowing more new transactions.

If a service provider is sending deposits to a cold wallet, and then making a single transaction from the cold wallet to the hot wallet they would end up with less available outputs however there is no requirement to make the funding transaction from cold wallet to hot wallet be a single output.   As an example instead of sending  1x500 BTC to the hotwallet send 10x50 BTC and once that confirms you can process 10 not 1 withdrawals (of up to 50 BTC each).  Outputs are relatively small so you can get ~4 outputs per KB making the cost per discrete output about $0.02 right now.  That is simply the cost of doing business.  A smart exchange will monitor the number and value of their unspent outputs and take action to ensure it isn't exhausted.  For example if a large rush of withdraws reduces the number of confirmed outputs, start creating transactions which produce an extra change output (payment + change + change).  If this sounds hard and complicated ... that is why the exchange is getting paid.  They are providing a service to abstract all this from the user so it just "works".

Start to expect more from your exchange, not give them excuses on why they can't do it. Smiley
2137  Other / Beginners & Help / Re: Sent bitcoins not showing in blockchain, already been 8hour.. how come? Help pls on: February 12, 2014, 06:33:34 PM
By "platform" do you mean a website where you don't have direct control over the private keys (examples would be exchange account, mining pool, etc).

If so understand you can't actually "send" bitcoins all you can do is make a request through the website.

If you made a request and the transaction id doesn't show up in blockchain.info, blockexplorer, or your local wallet it is very likely that either
a) the service has NOT sent your coins
or
b) the service has had an error which produced an invalid transaction that wasn't relayed to peers on the network.

Either way the place to start if the website/service where you made the request and ask them why they haven't sent your coins.

It may take a while for transactions to confirm but valid transactions created by competent service providers should propagate across the network within a matter of seconds.

Simple version:
If a website (any website) reports "we sent your coins" and it has been 60 seconds and your wallet, blockchain.info and blockexplorer all don't show it, then they haven't sent them (or haven't sent them properly). Don't accept excuses that it "might take a while", that is nonsense.  Confirmations "take a while" unconfirmed transactions should be relayed to all nodes on the network within seconds.
2138  Economy / Service Discussion / Re: Bitcoin to paypal -- Legit ? on: February 12, 2014, 05:13:50 PM
Do you have any idea how many scams have been attempted on this website and they all follow the same M.O.

First a posting by someone who has no reputation on this website and then multiple follow ups about how great the service is from many more new members who all claim the same.

999 times out of 1000 its a scam.

If it looks like a duck, walks like a duck, quacks like a duck.......

So why not trade with someone who is already trusted instead?

BitSimple - https://BitSimple.com

2139  Bitcoin / Development & Technical Discussion / Re: The malleability attack is creating a lot of trouble, we need a quick fix on: February 12, 2014, 05:05:33 PM
jl2012 got it. 

The patched reference client will include a command to set the min # of confirmations before change is unlocked (spendable).   For those running a client which support coin control you can temporarily work around the issue by selecting only confirmed outputs.

It also is likely a good idea to keep more confirmed outputs (the # of discrete outputs not necessarily the number of BTC) in the hot wallet.  This will reduce the chance of "confirmed output exhaustion" where a wallet can't make payments because all the change outputs are waiting confirmations.   

Lastly any competence business should be paying the min mandatory fee even for high priority transactions.  Paying sufficient fees becomes even more important now.  If a tx is delayed a few blocks, then the change also becomes unspendable for a few blocks.

Obviously the long term fix is to have immutable transaction ids but that is a long term fix.  The patches being considered right now will at least make the clients are "little smarter" in dealing with the reality of an attacker actively spamming duplicates into the network. 
2140  Bitcoin / Bitcoin Discussion / Re: So It Wasnt All Down To Gox? on: February 12, 2014, 04:21:03 PM
How come all the major exchanges had experienced the same problem, even though the problem was already known. Did they use the same code? Or did they all ignore the problem tough it would go away?

They didn't have the same problem.

MtGox = lets naively keep paying the same customer over and over and over on withdraws so he can steal coins.  Oh crap we just lost a small fortune so lets shutdown and blame Bitcoin.

A few other exchange = the DDOS and the way the reference client handles unconfirmed change outputs is caused us to generate broken withdraws so lets suspend withdraws until the patch to not spend unconfirmed change outputs is released.

Some other exchanges ( including https://bitsimple.com ) = Yup we are still open.  Right this second.

Starting to see the difference?
Pages: « 1 ... 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 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 [107] 108 109 110 111 112 113 114 115 116 117 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 ... 796 »
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!