There is a trusted user named BayAreaCoins in the currency exchange section. I bought paypal money from him some times and i consider it relatively safe. One shouldn't buy from an untrusted user though. As long as no dispute comes up inside of paypal then it would not be a problem that a digital good was traded.

Contact the admins, you need to do this not seldom to clear things. Might be the buyer only forgot to release the coins or other reasons.

I believe administrators can release the coins to you too.

By the way, the third block reward was sent out from the escrow address. See the transaction id:

59da51bd64cb02e4ae784c0259f08ad16f3739676d5b978a412d2bf7dbb59499

Good luck with finding the next rewards...

Clearing browser cache might be a chance too. These cache things in content management systems can be a real pain. And way too often one forgets about one or another cache that can be the source of the problems.

I fully agree with you. And the law enforcement should have not much trouble finding him. He did not run or anything like that... There are other scammer who are, unfortunately, harder to find.

Though when i say that... still nobody visited the address. And it might mean that there is nothing to find. There are enough ways to scam this.

I can only tell you that using an escrow is momentarely the best way to prevent being scammed. Very often scammer vanish silently already when you tell them you contact the escrow. Some play it smart and back out after the escrow had work with the contract. Most probably to find a valid sounding excuse. Still a prevented scam, though often enough people don't tip when a scam was prevented with escrow. Even though he had work and saved the user coins.

I know there was a well known escrow scamming lately but that is pretty seldom. An escrow is increasing safet ALOT.

If someone has a deal you can ask me, see my user profile to find my servicethread.

But wouldn't this first need that the user enables the option that the other partner can interact on his pc? I think the default setting is that the partner only can see and there is a warning before you give him the right to move the mouse on your pc and such things.

So what happened here? Were the rights given?

I didn't know 2 of 3 would create always the same multisig address, though when i think about it it makes sense. I somehow awaited a random factor like with mnemonic phrases for wallets. Though makes sense.

But what i meant with lowering security is that the lower the first number and the higher the last number the higher the chance of a possible scam happening.

For example 2 of 4... it only needs a corrupt escrow who comes out as a trader and trades. Then one person has the power to release the coins. 3 of four would be more safe then since it will be harder and harder to impersonate more parties.

By the way, when will the server give his key? The one controlling the server might be one of the involved parties too.

And the higher the last number the higher the chance that 2 are the same person again.


Yeah, for some shops a buyer really would prefer protection. Though i think that the merchant needs to offer it first. I mean the merchant would agree that he only gets his payment after the buyer receives the goods. That surely is not for every merchant.

Thank you for the explainations. I'm not so much into the details of the tech so i appreciate to learn how it works.

So when the witness is segregated into a parallel block then the amount of data to be transferred and to stored would not be less than if you would put the same amount of data into a normal traditional block? I thought this was one of the main reasons that were brought up against raising the blocksize limit. And the segwit nodes would have to verify the transactions, which then would mean the CPU would still have to work on, let's say, 2MB worth of transactions.

So the internet use, harddisc space and CPU-Usage would not be lower for the same amount of transactions than with traditional blocks?

sturle, you say that it is very unlikely for an old node to create an invalid block. Though segwit surely won't start with the majority of miners. So when segwit hashpower is at 10% of the net then no segwit blocks will be created, segwit blocks start at 95% of hashpower only. So 5% of the blocks would have potentially a chance of being invalid blocks because the old nodes can't see that some addresses already have their bitcoins taken away and they might try to spend them again. Though it doesn't sound like a big problem since when segwit reached that threshold then it is sure that it won't lose that power anymore. It would be safe to switch.

But it is not sure that segwit will reach that, right? Though it would be the same like with the old nodes. It would be safe to assume that segwit wins and that this transaction will never get invalidated.

So it is sure that segwit blocks only start to be created once segwit nodes hashpower reach 95%? I have read it differently, like it would be done from the start to enforce the adoption. So implemented in a different way than previous soft forks. So it is definitely the case that the old threshold is used?

To be honest... at the moment i don't even see anymore why segwit is an advantage when the arguments against 2mb blocks, internet, cpu and harddiscspace usage, are not changed. So it is only easier to raise?

