BitMarket

(Not sure if I understood the question, but that's the only exchange I know it's in italian. Also it's where I buy and sell BTC)

Subbing.


You mean javascript?

I use a single passphrase to generate passwords for each site:

http://www.youtube.com/watch?v=KUFkb0d1kbU

Uncrop!

Another thing worth mentioning:

• Sell things and offer services accepting bitcoin as payment. No fees, no chargebacks and since we're still at the early days you will get free publicity.

We already have hashcash. Satoshi was inspired by it to make his paper.

Star Wars the Old Republic for 5 BTC (new is 10-11 BTC).

At the time of this writing (feb 8), 12 days of free game time remaining. Some personal data can't be changed, but you have full access to the game.

I accept escrow.

Think of cash: people give you coins and bills. 100 cents ocuppy much more than one dollar. The same applies with bitcoin transactions: you recollect previous transactions to you and send them into new addresses. Sometimes you send more money than you want to send (like when you pay with a bill), the remaining (the "change") is sent to yourself.

The size of a transaction is proportional to the number of "coins" (independently of the value) and the number of outputs (usually one or two if there's change). If you pay with 100 cents instead with a dollar bill, you pay more fees. That transaction becames a new "coin" for the recipient to use.

I'm opening this thread to continue a discussion started in this other thread.

I think 0-confirmation transactions are safe for small purchases if the merchant have a transaction radar connected with hundreds of nodes across the globe and waits for e.g. 80% propagation with no other conflicting tx.

I've done purchases of 1-2 euros with credit card, and just the fees are far more expensive than the possible double spends undetected by a tx radar.

What do you think? Has anyone tested this thoroughly?

How do you know where's the merchant node? Also, if I'm being DDoSed, I can't see a tx being popagated across the globe, so I would do nothing.

Do you know how blocks are generated? They are generated at random times, for everyone (but the average time always approaches 10 minutes).
0 confirmations for some groceries or 1 confirmation for something e.g. in the $200 range is already safer (and cheaper) than credit cards (chargebacks vs double spends), I think.
Also, if you trust the merchant, you can give it your money when you enter the shop, and on checkout it returns you the change (or everything if you didn't buy).

I found out the 17th of october, the day of the "crash" of bitcoin, a lot of news suporred across the sites I visit. I was not very interested (and I was about to dimiss it) until I saw a comment explaining bitcoin very well in the sea of misleading comments.


Merchants can use 0-confirmation transactions for small amounts of money. With a tx radar and waiting 10-30 seconds you'll be sure there isn't a double spend. To double spend such transactions you would have to mine a block yourself, which is much more expensive.

I have a question for you: Do you want Bitcoin to be successful?

If the answer is yes, we need more people to use it securely. Learn from the problems of the last year, where each security breach meant a drop in the price and the users. You blame people, but people blame Bitcoin itself, making imposible to Bitcoin to ever be popular.

Companies with bank accounts where 2 responsibles are required for high volume transactions are stupid. Yeah...
Your wallet already stores several keys and generates new ones from time to time, even if you don't see them in your input addresses.


Exactly. Bitcoin will be valuable to everyone only when this is possible. Not everybody can make sure all the time their computers aren't compromised.

Let's put it clear for everyone then:

PIP 11: It's already in the protocol but we need support from everyone (GUIs, webpages) to arbitrary-sized addresses such as this one: 1TM1TTodZRiGNY23hgEW4QLroBW5By2gF1FQBwst7BEGPvS3gVh6PuqF5yNPtLFFFy71NzC2bZEX7mU jMJAb8wh6tPVpQeMCcu68F

PIP 16/17: They're too similar the more I read them. It requires protocol changes but they will allow to have regular-sized addresses which redeems the money with several signatures instead of a single one. It also allows much more complex transactions while the address stays the same size. It allows space savings in the block chain.

We can have escrow right now with PIP 11 (it just needs GUI support), but not secure multisig-by-default wallets, as DeathAndTaxes says.

After much thought I came to realize what's the main purpose of PIP 16/17 while we already have PIP 11: The reason is secure wallets that are always multisig without superlong addresses. We'll also have space savings in the chain.

We need PIP 16/17 but what's urgent is PIP 11 in client GUIs.

Ok, I misread PIP 11 the first time. Then why they're pushing PIP 16/17 so hard? While I think it will be needed, I don't think it's a priority. The first thing we need is GUI support for what we already have.

Tell me how we can do m-of-n signatures, or escrow without trusting a third party (or with a third party only in case of dispute).

Those "fancy features" are, in my humble opinion, the killer features that will guarantee bitcoin's success. It requires the consensus of the network, however.

That's exactly what I thought.

This is what I see in this thread:



My vote is for P2SH:

• There's no strong points against it.
• It's the only proposal so far that allows space savings in the future. Just imagine more and more complex unredeemed transactions saved in the chain: with P2SH is just a hash.
• Less potential of having a security flaw.

The only slight drawback I see is that you have to save the script somewhere to redeem it instead just a private key, but I don't think it's a problem if a good escrow negotiation scheme is implemented in the client (to avoid sending an escrow to someone who doesn't save the script).

edit: s/unredeemable/unredeemed/
Edit 2: It seems PIP 17 also allows the same space savings as PIP 16. Correct me if I'm wrong.