Completely decentralized and anonymous marketplace

[alani123]

Interesting but Bitmessage is broken. Can be attacked and spoofing nodes. POW too easy flooding the network is a breeze.

This is not big problem yet. I use it long time and all ok and small holes can be fixed. But I think about alternative way to send messages, may be namecoin network can be used?

Have you even heard of the ip2 network? It's like TOR but I've never heard it had any fatal security holes.

[bitXbay]

@bitXbay ... Just one question... how d fuck do I install this shit?

You say at README file: "Simply copy the file "socks.py" to your Python's lib/site-packages directory,
and you're ready to go."

Firts there is no "socks.py" file anywhere... or am I blind?
Second where is this pythons directory at?? do I have to install python too?? which version?? how todo??

Shit... you put so much effort building the plataform couldnt you dedicade 10min to properly explain how to install this??

anyway I wish you success!!!

Sorry, I forget about README. Installation simple. If you want just .exe, download it from here http://sourceforge.net/projects/bitxbay/files/BitXBay%20Windows%20binaries/ unzip and run. If it is not running, it can be on WinXP or other old windows system, you need python 2.7 and ]pyqt or ]pyqt for 64x if you install 64x python. If you want to run sources you need python 2.7 and pyqt, then use bitmessagemain.py file. If you want to run BitXBay on linux, it can be harder. For linux you need to run bitcoin-qt manualy with settings in config in btc folder and cut string in bitmessagemain.py with running bitcoin-qt.

[HostFat]

@bitXbay
Can you release a BIN that has litemode by default? (so hopefully it doesn't need Bitcoin Core at the first start)

[bitXbay]

How do you solve the problem of "who sends first"?

Once the 3 addresses are generated, someone has to send the coins first. If someone wants to fuck the system over, he simply let the other party send the coins first and then leave. The 5% are forever lost.

Rince and repeat.

 First send always buyer. But merchant cant get this money and spent his own money for rating payment or you know him befor. For this stupid action he need to pay money for rating and what he get with this? Unprofitable and stupid. He cant fuck whole system with this. If merchant pay more for temporary rating we can hope that he is a serious seller. If I have faster message system this can be resolved be small first payments. For example first payment it is 0.01% and second 0.5%... And it is will be absolutely useless. I create update with this if it is rly must be.

[bitXbay]

Dude you forgot to register the .com name. I've grabbed it and redirected it to this topic.

Thx, my main address now it is bitxbay .ws  and I have bitxbay.bit but did not have time for website yet. In a hurry to make a really light version, now the priority use of electrum as alternatives bitcoin-qt.

[bitXbay]

Can you set the litemode by default?
It seems that it still need the Bitcoin-Qt at the first start.

If you have a Windows machine, you can try it with this: http://www.sandboxie.com

Yes it need yet. But I in work for use electrum and other services like blockchain.info. And I want to use this services via tor. Now it is just direct connections and it can deanonymize you. Anyway rly anonymous, decentralized and safe only version with Satoshi's bitcoin-qt. But if you have anonymous and slow internet connection light version can be better.

[bitXbay]

Wow!
I posted this on reddit, people are all over this like crazy!

bitXbay, get over here! :-)

http://www.reddit.com/r/Bitcoin/comments/2ada0b/completely_decentralized_and_anonymous/

Ente

Think will be better if I just fix all what I can befor start to excuses. Come to reddit soon.

[HostFat]

Please also remember to release/update the source code

[tprogex]

How do you solve the problem of "who sends first"?

Once the 3 addresses are generated, someone has to send the coins first. If someone wants to fuck the system over, he simply let the other party send the coins first and then leave. The 5% are forever lost.

Rince and repeat.

I think about same here must be also some feedback system.

[bitXbay]

How do you solve the problem of "who sends first"?

Once the 3 addresses are generated, someone has to send the coins first. If someone wants to fuck the system over, he simply let the other party send the coins first and then leave. The 5% are forever lost.

Rince and repeat.

I think about same here must be also some feedback system.

I wrote above about how to solve this if it really be a problem.

[super3]

Dude you forgot to register the .com name. I've grabbed it and redirected it to this topic.

Thx, my main address now it is bitxbay .ws  and I have bitxbay.bit but did not have time for website yet. In a hurry to make a really light version, now the priority use of electrum as alternatives bitcoin-qt.

Just tell me where to transfer it to. My gift to you. Do you have a Namecheap?

[Ente]

Dude you forgot to register the .com name. I've grabbed it and redirected it to this topic.

Thx, my main address now it is bitxbay .ws  and I have bitxbay.bit but did not have time for website yet. In a hurry to make a really light version, now the priority use of electrum as alternatives bitcoin-qt.

