[CLOSED] CoinLenders

[vlees]

Just read your site thoroughly and NOWHERE does it say application fees are non refundable. You will be reported to proper authorities.

But on another thread you say:

This was not a legal contract. And also Bitcoin is not recognized by the US government as currency. So I have no legal obligation to you. Goodbye

I don't have to give Austin anything. Bitcoin is not recognized as a currency in the United States. And we have no binding contract. I am done with Austin. Fuck you.

So you say the rules that apply to others don't apply to you? Well, how mentally challenged can a single person be?...

[Deprived]

Just read your site thoroughly and NOWHERE does it say application fees are non refundable. You will be reported to proper authorities.

It's an application fee - that means it's a fee you pay for applying.
It isn't an acceptance fee - which you'd only pay if your application was accepted.

[wolverine.ks]

So newb question to break up all the drama a bit....

what is all this verification to prevent MITM stuff?

ive seen it, but what do I do with it?

thanks

[siliclone]

So newb question to break up all the drama a bit....

what is all this verification to prevent MITM stuff?

ive seen it, but what do I do with it?

thanks

It's there for your peace of mind. It's an optional step that you can use to verify the authenticity of the deposit address prior to sending funds. My guess as to the reasoning is that if a MITM attack was taking place, the attacker would not posses certain information found in the message and therefore the generated signature from the injected address would not match.

[shawshankinmate37927]

So newb question to break up all the drama a bit....

what is all this verification to prevent MITM stuff?

ive seen it, but what do I do with it?

thanks

It's there for your peace of mind. It's an optional step that you can use to verify the authenticity of the deposit address prior to sending funds. My guess as to the reasoning is that if a MITM attack was taking place, the attacker would not posses certain information found in the message and therefore the generated signature from the injected address would not match.

The attacker would not possess the private key associated with that deposit address.  Only someone with the private key that corresponds to that deposit address would be able to generate that signature with that message.

[🏰 TradeFortress 🏰]

Can someone help?  I can't for the life of me get the new MITM address verification message to verify using multibit or brainwallet.org.    I had no problems before when it was associated with the address on these forums.  Now I can't send funds because maybe I AM being MITM attacked?  Most likely I'm doing something wrong, but I have tried every combo under the sun to get it to verify and it just won't.

I tried emailing TF, but no reply.

It's part of Inputs.io's message signing format. I'll allow everyone to access inputs.io/clearsign - one sec.

Thanks

[🏰 TradeFortress 🏰]

Copy and paste the signed message here:

https://inputs.io/clearsign

It should say: "Message verified to be from 15Cq6CSmEiGuqYEPmv877iA5dz4h83U4wk"

[🏰 TradeFortress 🏰]

Copy and paste the signed message here:

https://inputs.io/clearsign

It should say: "Message verified to be from 15Cq6CSmEiGuqYEPmv877iA5dz4h83U4wk"

Here's what came back:


Something still isn't working for me.

Heheh

I'll PM you a beta key

[BigBitz]

inputs.io something else you are working on TF?

[🏰 TradeFortress 🏰]

inputs.io something else you are working on TF?

Yes

[vlees]

Can someone help?  I can't for the life of me get the new MITM address verification message to verify using multibit or brainwallet.org.    I had no problems before when it was associated with the address on these forums.  Now I can't send funds because maybe I AM being MITM attacked?  Most likely I'm doing something wrong, but I have tried every combo under the sun to get it to verify and it just won't.

I tried emailing TF, but no reply.

You can verify the message in a normal Bitcoin client.

In Bitcoin-QT you can go to the first menu -> verify message.
The paste the entire message (including "signed with inputs.io.....")
As signer address take the first line from the signature block.
As signature, take the second line. Click verify. Should work.

[🏰 TradeFortress 🏰]

Can someone help?  I can't for the life of me get the new MITM address verification message to verify using multibit or brainwallet.org.    I had no problems before when it was associated with the address on these forums.  Now I can't send funds because maybe I AM being MITM attacked?  Most likely I'm doing something wrong, but I have tried every combo under the sun to get it to verify and it just won't.