I guess i misinterpreted since that sounds strange.

Coins were sent to ZengryT since i did not receive or read any complaint against it. So i have to assume that all investors got their payment.

Let me know when you need an escrow again...

You write as if this exchange wouldn't own the same address on the other chain then too. But they would ideally. Well, probably depends on the way their wallet creates addresses. Core might be not good if i remember correctly.

But let's assume they own the same deposit address on both chains. Then it would not matter if they receive the coins on both chains and the chain they used on their exchange suddenly dies. They still would have the coins on the other chain. Nothing would be lost.

I hope you got now what i meant.

Yes i think so. Though Lauda wrote like the author of that sentence was so stupid to think that the confirmation time (the 10 minutes) will be lower. At least i interpreted it so since the sentence otherwise would be fine.

Yeah, though the chances are not fair if you think about it. 75% is the majority of hashpower for sure. That's the first point. Then they can do it.

The otherside will make segwit come with higher threshold and lightning network without decision finding.

The problem is that the core developers block the raising of the blocklimit and they can enforce it. So in fact they force all the rest of the community to follow the way they want it to be. I think they can not complain about classic doing a similar thing. Classic at least would know the majority behind themself at that point. Coredevs don't really care about such decision.

In order to allow a decision there is no other way than to present an alternative. So at the end coredevs complain about the possibility to vote. They decided for themselves and for all to not raise the blocksizelimit. Everyone had to follow. Force. Now a way to find the opinion of the community was found and they complain about that happening since they already did their decision for us all.

No, i think the worse enforcer are the core devs. Deciding for everyone without giving a choice and when someone creates a choice then he wants to break everything in their eyes.

Yes, in this sense it is not a democracy... maybe a technocrazy... cpu's are voting... So at the end the wealthy has more power. Was inevitable. But still it is some kind of decision finding. And the strongest wins because he can.

Do you speak about the time that will be used by segwit to reach 95%?


Then were comes the less datausage from? The signatures are not needed to verify the tx?
[/quote]

Actually we tried that first. But it is very complicated, has a learning curve. Then the problem was that the issuer would have to pay in nxt and solutions to pay in bitcoin did not match well.

Counterparty is very easy to handle so that i have high hopes that it will work fast there.

*lol* The GPU-Mining is actually pretty funny. I really did not anticipate such thing from him. Well he probably was surprised by the worth bitcoin reached and had not thought through the following effects.

The thing with the block reward sound like a software bug that might happen when coding. Well, it would have been enough time until that effect would have been triggered.

It's likely that it will be hard to get this amount with signature campaigns.

And for master-P's victims it would be interesting to merge forces with the other scammed members. Informing them about the connection and the more are involved the lower will be the costs.

What would be the sense of doing so? You can't send a reasonable amount of hashingpower to fake nodes just to try raising the hashrate, you would need to put real power into it. And you would only do this when you are sure that the fork wins. You can't fake hashrate like you seem to suggest. At the end it comes to the blocks that are found. And when a classic node miner has XX TH and spreads this hashpower around 10 fake nodes then on that chain there still would only be XX TH from that miner.

I think you mix the kind of vote the XT fans tried with actual votes by hashpower. It's not the same and the number of nodes decides nothing.


It might be that the problem is that one can foresee that there will always be more then 5% miners that categorically would block such a change. Which would make it impossible. On the other hand 75% is a strong sign of the will of the community, well miners aren't actually the community but comes near to it. And it's better to let the majority decide instead staying undecided.

At the end it doesn't matter. Sigwit might get taken over by the net realitively without problems, ln doesn't need a fork but i doubt it will be used very much. And at one point in time it is inevitable anyway to raise the blocksize. It's grinding some time, that's all.

You are right, they will chose one chain. But that doesn't say that they can check incoming deposits against the deposit on the other chain. When they received the bitcoins not only on their chosen chain but on the fork too then they can accept that deposit because it is riskless.

Why should they not monitor the other chain and instead close down completely? That makes no sense businesswise.