Wow, this issue is so old that I've even disabled notifications for this topic (hence my late response). That being said, I did not receive any communication from R- recently, so I don't know what's happening with this.

With that kind of attitude you'd be lucky to get anything more back. R- has already defaulted on this, so it'd be to your benefit to just get as much out of this as you can. One idea of what you can do is to send him an offer that gives him until a set date to pay you back at a discount, but on the condition that if he fails to do so he'll owe you even more than he currently does. Give him a limited amount of time to accept this offer. As a show of good-faith, it would be nice to at least make an offer like this once.

Of course, if you and R- come to an agreement, we would be happy to remove R-'s scammer tag.

Absolutely.

Heh, thanks!

Legalities aside, it could very well result in a ban from this forum. We take suicide threads very seriously and will actively remove any post that even considers suicide a viable option for the person who is contemplating it. Often, these types of posts will be deleted less than 10 seconds after they are posted.

I agree. I see nothing wrong with these threads. You need to remember why this policy was put into place more than you need to actually follow it to the letter.

I would say no.

They can for the sake of good will, but they wouldn't be responsible to do so.

No, because it was a donation.

In the BitcoinStore case, a scammer tag was never given, so I can't say for sure what would have happened there, but even with that there was a huge difference between that issue and the bulanula issue.

With bulanula, the overage was sent as part of a business transaction that was both already expected and negotiated prior to the transaction. Because of that, it was absolutely clear that a typo had been made when the amount that was sent was 10x what was expected. In addition, the sender was able to prove that they were the same person who negotiated the transaction.

With BitcoinStore, the additional transaction came later after the original agreement was settled. Because of this, there is no clear indicator that the amount was a typo, since no balance had been owed for over 22 hours. At that point, the receiver very well might have used the address for another purpose since nothing more was expected to arrive regarding the negotiated transaction. One such purpose may have been as a donation address. And that's where this story gets even weaker, because this was actually an address that BitcoinStore gave to someone else to pay to, meaning that they have no easy way to prove that they own the address and that what they said actually may have happened.

It could be anything...

That being said, because it's essentially a pre-announcement, I think that it shouldn't belong there until the company is revealed.

I think you just answered your own question: we would allow people to sell accounts that were registered through automation. Whether or not we ban that is a completely different debate.

As long as the accounts aren't hacked/stolen, it's just fine to sell them here. Of course, keep in mind that this most likely violates the sites' ToS, but that's the buyer's responsibility.

I think I get what you're saying. You're saying that because everyone already saw a certain block, it's impossible to forge a new one. However, it can easily be the case that because of network latency between peers, different node won't be in the same state at the same time. It is possible for an attacker to tell two different nodes about different versions of the same block and they won't hear of the other conflicting block until later. As DeathAndTaxes explained, this conflict of state is eventually resolved through proof-of-work.

Additionally, because nodes go online and offline in the network as they please, any system that depends on what was heard first without some way to resolve conflicts would totally collapse even if you had some way to reduce latency between all peers to zero.

Finally caught back up...

ianchudson: OK
w00ty: OK
Walter Rothbard: OK
mvj: OK
jcc: OK
WalrusBaller: OK
SpottedMarley: OK
smellymoo: OK
BitcoinByte: OK
bbqsamich: OK
dparrish: OK

Of all of these types of suggestions, this is the most promising:
Ultimate blockchain compression w/ trust-free lite nodes
You'll have plenty of reading to do with just that, trust me.

Before trying to conclude anything from this graph, you need to remember why fees were or were not paid. A strong majority of the transactions were likely made by clients that either require or highly suggest that you pay a fee only when the transaction would otherwise take a long time.

A proper analysis would show time in terms of blocks and would use only their own pairs of transactions that have the same/similar priority when their isn't a fee where one of the pair is submitted with a fee and the other isn't.

The few major issues I've come to realize with that proposal are:
1) It will most likely require cementing at some level so that miners don't "save up" their mined blocks to guarantee themselves a block in the main chain that won't be kicked out by someone else by chance.
2) On a similar note, Finney attacks are guaranteed to be successful, unless some form of block discouraging is used. This wouldn't be that big of a deal if the main chain gets extended every few seconds, though.
3) Any currently-backwards-compatible change that only requires a majority of the miners to upgrade to go into effect would require a hard fork if this were used. This might not be that much of a problem once the Bitcoin network is more mature.

Speaking of #3, that directly relates to that whole contract thing theymos brought up recently: it would truly become impossible to make lost coins unspendable if ECDSA is ever broken, so that would have to be considered too.

Anyway, that's the update on that.

If posts don't match the original topic of the thread, please report them. We might not do anything about occasional short distractions (1-2 posts) that don't result in people losing the focus of the topic, but we will generally take care of them if they go beyond that. Either way, though, report the posts.

Well, if you assume that the email isn't intercepted in-transit (which is a safe assumption for the vast majority of attackers), then the emailed backup is protected by your Blockchain.info password plus whatever security mechanisms you have to use to access the email account. For example, you could also protect the email account that the backups are sent to with 2FA.

...at a penalty of $16000 per order + whatever the local consumer protection laws say. Their official policy is meaningless. They'd be stupid to actually follow it.

You seem to lack the bitcoin-specific economics knowledge for me to do that, sorry. That's just fine! But we want people to be prepared to submit informed comments once they are able to post on the main board. I recommend doing some more reading so that you can get in your 4 hours.

Could you sign something with your OTC key that verifies that your bitcointalk.org account is controlled by the same person who controls that key?

Could we get some more information? A website plus maybe a hidden page that verifies your identity here would be appreciated.

An attacker could choose to hold off the tranaction(s) they are sending to the merchant(s) until they find a block that double-spends those transactions. Then, they send off those transactions with a good fee and hope to god that they are included in the next block, otherwise it would be as if the merchant got the benefit of waiting an extra block. However, unless you only started mining after the transactions made it into a block (which would be stupid, since you'd start a block behind), it is better to premine and hope that the transactions make it into the next block than it is to start mining when the transactions are sent since the transactions could still make it into the next block, except you might not have one mined yet, yourself.

Because then you risk wastefully reverting more blocks than you need to because your transaction(s) didn't get into the first block on the honest side of the fork, decreasing your chance of success.

Dear God this is terrible. Seriously, if any of you are ever in the position where you'll be presenting about bitcoin, at the very minimum you MUST read this:
https://en.bitcoin.it/wiki/Public_relations

Any links that Google has would be accessed all the time, because that's what bots do. So, this will most likely not effect any published links.