Just tell me where to transfer it to. My gift to you. Do you have a Namecheap?

You, sir, are awesome!

Ente

[dzimbeck]

Interesting but Bitmessage is broken. Can be attacked and spoofing nodes. POW too easy flooding the network is a breeze.

This is not big problem yet. I use it long time and all ok and small holes can be fixed. But I think about alternative way to send messages, may be namecoin network can be used?

Its a huge problem. Im just saying you really need to work around this for scale. The major problem you will have is days where messages will drop and nobody will connect. Luckily the more people that connect to Halo are logging in to Bitmessage. But still many messages get dropped their failure rate can be worse than 50%. Spoofing nodes and attacks are too much. So first of all fix the Bitmessage protocol by hashing the unprotected parts. And there is another fix which is outside the scope of this thread. But nonetheless wanted to give you a heads up.

[dzimbeck]

Ok so I use encrypted email and it works awesome. i2p is also interesting. Maybe trying fixing bitmessage and fork it.     ...my friend just said look at retroshare. We have about 3 protocols so far. Check back with us for ideas and if you come across anything please come back and let us know. No reason why we cant start to reach out to help other projects as time permits.

[Automatic]

Why don't the two peers (Buyer & Merchant) communicate what TXIDs they're going to use to spend, then, one party (Either one) can create a transaction using the two TXIDs and destinating in the 2-2 address, sign it, then send it to the other party. This way the other party can only cash in the other person's money if they also agree to cash in their money as well, otherwise, the transaction is invalid as it's missing signatures.

Seems like such a simple feature of Bitcoin you completely skipped over making this wholle project infinitely worse, as, I think we can all agree, we want a trustless system, currently, this system is highly trustful.

Case in point:- I just lost ~ $0.07 because the seller disappeared (Or went offline) after I had sent the 5% to the initial address, if you used my above system, I'd have either of never sent it, or, the seller would have also have just lost 5%.


EDIT:- And can you explain something else for me? Imagine this:-

1. Seller puts up sale for product
2. Buyer purchases, sends 5% to address, so does the seller, then buyer deposits 100%.
3. Seller refuses to give buyer anything

What happens now? Is there anything the buyer can do? The only way I can see the buyer of getting *any* of his money back is to authorize the transaction to receive 5% of his money back, otherwise, he's out 105%, rather than 100%. This could easily be used to extort people, especially if dealing with large amounts (Say I was buying something for $1,000, I'd rather have lost $1,000 than $1,050).

[bitXbay]

Dude you forgot to register the .com name. I've grabbed it and redirected it to this topic.

Thx, my main address now it is bitxbay .ws  and I have bitxbay.bit but did not have time for website yet. In a hurry to make a really light version, now the priority use of electrum as alternatives bitcoin-qt.

Just tell me where to transfer it to. My gift to you. Do you have a Namecheap?

GREAT Thanks. I registered an account at Namecheap. Login - bitxbay  email - bitxbay@post.cz

[bitXbay]

Ok so I use encrypted email and it works awesome. i2p is also interesting. Maybe trying fixing bitmessage and fork it.     ...my friend just said look at retroshare. We have about 3 protocols so far. Check back with us for ideas and if you come across anything please come back and let us know. No reason why we cant start to reach out to help other projects as time permits.

To easy make a alternative channel, there is should be something like a shared inbox. For main trade board. With bitmessage I use chan channel. I have not looking for yet. Perhaps something like chan exist in one of this 3 protocols.

[bitXbay]

Why don't the two peers (Buyer & Merchant) communicate what TXIDs they're going to use to spend, then, one party (Either one) can create a transaction using the two TXIDs and destinating in the 2-2 address, sign it, then send it to the other party. This way the other party can only cash in the other person's money if they also agree to cash in their money as well, otherwise, the transaction is invalid as it's missing signatures.

Seems like such a simple feature of Bitcoin you completely skipped over making this wholle project infinitely worse, as, I think we can all agree, we want a trustless system, currently, this system is highly trustful.

Case in point:- I just lost ~ $0.07 because the seller disappeared (Or went offline) after I had sent the 5% to the initial address, if you used my above system, I'd have either of never sent it, or, the seller would have also have just lost 5%.


EDIT:- And can you explain something else for me? Imagine this:-

1. Seller puts up sale for product
2. Buyer purchases, sends 5% to address, so does the seller, then buyer deposits 100%.
3. Seller refuses to give buyer anything

What happens now? Is there anything the buyer can do? The only way I can see the buyer of getting *any* of his money back is to authorize the transaction to receive 5% of his money back, otherwise, he's out 105%, rather than 100%. This could easily be used to extort people, especially if dealing with large amounts (Say I was buying something for $1,000, I'd rather have lost $1,000 than $1,050).

