I would if it was easy. Just wanted to raise voice to what we loose by changing the behavior.

On bitcoinqt I generate a new address for each incoming transaction and label them accordingly, so I have "[from eric for his $x pizza] received yɃ from [eric]". This way I kind of label the transaction. Handling with only few addresses, I would want to label the transactions, too, so the current design is far from perfect for me.

Maybe some "Insufficient funds in the currently selected address. [add random addresses[check to make default]] [add specific addresses [check to make default]]
"Problem" is the sender would think to be sending from his Giszmo address but as Giszmo is at 0Ƀ, Giszmo would not show up at all in the resulting transaction.

It's really tricky You don't have "Balance 2Ƀ (total: 5Ƀ)" but "Balance 2Ƀ (total: 5Ƀ, spendable: 1Ƀ)" with "Balance [current address]Ƀ (total: [all addresses]Ƀ, spendable: [addresses with private key ready]Ƀ)"

Oh, and this will be funny, if users keep their private keys off the device all of the time and for some transactions have to show to the device 5 addresses for the signing process.

Also I want a swipe all functionality to consolidate all keys into one, leaving exactly zero in all the addresses paying minimum fees.


An admin in the play store is the worst case I could think of, and on the long run I guess it's very likely to have all such wallets get wiped out in some incident. The reward is just too huge to not do it. (Ok, so far all huge hacks went without spending their coins but with ZeroCoin they become spendable again and I'm sure some day we will have that.)

Nooo!!! Please don't! The privacy implications of having control not to mix keys when sending is quite valuable. Sure, getting the change back to the same key is a privacy drawback but please think up something that solves both issues.

http://bluebox.com/corporate-blog/bluebox-uncovers-android-master-key/
Mycelium user affected? What would the attack scenario be? Some guy at google tampering with mycelium.apk? Some guy at Verizon tampering with the "Standard-Verizon-clock-widget"? shady.com offering mycelium.apk with a "good" signature? Some guy at Rovio updating angrybirds.apk with a hidden permission?

I just locked voting. We didn't reach my guess ($70) yet and I hope those who said $80 will be the winners but of course this game might not be over in half a year.
Let me know if you think I should open voting again. The vote count is low but it's also kind of stupid to let people vote against others that had one or two months less data.

Edit: Unlocked voting again. Voting ends 9th of August as before.

Yep. If all were permabullish no matter what, it wouldn't help the cause at all. It would only lead to some noobs getting a blody nosy.

mindboggling bullshit going on. (/subscribe)

