I have started an OTC marketplace in IRC channel #bitcoin-otc on freenode. People can enter their supply/demand orders into the order book, and complete transactions OTC. Feel free to join the channel, and to check out the web site with instructions and order book: http://bitcoin-otc.com . Click here to use freenode webchat to join the channel: http://webchat.freenode.net/?channels=#bitcoin-otcAny thoughts, comments, suggestions, questions are welcome.  |
|
|
|
my 0.5 btc : ACH (only works in the US)
still not a bad start (can you guess i'm in the US? ) LibertyReserve: (ok except expensive to transfer in and out)
1% is quite reasonable, as far as transfer fees go. |
|
|
|
please consider this as a bug report:
you should not reveal bidder's usernames in auction history or high bidder display to the world.
Are you sure you're not logged in, looking at your own auction? AFAICT from my own auction, the bidder names were only revealed when I was logged in, looking at my own auctions. i'm not logged in. pretty sure cuz i don't even have an account there. this changed as of yesterday. yesterday everyone was "bidder 1, bidder 2", today all nicks are revealed. |
|
|
|
|
hey biddingpond owner:
please consider this as a bug report:
you should not reveal bidder's usernames in auction history or high bidder display to the world.
your previous display of "bidder 1, bidder 2" was better regarding bidder privacy.
you should reveal each bidder's name /to each specific bidder/, so that he knows whether he won, or whether he is the high bidder, but you should not reveal usernames of everyone to everyone.
so e.g., if i'm logged in as user "aoeu", and i'm the second bidder, then in the bidding history i might see things like "bidder 1, aoeu, bidder 3, bidder 1, aoeu"
so, when you are logged in, only your name becomes revealed only to you.
|
|
|
|
Make sure you keep your node online so it'll keep rebroadcasting transaction b412a0. It haven't seen it rebroadcast since 29/09/2010 16:41.
OK... so i've been running the node for the past day, i have been consistently connected to 8 other nodes, i'm up to the latest block in the chain as of this moment (83535), and the transaction is still not verified... how do we proceed from here, satoshi? |
|
|
|
The command line switches are listed in "bitcoind -?" instead of "bitcoind help". You are still right tho, those options are missing from "-?" too.
lfm: try it, '-help' is /quite/ different from just 'help' ('-help' is the same as '-?') |
|
|
|
Make sure you keep your node online so it'll keep rebroadcasting transaction b412a0. It haven't seen it rebroadcast since 29/09/2010 16:41.
ok, will do... how long should i keep it online for, before i can come back and bug you about it again (if it stays at 0 conf) ? (and btw, i'm using the official .13 client) |
|
|
|
Block 83018 (00000000002bba570c3) cleared out a bunch of them. Last I heard nanotube still had one that's unconfirmed, though.
Edit: Nanotube's transaction cleared recently. I don't know why it was delayed, since it wasn't relying on a sub-0.01 transaction.
just a clarification, the one that "cleared recently" didn't have anything to do with the problem microtransactions. the problem one, that was unconfirmed, is still unconfirmed, see info in my post above. |
|
|
|
Any transactions in your wallet also have bundled with them all unrecorded transactions required to reach the block chain. If you have a transaction that is displayed as 0/unconfirmed, then you have all the previous unrecorded transactions it depends on and you will also rebroadcast those transactions when you rebroadcast yours.
If a no-fee block has already been generated and hasn't helped, then I need to look at what's wrong. It's a part of code that doesn't get much use. They should be recorded in the wallets of everyone who has a transaction depending on them.
I have one transaction that remains perpetually in 0/unconfirmed status in my wallet. Here are the details, as shown in debug mode: Status: 0/unconfirmed
Date: 09/29/2010 12:46
From: unknown
To: 1MgD6rah5zUgEGYZnNmdpnXMaDR3itKYzU (yours, label: gribble stored address)
Credit: 0.03
Net amount: +0.03
debug print
Credit: 0.03
Inputs:
Transaction:
CTransaction(hash=5c05d9, ver=1, vin.size=1, vout.size=1, nLockTime=0)
CTxIn(COutPoint(b412a0, 0), scriptSig=3045022049753afb02f58a7b)
CTxOut(nValue=0.03000000, scriptPubKey=OP_DUP OP_HASH160 e2ccd6) Would appreciate it if you take a look and see what's wrong with it and why it remains unconfirmed.... |
|
|
|
Dwdollar lost some BTC with Bitcoin Market because someone either maliciously or accidentally sent him "unconfirmable" transactions, and he hadn't upgraded. Maybe now would be a good time to test the alert feature.
I can agree with that. otherwise the 0/unconf txns can propagate through the network and mess up a lot of people's wallets. |
|
|
|
Version 0.3.13 is now available.
- Only accept transactions sent by IP address if -allowreceivebyip is specified.
- Option -rpcallowip= to accept json-rpc connections from another machine.
I notice that these options are not showing up in --help output... Shouldn't --help have a comprehensive listing of these options in it? (Especially given that there's no manpage or other help docs distributed in the official-release tarball?) Just an idle question, whose result I hope makes its way into the next release. |
|
|
|
This is just a brief note that I hope will help others compile bitcoind on their debian-like linux system. The main sticking point is figuring out what dependencies are needed. So follow these simple steps below, and you can be up and running in no time. Note that I have done this on Ubuntu 10.04, i386. 1. run sudo apt-get install build-essential libboost-all-dev libssl-dev libdb-dev libdb4.8++-dev libglib2.0-dev to install all the required dependencies. (note that the 4.8 version may differ depending on the age of your distribution) 2. get the source code of bitcoin, either through an svn checkout, or by downloading one of the release tar.gz's 3. cd to the directory where the source code is located, and run make -f makefile.unix bitcoind 4. watch the compilation progress scroll by. 5. the compiled binary 'bitcoind' will be created in your current directory - enjoy! Note: currently the official binary uses libdb 4.7, so if you want to be consistent with that, use libdb4.7++-dev instead of the 4.8 version. if you need to go back to 4.7 after running with 4.8, you need to delete .bitcoin/database/* files, because these logfiles are not backward compatible between 4.8 and 4.7. Any comments/thoughts/suggestions are welcome. :) |
|
|
|
|
ok, so i built a modified bitcoind, with the addition of 'pcoin->GetDepthInMainChain() < 1' to both SelectCoins and GetBalance.
My 'stock client' balance shows as 131.00139787, and my modified client balance shows as 130.92112098, so i have about 0.08xx of "bad" bitcoins' worth of transactions in my wallet.
So I guess now, all i need to do is create another wallet, and then send all the "good coins" from my old wallet to my new one (or, i guess... i could just use the same wallet, since my bitcoind won't try to send the bad coins, i can just ignore them....)
But yes, I hope the modifications as described by jgarzik (being configurable with cli switches/checkboxes) do make it into mainline - because otherwise it's too easy to 'poison' people's wallets with bogus transactions.
|
|
|
|
At (roughly) line 3191 in main.cpp (SelectCoins), change the if statement to this: if (!pcoin->IsFinal() || pcoin->fSpent || pcoin->GetDepthInMainChain() < 1) Your client will then no longer consider coins with 0 confirmations when choosing coins. thanks theymos for the patch! i guess now i have to figure out how to build bitcoind.... or maybe i'll just wait around for this to make it into the next official release... if satoshi agrees with jgarzik as far as including those options in mainline, maybe i don't have to wait that long... |
|
|
|
I checked the code. It seems that the transactions will be relayed, since they pass AcceptToMemoryPool. The network will tend to forget these transactions because the memory pool is cleared when Bitcoin shuts down, and as far as I can tell nodes never relay transactions that they already have in their memory pool. I don't know if there is any protection in the protocol from this kind of attacks There is. The more transactions waiting to be included in a block, the higher the transaction fee has to be for one to get in. theymos: well... the problem is that it causes problems for the wallets that happen to have received those transactions. my wallet now includes a bunch of small transactions that will never be confirmed (due to their not having paid the requisite fees). since the client does not let the user control which coins to send, any transaction i send out in the future is liable to try to include those coins in the outgoing payment, which, in turn, will never get confirmed, thus borking my whole wallet. so say a 'rogue' client harvests a bunch of addresses of the net (these forums are a good and ripe place), and starts sending out a bunch of .000001 payments with no fee. now these wallets will all be contaminated with these never-to-be-confirmed payments, and since the client doesn't allow one to choose which coins get sent, they may be included in future outgoing payments, which will also never get confirmed. so what should i do to 'clear' my wallet? i'd need some custom tool to be able to send /specific coins/, so that i can send them all to another wallet and drop the contaminated one. and more importantly, for the future - how do we address this problem? |
|
|
|
Would you mind posting the 50,000 for sale at mtgox at the exact price of .0900 so I know you have them?
+1 In all seriousness, I graduated from the University of Alabama, and was thinking of going for this week's game on saturday. If I knew you had the coins, I wouldn't mind driving to huntsville to arrange for an in-person transfer. I was thinking I'll buy 25k coins for $1,000?
+1 --- +2 for TTBit |
|
|
|
Hey, so i've been the recipient of a few of these microtransactions
so now i have several transactions in my wallet that are now perpetually in the '0/unconfirmed' state
They will get confirmed when someone that doesn't require fees include them in his/her block. yes and.... at this point /all/ clients require fees for transactions <0.01, do you have any reason to expect that this will change at any point in the future? i don't. so "never will get confirmed" seems a reasonable approximation to reality. so the question is, if i send stuff, will it include those bitcoins in my sends, thus propagating the invalid chain? what is to be done here?
There is no invalid chain just because someone didn't want to pay the fee. It will just take longer for them to get included in a block and until then they can be double spend if someone hasn't heard about them. BTW if nodes don't propagate transactions just because they don't like them it will be dangerous since it will be easier for someone to double spend bitcoins. yes but the problem is that the client doesn't let the user choose which coins to spend, it does it all "automagically" behind the scenes. so how would a user know if he's sending confirmed coins or unconfirmed coins? note also that this seems like a valid way to spam the network - send a bunch of microtransactions without the fee, so you can effectively multispend the same bit of btc and spam everyone's wallets with bogus microtransactions at no cost to you?
You can also send the same 1BTC back and forth between two clients, using different addresses every time. If you do it fast enough you will probably be able to fill up the block that everyone is trying to generate and therefore make the network really slow and lower the chances for legitimate transactions to get into blocks... Also if you do it reeeealllly fast you could saturate the network for a long time, even after you exit the network. You will just leave the rest trying to fit hundreds of thousands of transactions into blocks... I don't know if there is any protection in the protocol from this kind of attacks... If not, they are quite easy to be done. We really need fixed transaction fees with the option to change your preferences on what is the fixed price you accept and what fee to include in your own transactions. yes, but that's a separate issue. i'm really trying to figure out what, if anything, to be doing about the handful of never-to-be-confirmed transactions i have in my wallet, whether the client will prioritize sending other coins first or not, and if not... that means it's possible that i'll never be able to make a send transaction that will be confirmed, because the unconfirmed bits of coin will be included. which would in turn mean that my whole wallet is foobar. |
|
|
|
|
Hey, so i've been the recipient of a few of these microtransactions
so now i have several transactions in my wallet that are now perpetually in the '0/unconfirmed' state
so the question is, if i send stuff, will it include those bitcoins in my sends, thus propagating the invalid chain? what is to be done here?
note also that this seems like a valid way to spam the network - send a bunch of microtransactions without the fee, so you can effectively multispend the same bit of btc and spam everyone's wallets with bogus microtransactions at no cost to you?
|
|
|
|
But I understand that some are uncomfortable with a log being kept, despite it being a public channel that anyone can secretly log anytime. So redacting those member's lines is a good compromise, as long as it's made obvious each line that was redacted. Don't show who's line it was; just indicate that someone unknown said something unknown, so there won't appear to be confusing one-sided conversations.
there are some difficulties with that, though. people will address the 'unknown people' in their messages... they'll make references to what they say in such a way as to enable a determined observer to put together a picture of who the unknown person is and the gist of what they're saying. as a result, it seems to me that trying to redact the logs will be a futile exercise, and only give the redactees a false feeling of 'ooh my messages are not getting logged so nobody knows i was there and what i was saying'. so at the end of the day, the chanops will make a decision one way or the other, which would be either (a) have no logging, and if you don't like it, tough, or (b) have public logging with notice in topic, and if you don't like it, tough. |
|
|
|
|
I have no problem with logging.
|
|
|
|
|
Show Posts
