|
8241
|
Bitcoin / Bitcoin Discussion / Re: Small transactions without transaction fee
|
on: July 13, 2011, 07:09:43 PM
|
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.) |
|
|
|
|
8242
|
Bitcoin / Bitcoin Technical Support / Re: Bitcoin 0.3.24 different behavior - Where is my "New Auto-Generated Address"?
|
on: July 13, 2011, 10:33:26 AM
|
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.] |
|
|
|
|
8244
|
Bitcoin / Bitcoin Discussion / Re: Small transactions without transaction fee
|
on: July 13, 2011, 09:38:28 AM
|
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. |
|
|
|
|
8256
|
Bitcoin / Development & Technical Discussion / Re: [DRAFT] qwk'n'easy instant payments
|
on: July 11, 2011, 04:40:16 PM
|
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. |
|
|
|
|
8259
|
Bitcoin / Development & Technical Discussion / Re: [DRAFT] qwk'n'easy instant payments
|
on: July 11, 2011, 10:20:18 AM
|
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. |
|
|
|
|
8260
|
Economy / Service Announcements / Re: New, simple online wallet: www.instawallet.org - no signup required
|
on: July 11, 2011, 09:35:23 AM
|
|
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.
|
|
|
|
|
Show Posts