I tried emailing TF, but no reply.

You can verify the message in a normal Bitcoin client.

In Bitcoin-QT you can go to the first menu -> verify message.
The paste the entire message (including "signed with inputs.io.....")
As signer address take the first line from the signature block.
As signature, take the second line. Click verify. Should work.

That works too, but it's much easier with Inputs

[BigBitz]

Just a small one.

Code:

2 factor auth has being enabled for your account.

typo it should be either "has been" or "is being" if there is some sort of back end work required.

[siliclone]

So newb question to break up all the drama a bit....

what is all this verification to prevent MITM stuff?

ive seen it, but what do I do with it?

thanks

It's there for your peace of mind. It's an optional step that you can use to verify the authenticity of the deposit address prior to sending funds. My guess as to the reasoning is that if a MITM attack was taking place, the attacker would not posses certain information found in the message and therefore the generated signature from the injected address would not match.

The attacker would not possess the private key associated with that deposit address.  Only someone with the private key that corresponds to that deposit address would be able to generate that signature with that message.

I'm assuming that an attacker that injects a deposit address would also possess the private key for that address. Therefore, the only discernible asset not possessed would be something found in the message itself. Unless MITM in this scenario has nothing to do with injecting a fraudulent address.

[🏰 TradeFortress 🏰]

The message is signed with another address.

[shawshankinmate37927]

So newb question to break up all the drama a bit....

what is all this verification to prevent MITM stuff?

ive seen it, but what do I do with it?

thanks

It's there for your peace of mind. It's an optional step that you can use to verify the authenticity of the deposit address prior to sending funds. My guess as to the reasoning is that if a MITM attack was taking place, the attacker would not posses certain information found in the message and therefore the generated signature from the injected address would not match.

The attacker would not possess the private key associated with that deposit address.  Only someone with the private key that corresponds to that deposit address would be able to generate that signature with that message.

I'm assuming that an attacker that injects a deposit address would also possess the private key for that address.

If an attacker injects a fake deposit address, then yes, it only makes sense to that he possesses the private key to that fake address.  However, when you attempt to verify a message that was signed with the private key of the real deposit address, the signature will not match up with the fake deposit address, causing validation to fail.

[siliclone]

So newb question to break up all the drama a bit....

what is all this verification to prevent MITM stuff?

ive seen it, but what do I do with it?

thanks

It's there for your peace of mind. It's an optional step that you can use to verify the authenticity of the deposit address prior to sending funds. My guess as to the reasoning is that if a MITM attack was taking place, the attacker would not posses certain information found in the message and therefore the generated signature from the injected address would not match.

The attacker would not possess the private key associated with that deposit address.  Only someone with the private key that corresponds to that deposit address would be able to generate that signature with that message.

I'm assuming that an attacker that injects a deposit address would also possess the private key for that address.

If an attacker injects a fake deposit address, then yes, it only makes sense to that he possesses the private key to that fake address.  However, when you attempt to verify a message that was signed with the private key of the real deposit address, the signature will not match up with the fake deposit address, causing validation to fail.

I think that was my point. Although I'll admit a certain ignorance when it comes to the soundness of this approach as it appears on the surface. One would think that if an attacker has the ability to inject a deposit address, then he would also have the ability to at the same time inject his own message and signature, which would then be verifiable when checked against the fake address.
The one way I can see around this is if the message contained some information that the attacker does not know, and is unable to intercept, and therefore unable to forge. This approach however, would require the user to know the content and format of the message to ensure it has all the elements and hasn't been tampered with...

I haven't had lunch. I can't think when I'm hungry.

[🏰 TradeFortress 🏰]

The message must be signed from the same address.

It should say: "Message verified to be from 15Cq6CSmEiGuqYEPmv877iA5dz4h83U4wk"

If it is not that address, then something went wrong.

[sleger]

Hi TF,
What is the procedure to remove the 2fa authentification should the device be lost / stolen / wiped out ?
Thank you

[joeyjmr8484]

My loan is still pending. Can you approve it?