A problem with this scheme would be a DOS vulnerability. If the consumer negotiates the deal but denies or delays the signature, the producer would either have to build on the prior level of negotiations between the middle-man and him with the next customer (risky-ish), wait for the signature with a timeout (blocking. that's a no-go in almost all scenarios) or negotiate a new channel for as much parallelism he needs (costly-ish. has to be implemented for client and middle-man and results in multiple channels between one provider and one middle-man). The good news is that protecting against this type of DOS-attack would justify to charge a higher premium for the middle man.

blockchain.info has +5k transactions per day. Assuming a normal distribution over the 86400s of a normal Sunday, bulking would barely result in less transactions if you time it to bulk more frequently than every 60s, so yeah, I agree, delaying transactions by 60s is baaad. If nobody complains, I would assume they would rather want to bulk every 5 minutes or even worse, when there are x transactions.

I didn't know about that "feature" and would not recommend a service that does this. How does it work trust-free anyway? I thought blockchain info did the signing in the client with the keys in the client derived from the password?!? If not, which service did that? Now I almost feel bad for suggesting blockchain.info to people.

tosaki I miss a word from you regarding the doubts in escrow dinogenes stated over and over. You as a service provider have to make clear how you will deal with escrow. If it is not 100% sure that in cases where there is no doubt I shipped the good, you will side with me, what would escrow be good for?

good to know your service is deemed worthy to DDOS

Guess your margins are enough to counter it and hope you are back soon. … uhm, here you are very online.

TLDR: Hey middle-man! If you show me that you increase the producer's balance by 1ct. referencing my transaction of 1.01ct to you, you may keep the 0.01ct for your service as with this I can request the service to unlock the paid content.

Long version:
Paypal is not trust-free. They are known to freeze your money just for you trusting them to hand it over to somebody else.
The system proposed here almost allows a middle-man to set up a gateway that is trust free although it would need some more bits:

Think paypal. How would it work with Bitcoin and trust free?
You could have one micro payment channel going from the consumer and one to the producer. These could be linked through a similar contract, so the transaction update consumer -> paypal also references another timed transaction that  gets only valid if any other paypal -> producer transaction also gets updated.

My browser would increment my payment to a gateway address only if they show me a transaction that references my unsigned transaction in increasing the earnings of the website I'm just surfing.

This way I would have two transactions – charge and finalize – per month with some middle man and the middle man would have such two transactions with producers and would never hold any party's money.

Oh, we need a standard for something like that I want something similar to bitcoin:.... adressses that cover this:
bitcoin:middleman=[address]&middlemanfee=50&target=[address]&targetfee=50000.

now the website would have a service running that sees the transaction from the middleman referencing the transaction that I can show them to authorize my access. I would not show the full transaction as I wouldn't want it to be published yet but that should not matter for that fact.

(I'm afraid this does not come over very clearly as it's only now forming in my head but I'm 100% sure you can extend the micro-payment channels to some two step scheme that works trust free multi point to multi point. As non-public transactions are involved you need a middle-man to keep track of these and sign them and of course such a middle man would want his share for keeping the box running but it could be standardized and made available with the standard client, so a lot of competition minimizes the profit they can aim for. Sure, producers and consumers alike would not want to use yet another such middle man but as each such middle-man relation apart from the fees they charge on top only costs 2ct for the two transactions per month, it's not much of a deal to integrate 10 of them if you want to micro-pay 10 pages that all picked distinct such services. The bigger problem would be the money that's locked up for a month like that but I guess this will all be very seamlessly handled by the clients in the future.)

The producer would in fast succession sign that each of these consumers' transactions actually increased his balance and to finalize the deal the middle man could even remove the last consumer as the producer would happily sign this finalization again. Same with the consumers, as they might not want the public to know even the last service they consumed, the middle-man could cut out this bit of info and update the transaction to a wiped version. The public would know that the middle-man got money for no apparent reason and likewise sent money to the producers for no apparent reason and apart from the middle-man (and the parties themselves) nobody knows who consumed what in which quantity.

(P.S.: Regards to all that put the TLDR in the end of their posts hoping people read their long post first. For me a TLDR is an abstract people should read to decide if they want to read the full article, not a summary to sort stuff after reading a long article.)

As soon as you stop being a Nazi here …

I see Bitcoin as a way to get banking to the less fortunate 99% of the world population and classifying somebody as a scammer for living on the wrong continent is what I want to question here.

So the coins are in escrow? What's your problem? How could he scam you out of these coins if they are in escrow? If you think this is to launder some stolen funds (is he buying stuff that can be turned into cash easily? gold or dollars maybe?) you may invite bitmit to check the origin of the funds for some known frauds and while this would still be racist, your trade partner wouldn't need to know about it but as I said before, these coins are at bitmit regardless of the escrow being released to your Nigger or being paid to you as the release from escrow will not happen with the exact same coins.

FYI: Nigeria has 170 million citizens. Also you might want to read about this.

good point. While I'm slightly surprised to read about transaction signing not covering the whole transaction which sounds like a huge design flaw now, changing the hash sounds spooky to me, too.

Where can I down-vote your reply? You didn't read mine, did you?

I would pay some 10ct. per week for coverage via this thread
I check the forum all the time and sure I could check reddit and bitcoin magazin but it's convenient to have all in one place.

And here we see the down side of having versatile language. If there was only one way of stating this fact, a computer would be able to filter it and I could mark it as "got it" and not have to read it about once per page in this and so many other threads in the speculation forum.

I would report any person that asked me to pay out of escrow before receiving the good as a scammer and you deserve to be marked a scammer for that.
You offer your goods with escrow to exactly leave it to the discretion of bitmit to decide if you or they get the money in the end. Changing that rule after somebody spent time (and risked to loose their money to bitmit "getting hacked") is exactly what bitmit can't accept without rendering escrow pointless.

To not have to change the rules after somebody accepted your deal, maybe state that you ship only to the US.

If nobody maintains this thread, I have no objections. I agree that the thread is not useful as is but I would love to have it useful as it was. If the most important articles were linked here, I would not check the press board. If the thread gets locked, I have to. If it stays as is, I will not check the press board, missing the important stuff :/

(it's easier to spot new stuff in a thread than on a board with threads that change order)

It's not bitcoin's obligation to help alt-coins to keep pace. If you are into litecoin, proof they are worth something and that they are not just some scam of some greedy people envy of the early adopters that took all the risk to push bitcoin to what it is now. If something proofs to be essential for a modern crypto currency, bitcoin will adopt it from the alt-coin or die. Not the other way round.
Edit: ooops. bad quote.

Again: Are the BTC in escrow? Will Bitmit trust you that you shipped? If the answer is yes to both questions, on what grounds would you refuse a customer from Nigeria? Did you do some cheap buys on ebay to "gain trust" before you bought something you actually wanted? Would you ship it to some US address? What's your problem man? The US customer of yours might turn out to be a nigger, too. (sorry, but really: what's your problem?)

Satoshi dice should use this! They would save tons of fees and reduce spam for all of us.
I'm so excited!

… maybe not possible … hmm …