Very-low-priority transactions will get dropped by peers, because they look like "spam" transactions and network bandwidth is not free. +1 This is a problem I hope they find a solution to, very annoying. Just to be clear though, this does not mean that the transaction will not ever get processed. Though some peers may not relay a very-low-priority transaction the client will continue trying to resend that transaction to its peers. If the problem is the transaction isn't getting relayed, the client can even be directed to connect to a specific node that relays regardless: - http://en.bitcoin.it/wiki/Free_transaction_relay_policy (though I don't know if that will cause the transaction to be included in a block any sooner.)
|
|
|
I can see the new address at the main interface screen, but no anywhere else)! I tried replicating this but I couldn't. Out of curiosity was the wallet created by 0.3.24, or was this a wallet from a previous version that is getting its first transaction in 0.3.24?[update: When paying closer attention on a second attempt, I now see the behavior you describe. A new address does automatically get generated but no it doesn't get added to the address book.]
|
|
|
Isn't there still chargeback risk with a gift card? I'm assuming the service that accepts prepaid gift cards in exchange for bitcoins uses them for purchases before releasing the bitcoins, thus effectively to the exchange, those are irrevocable after being spent.
|
|
|
the backward payment without fees did not arrive even after a day. I searched the unconfirmed transactions on http://bitcoincharts.com/bitcoin/but cannot find it. It also does not show up in my PC-client. Is it possible that such small transactions without fee are dropped completely by the network? When a transaction is made the bitcoin client announces the transaction to all the nodes it has peered with. Each node in turn announces it to its peers, and so on until eventually even the miner nodes know about it. If for some reason the transaction didn't get announced properly, the client will re-send the transaction after some time has elapsed. For best results, the sender should leave the Bitcoin client running until the transaction gets resent and makes it into a block. This could be many many hours if there are many "low priority" transactions queued, but at the current time there are few.
|
|
|
as a person about to put $4000 into an epic mining rig Notice the green line ... mining is currently at its lowest profitability levels. - http://tvori.info/bitcoin/charts/ (scroll down to the second chart to see the current chart of what I have above.)
|
|
|
Hi. Can I use my Visa gift card to purchase a few bitcoins from you? I don't have any experience with this service, and they just recently launched, but they do mention accepting prepaid gift cards as payment towards the purchase of bitcoins: - http://en.bitcoin.it/wiki/GetBitcoin
|
|
|
If so, PM me. I don't have any experience with this service, and they just recently launched, but they do mention accepting prepaid gift cards as payment towards the purchase of bitcoins: - http://en.bitcoin.it/wiki/GetBitcoin
|
|
|
This saves me a lot of waiting for something that would never happen If your transaction is queued, it will appear here: - http://www.bitcoincharts.com/bitcoinIf it already made it into a block, it will appear here: - http://www.blockexplorer.comIf you isn't in either, then leave your client running so that it will rebroadcast it ... something that could take tens of minutes, or more. It will eventually get included into a block.
|
|
|
All transactions are in the block chain and you can view them in block explorer or via the command line. This is true assuming the recipient is not using an eWallet service. If both parties are using the same eWallet service, the transaction is internal to the Ewallet provider and will not be seen in the block chain. - http://en.bitcoin.it/wiki/EWallet
|
|
|
I used to sell software over PayPal, and the buyer doesn't get the money back by default. The PayPal side reviews the case first. Apples to oranges. Selling software for PayPal payments is not against PayPal's Acceptable Use Policy. Selling bitcoin for PayPal payment IS against PayPal's Acceptable Use Policy.
|
|
|
That's not how the attacks against 0-confirmed transactions work. Either you have to race the payments and try to confuse the network, but that can be detected just by listening on many connections for a few seconds ... no slower than a credit card payment. Ok, that describes what I was missing. The assumption is that with additional software (to make multiple connections and listen for double-spends) the merchant is not at any real risk of a 0-confirmed / race attack being successful. All merchants and users run the Satoshi client today, it does not alert you if a double spend occurs, yet there have been no complaints about reversed transactions as far as I know. One reason there have been no complaints could be that few merchants currently complete a sale based on a 0-confirmed transaction. This is what I believe needs to be tested, with results measured and reported, before I as a merchant would take the risk. Specifically, the test I would want to see the results for is to emulate is a typical point-of-sale scenario -- say where a customer pays using the Bitcoin-android mobile client (and thus has 100% control over the timing with the ability to simultaneously send a message to commence the double-spend) and the merchant's cashier is running the Bitcoin client (the "Satoshi client") with default settings.
|
|
|
If TX fraud is so easy, please go ahead and demonstrate some real attacks against real merchants (you can get their permission to try beforehand). I'm not sure why you are specifying that this be a "real merchant". If these attacks can be proven successful in a lab setting they will be attempted against "real merchants" as well. With a typical point-of-sale transaction, the customer is long gone by the time the current block is solved (which is the first point at which the merchant can realize that a double-spend had occurred). If the attack can be even just occasionally successful it will be attempted. If this race attack is successful in maybe one out of twenty attempts even, I couldn't imagine that merchants would go along with that level of financial risk and/or resulting administrative hassle. Assuming the merchant is just running a normal node and has no double-spend monitoring occurring, I wouldn't doubt that successful attacks would occur.
|
|
|
While there is no immediate resolution to the "can't send less than 0.01 BTC" using InstaWallet, how about allowing those small transfers from one Instawallet to another to be allowed (i.e., the transfer is allowed if the target address is also on InstaWallet)?
MyBitcoin, for instance, allows internal transfers to an address for another MyBitcoin account can be an amount as low as 1 satoshi or something to that effect.
These transactions would have the additional benefit of clearing instantaneously, since they are internal to InstaWallet and not announced to the block chain.
With the API now available, I can think of a couple of uses where this would be handy.
|
|
|
|