Your system almost same but rly more trustless if it can be released. I will try soon.
 Please be realistic. In any situation, someone can lose money. The system makes it so that all were interested in a fair deal. But it can not protect you from incident. For example we have laws, but someone might take up arms and kill you, and would be sent to jail, but you're going to die, so laws dont help.

[Automatic]

Why don't the two peers (Buyer & Merchant) communicate what TXIDs they're going to use to spend, then, one party (Either one) can create a transaction using the two TXIDs and destinating in the 2-2 address, sign it, then send it to the other party. This way the other party can only cash in the other person's money if they also agree to cash in their money as well, otherwise, the transaction is invalid as it's missing signatures.

Seems like such a simple feature of Bitcoin you completely skipped over making this wholle project infinitely worse, as, I think we can all agree, we want a trustless system, currently, this system is highly trustful.

Case in point:- I just lost ~ $0.07 because the seller disappeared (Or went offline) after I had sent the 5% to the initial address, if you used my above system, I'd have either of never sent it, or, the seller would have also have just lost 5%.


EDIT:- And can you explain something else for me? Imagine this:-

1. Seller puts up sale for product
2. Buyer purchases, sends 5% to address, so does the seller, then buyer deposits 100%.
3. Seller refuses to give buyer anything

What happens now? Is there anything the buyer can do? The only way I can see the buyer of getting *any* of his money back is to authorize the transaction to receive 5% of his money back, otherwise, he's out 105%, rather than 100%. This could easily be used to extort people, especially if dealing with large amounts (Say I was buying something for $1,000, I'd rather have lost $1,000 than $1,050).

Your system almost same but rly more trustless if it can be released. I will try soon.
 Please be realistic. In any situation, someone can lose money. The system makes it so that all were interested in a fair deal. But it can not protect you from incident. For example we have laws, but someone might take up arms and kill you, and would be sent to jail, but you're going to die, so laws dont help.

Unless I'm missing something huge, you can relatively easily (Keyword:- Relative, I'm not saying it is easy) make a method where nobody, or, both parties lose money. In your system the buyer is always at risk of losing money. When both parties lose money it's a lot more incentivising than when just one does. Obviously the perfect environment would be where only the person who backed out loses money, but, that seems impossible with our current setup.

EDIT:- This system should also probably add each other's Bitmessage address to the address book after the first communication, this means that *no* work is required for messages to be sent between each other, which, is probably a good thing when making trades. The work is useful on the first message, but, after that, it's just degrading usefulness.

[bitXbay]

Why don't the two peers (Buyer & Merchant) communicate what TXIDs they're going to use to spend, then, one party (Either one) can create a transaction using the two TXIDs and destinating in the 2-2 address, sign it, then send it to the other party. This way the other party can only cash in the other person's money if they also agree to cash in their money as well, otherwise, the transaction is invalid as it's missing signatures.

Seems like such a simple feature of Bitcoin you completely skipped over making this wholle project infinitely worse, as, I think we can all agree, we want a trustless system, currently, this system is highly trustful.

Case in point:- I just lost ~ $0.07 because the seller disappeared (Or went offline) after I had sent the 5% to the initial address, if you used my above system, I'd have either of never sent it, or, the seller would have also have just lost 5%.


EDIT:- And can you explain something else for me? Imagine this:-

1. Seller puts up sale for product
2. Buyer purchases, sends 5% to address, so does the seller, then buyer deposits 100%.
3. Seller refuses to give buyer anything

What happens now? Is there anything the buyer can do? The only way I can see the buyer of getting *any* of his money back is to authorize the transaction to receive 5% of his money back, otherwise, he's out 105%, rather than 100%. This could easily be used to extort people, especially if dealing with large amounts (Say I was buying something for $1,000, I'd rather have lost $1,000 than $1,050).

Your system almost same but rly more trustless if it can be released. I will try soon.
 Please be realistic. In any situation, someone can lose money. The system makes it so that all were interested in a fair deal. But it can not protect you from incident. For example we have laws, but someone might take up arms and kill you, and would be sent to jail, but you're going to die, so laws dont help.

Unless I'm missing something huge, you can relatively easily (Keyword:- Relative, I'm not saying it is easy) make a method where nobody, or, both parties lose money. In your system the buyer is always at risk of losing money. When both parties lose money it's a lot more incentivising than when just one does. Obviously the perfect environment would be where only the person who backed out loses money, but, that seems impossible with our current setup.

EDIT:- This system should also probably add each other's Bitmessage address to the address book after the first communication, this means that *no* work is required for messages to be sent between each other, which, is probably a good thing when making trades. The work is useful on the first message, but, after that, it's just degrading usefulness.

Thx, great advices. I got more work today Want to release it as soon as possible.