BitBay OFFICIAL BITBAY Thread Smart Contracts Decentralized Markets Rolling Peg

[dzimbeck]

Here you go my blog post as promised: http://syscoin.org/in-depth-look-at-the-syscoins-decentralized-marketplace-and-comparing-it-to-the-competition

Ok cool thanks! And good luck on you project, there a lot of text I don't have the time yet to look over all of it. Perhaps on day we could chat about markets and stuff. Ive always thought about plugging BitBay into existing sites. Its always possible to put an api in. Personally, from all that data that gets transacted in one contract I can say its took expensive to store that on a blockchain and will bloat very fast. Like if i put all the contract data on blockchain it would be about 100-200 outputs with 6a. Also, bloating in blockchain size is not going to be your primary issue but simply bandwidth issues. If the markets are popular, they wont scale because if its 10k+ per contract(not including the image) then this can bring your blockchain to a crawl. This doesnt include images. Images need to be heavily compressed. Halo compresses images to 10kb no matter if its a 3 mb image or 20 mb image. Also, you can perform contracts without being connected, you just need to reconnect eventually. Even if you use the blockchain, you need to be connected to sign anything no matter what method you use.

Thanks! Expired offers can be pruned to make it a linear problem. Bloat won't be an issue I talk about that. Images can be but shouldn't be stored in the blockchain.

Spv can be used to reduce bandwidth issues.

Smart contracts will work on the network ready to sign.. They would work offline but yes to sign you would connect and it would send off. IMO it's better than working offline in p2p system because of the random times it rebroadcasts after the pruning cutoff time limit (2 days)...

I was thinking same thing.. We have a lot to discuss. Personally if bloat is solved via pruning then blockchain really doesn't have any  drawbacks

it depends on how you are doing the markets. Bitmessage could do offline transactions with dedicated servers thats no different from SPV in theory. SPV can be insecure due to not confirming enough blocks. It may be more susceptible to botnet attacks. Like for BitHalo, i rely on Biteasy, Electrum and Blockchain.info servers to avoid downloading the blockchain but imagine if they get something wrong like the size of an input. Then it could cause loss of coins. In BitBay, even with 10kb images, we use anonymous pastebins. The big advantage is not having bloat. Its my primary argument against Etherium. For example you can do distributed p2p smart contracts with hashes of approved code that can be downloaded via torrent for full nodes. Anyways... this link is something you and all of us should take seriously. Bitcoin has serious scaling issues forget markets even storing coins is a logistical nightmare if you plan on really calling it "decentralized"

https://en.bitcoin.it/wiki/Scalability

That article only considers VISA transactions but market orders with full descriptions of products, custom settings etc would have to make it 10x bigger. Meaning nobody can download 10mb per second and if they arent connected for a few days they will never catch up.

In other words its impossible to scale in a decentralized way. You need to be able to divide the network into sections either by using different ports and linking those with servers or something.

And dont even get me started with man in the middle, controlling exit nodes, botnet, sybil, sharing fake data with botnet and other attacks. Bitcoin is extremely fragile already, so reliance spv is not the solution.

In many ways these problems are not solved yet not even for bitmessage. There are advantages though to not having a blockchain.

[1714924106]

1714924106

[1714924106]

1714924106

[1714924106]

1714924106

[1714924106]

1714924106

[sidhujag]

Here you go my blog post as promised: http://syscoin.org/in-depth-look-at-the-syscoins-decentralized-marketplace-and-comparing-it-to-the-competition

Ok cool thanks! And good luck on you project, there a lot of text I don't have the time yet to look over all of it. Perhaps on day we could chat about markets and stuff. Ive always thought about plugging BitBay into existing sites. Its always possible to put an api in. Personally, from all that data that gets transacted in one contract I can say its took expensive to store that on a blockchain and will bloat very fast. Like if i put all the contract data on blockchain it would be about 100-200 outputs with 6a. Also, bloating in blockchain size is not going to be your primary issue but simply bandwidth issues. If the markets are popular, they wont scale because if its 10k+ per contract(not including the image) then this can bring your blockchain to a crawl. This doesnt include images. Images need to be heavily compressed. Halo compresses images to 10kb no matter if its a 3 mb image or 20 mb image. Also, you can perform contracts without being connected, you just need to reconnect eventually. Even if you use the blockchain, you need to be connected to sign anything no matter what method you use.

Thanks! Expired offers can be pruned to make it a linear problem. Bloat won't be an issue I talk about that. Images can be but shouldn't be stored in the blockchain.

Spv can be used to reduce bandwidth issues.

Smart contracts will work on the network ready to sign.. They would work offline but yes to sign you would connect and it would send off. IMO it's better than working offline in p2p system because of the random times it rebroadcasts after the pruning cutoff time limit (2 days)...

I was thinking same thing.. We have a lot to discuss. Personally if bloat is solved via pruning then blockchain really doesn't have any  drawbacks

it depends on how you are doing the markets. Bitmessage could do offline transactions with dedicated servers thats no different from SPV in theory. SPV can be insecure due to not confirming enough blocks. It may be more susceptible to botnet attacks. Like for BitHalo, i rely on Biteasy, Electrum and Blockchain.info servers to avoid downloading the blockchain but imagine if they get something wrong like the size of an input. Then it could cause loss of coins. In BitBay, even with 10kb images, we use anonymous pastebins. The big advantage is not having bloat. Its my primary argument against Etherium. For example you can do distributed p2p smart contracts with hashes of approved code that can be downloaded via torrent for full nodes. Anyways... this link is something you and all of us should take seriously. Bitcoin has serious scaling issues forget markets even storing coins is a logistical nightmare if you plan on really calling it "decentralized"

https://en.bitcoin.it/wiki/Scalability

That article only considers VISA transactions but market orders with full descriptions of products, custom settings etc would have to make it 10x bigger. Meaning nobody can download 10mb per second and if they arent connected for a few days they will never catch up.

In other words its impossible to scale in a decentralized way. You need to be able to divide the network into sections either by using different ports and linking those with servers or something.

And dont even get me started with man in the middle, controlling exit nodes, botnet, sybil, sharing fake data with botnet and other attacks. Bitcoin is extremely fragile already, so reliance spv is not the solution.

In many ways these problems are not solved yet not even for bitmessage. There are advantages though to not having a blockchain.

Right but you must place not only trust of your transactions getting relayed properly but also pay fees for using those dedicated servers for incentive to execute other's transactions. This is what OpenBazaar does through arbiter nodes to resolve disputes or to relay transactions.

SPV makes sense if you are a new user or aren't syncing existing transactions, even then it is able to confirm your UTXO's since usually that is all you really care about. If you want your spent outputs you can reindex the entire chain. For existing users, they have already synced and can now prune their chains to reduce blockchain size (some may not, some may enable pruning). Depends on the hardware they are running on.

Regarding scalaibility yes I believe Gaven is addressing not only releasing the block size constraint but thinking of ways to solve the bandwidth issue, SPV reduces network trust but makes sense for thin clients.. and the mechanism I told you about before by being able to confirm your UTXO's reducing bandwidth to kb's instead of mb's is just an example that many people are working towards solving the issues and I'm confident they will and when they do, we can simply reap the benefits of the solutions because we share codebases. The big advantages of using the blockchain I believe will start showing as we do more integration work, that would be not only more complex but impractical to do via the P2P approach... however I do believe you know what you are doing and can solve any issue its just a matter of development time, and leveraging others work that you trust is critical in trying to achieve the network effect which is essentially the end game for all projects except the one that gets it.

The elegance and genius of Satoshi usually will not show itself inherently until you try to use it and integrate with it for new ideas that people would have thought would have been better suited with existing decentralised technologies. Infact like I said in the blog, he actually had a marketplace stub implementation in the 0.1 reference qt client but was incomplete.. its obviously alot of grunt work for him and he probably thought his time was best served in other areas of interest and rightfully so.

Also what you have to understand is that the service of offers in the blockchain is not meant to be analogous to the spending of currency which is expected to have higher velocity, so to match VISA speed requirements would obviously not be a very fair comparison since I don't believe that the e-commerce marketplace has the need to transact at the same speed as a currency transaction, unless you talk about paying the offer which offers no metadata and is streamlined to be a simple transaction from the bitcoin core so 8 mb/s required for VISA speeds for paying offers. What you talk about is not a "Bitcoin" problem per se but it is the P2P layer that will not be able to handle transactions fast enough and becomes a bottlenecks compared to VISA. It becomes a problem of Memory bloat if you have transactions filling up the mempool but not confirming fast enough to avoid the mempool from taking up all the available memory in the system. Since you would keep tx's around for 2 days wouldn't it also be a problem with BitHalo/BitMessage? If 2 days is a cutoff and the transactions are piling ontop faster than they can be processed you will have a case where they are not queued any longer and you lost those transactions. Since P2P markets take up considerable more bandwidth than their blockchain counterparts it will become a bigger problem in the P2P implementation than it will ever be in the blockchain version.

[dzimbeck]

Here you go my blog post as promised: http://syscoin.org/in-depth-look-at-the-syscoins-decentralized-marketplace-and-comparing-it-to-the-competition

Ok cool thanks! And good luck on you project, there a lot of text I don't have the time yet to look over all of it. Perhaps on day we could chat about markets and stuff. Ive always thought about plugging BitBay into existing sites. Its always possible to put an api in. Personally, from all that data that gets transacted in one contract I can say its took expensive to store that on a blockchain and will bloat very fast. Like if i put all the contract data on blockchain it would be about 100-200 outputs with 6a. Also, bloating in blockchain size is not going to be your primary issue but simply bandwidth issues. If the markets are popular, they wont scale because if its 10k+ per contract(not including the image) then this can bring your blockchain to a crawl. This doesnt include images. Images need to be heavily compressed. Halo compresses images to 10kb no matter if its a 3 mb image or 20 mb image. Also, you can perform contracts without being connected, you just need to reconnect eventually. Even if you use the blockchain, you need to be connected to sign anything no matter what method you use.

Thanks! Expired offers can be pruned to make it a linear problem. Bloat won't be an issue I talk about that. Images can be but shouldn't be stored in the blockchain.

Spv can be used to reduce bandwidth issues.

Smart contracts will work on the network ready to sign.. They would work offline but yes to sign you would connect and it would send off. IMO it's better than working offline in p2p system because of the random times it rebroadcasts after the pruning cutoff time limit (2 days)...

I was thinking same thing.. We have a lot to discuss. Personally if bloat is solved via pruning then blockchain really doesn't have any  drawbacks

it depends on how you are doing the markets. Bitmessage could do offline transactions with dedicated servers thats no different from SPV in theory. SPV can be insecure due to not confirming enough blocks. It may be more susceptible to botnet attacks. Like for BitHalo, i rely on Biteasy, Electrum and Blockchain.info servers to avoid downloading the blockchain but imagine if they get something wrong like the size of an input. Then it could cause loss of coins. In BitBay, even with 10kb images, we use anonymous pastebins. The big advantage is not having bloat. Its my primary argument against Etherium. For example you can do distributed p2p smart contracts with hashes of approved code that can be downloaded via torrent for full nodes. Anyways... this link is something you and all of us should take seriously. Bitcoin has serious scaling issues forget markets even storing coins is a logistical nightmare if you plan on really calling it "decentralized"

https://en.bitcoin.it/wiki/Scalability

That article only considers VISA transactions but market orders with full descriptions of products, custom settings etc would have to make it 10x bigger. Meaning nobody can download 10mb per second and if they arent connected for a few days they will never catch up.

In other words its impossible to scale in a decentralized way. You need to be able to divide the network into sections either by using different ports and linking those with servers or something.

And dont even get me started with man in the middle, controlling exit nodes, botnet, sybil, sharing fake data with botnet and other attacks. Bitcoin is extremely fragile already, so reliance spv is not the solution.

In many ways these problems are not solved yet not even for bitmessage. There are advantages though to not having a blockchain.

Right but you must place not only trust of your transactions getting relayed properly but also pay fees for using those dedicated servers for incentive to execute other's transactions. This is what OpenBazaar does through arbiter nodes to resolve disputes or to relay transactions.

SPV makes sense if you are a new user or aren't syncing existing transactions, even then it is able to confirm your UTXO's since usually that is all you really care about. If you want your spent outputs you can reindex the entire chain. For existing users, they have already synced and can now prune their chains to reduce blockchain size (some may not, some may enable pruning). Depends on the hardware they are running on.

Regarding scalaibility yes I believe Gaven is addressing not only releasing the block size constraint but thinking of ways to solve the bandwidth issue, SPV reduces network trust but makes sense for thin clients.. and the mechanism I told you about before by being able to confirm your UTXO's reducing bandwidth to kb's instead of mb's is just an example that many people are working towards solving the issues and I'm confident they will and when they do, we can simply reap the benefits of the solutions because we share codebases. The big advantages of using the blockchain I believe will start showing as we do more integration work, that would be not only more complex but impractical to do via the P2P approach... however I do believe you know what you are doing and can solve any issue its just a matter of development time, and leveraging others work that you trust is critical in trying to achieve the network effect which is essentially the end game for all projects except the one that gets it.

The elegance and genius of Satoshi usually will not show itself inherently until you try to use it and integrate with it for new ideas that people would have thought would have been better suited with existing decentralised technologies. Infact like I said in the blog, he actually had a marketplace stub implementation in the 0.1 reference qt client but was incomplete.. its obviously alot of grunt work for him and he probably thought his time was best served in other areas of interest and rightfully so.

Also what you have to understand is that the service of offers in the blockchain is not meant to be analogous to the spending of currency which is expected to have higher velocity, so to match VISA speed requirements would obviously not be a very fair comparison since I don't believe that the e-commerce marketplace has the need to transact at the same speed as a currency transaction, unless you talk about paying the offer which offers no metadata and is streamlined to be a simple transaction from the bitcoin core so 8 mb/s required for VISA speeds for paying offers. What you talk about is not a "Bitcoin" problem per se but it is the P2P layer that will not be able to handle transactions fast enough and becomes a bottlenecks compared to VISA. It becomes a problem of Memory bloat if you have transactions filling up the mempool but not confirming fast enough to avoid the mempool from taking up all the available memory in the system. Since you would keep tx's around for 2 days wouldn't it also be a problem with BitHalo/BitMessage? If 2 days is a cutoff and the transactions are piling ontop faster than they can be processed you will have a case where they are not queued any longer and you lost those transactions. Since P2P markets take up considerable more bandwidth than their blockchain counterparts it will become a bigger problem in the P2P implementation than it will ever be in the blockchain version.

Well actually, the market itself does not have to be decentralized in every case. i know that may seem off topic, but you know, being able to pull data from Ebay may be what gets the network effect fastest. The way BitBay works with Bitmessage orders is by signing the entire json dictionary which gets hashed using a special json hashing function to order it and then signed with your private key. Thats pretty much identical to how Bitcoin works under the hood but more flexible. However in this case a bit faster because you arent signing every input. After all, you are only trying to verify that you are not spoofing data and not man in the middle.

A blockchain IS a p2p system. Period. We are comparing apples to apples haha. Bitmessage just doesnt hold on to data for more than 2 days. However services to hold on to that data and hash it in the form of a notary chain, burn to a blockchain can be extremely secure since the hash must exactly match. Also since the market data is signed identical to a bitcoin transaction at least in my implementation, there is absolutely no reason you cant have master nodes etc. Of course you can also burn it but this is just a value added option. Me and Vitalik discussed this today and he seemed to have the same idea as you which is "eventually they will solve it". I'm not really waiting for the issue to get solved, i simply did it the way i knew could work now.
There is no solution yet, if Bitcoin had to scale to visa sizes today it would fail. Lets agree that BTC needs a full rewrite. I personally wish i had the time to do that in python. Regardless, you are right, it can definitely be written better more elegant for scaling issues and i think blockchains can be reduced 10x in size for bandwidth and 1000x in size for storage. But then sime bandwidth problems persist... how can one make a letter/char less than 8 bits?! Maybe one day we will move beyond a binary system where frequencies are measured and have some sort of base 10+ system.

Here Bitmessage and any other implementation will face a similar problem but has the advantage of switching ports if the traffic is too unbearable. Also perhaps having something signed in the header to make traffic more specialized. Header data first explaining categories, one network for reading the search query etc. So we can break it up too. This is all just a data management issue.

Like, how would a mesh network handle all of its own issues. We are heading towards a p2p society, blockchains are p2p and so are markets, the concept is to break data management into pieces, magnet links, ports what is needed to streamline this to scale to surpass current bottlenecks.

2 days is an arbitrary limitation and i can change that in the code if we have to and run on another port. Perhaps even change how messages are held or pruned, access knownnodes.dat and add ips that are from the network and trusted and even have a full seeder that scans the entire internet with the zmap library. Lots to discuss, and lots of ways to solve the problem.

This reminds me, SPV might be very useful for my decentralized exchange NightTrader. Ive got to learn a bit more about it and how to run those nodes because in the case of decentralized exchange with 20 different coins we dont want to force everyone to download each blockchain they trade in (if they really dont want to wait). So yeah it has its place and confirming blocks even if not the full blockchain still wards off basic attacks.

You and me both know, sybil and botnet is a problem with or without spv and Gavin would agree with me im sure there is absolutely no solution yet. Some trust is still required.

By the way, i do realize you grouped some of the competitors into the same category but it may be confusing to a reader. Obviously BitHalo/BlackHalo and BitBay dont have the fee structure problem of OpenBazaar and we dont have the Escrow problem of OB. If you guys do an escrow PLEASE do 2 of 2. Dont do 2 of 3 or you risk collusion attacks (escrow agents getting involved in their own deals and taking the coins). Also remember escrow agents cant determine who is lying and NEVER will be able to determine who is lying no matter how advanced technology gets.

So please use 2 of 2 as an option its the only reason i got into bitcoin. You cant have decentralized money with centralized escrow services. That 3rd party has got to go.

[sidhujag]

Here you go my blog post as promised: http://syscoin.org/in-depth-look-at-the-syscoins-decentralized-marketplace-and-comparing-it-to-the-competition

Ok cool thanks! And good luck on you project, there a lot of text I don't have the time yet to look over all of it. Perhaps on day we could chat about markets and stuff. Ive always thought about plugging BitBay into existing sites. Its always possible to put an api in. Personally, from all that data that gets transacted in one contract I can say its took expensive to store that on a blockchain and will bloat very fast. Like if i put all the contract data on blockchain it would be about 100-200 outputs with 6a. Also, bloating in blockchain size is not going to be your primary issue but simply bandwidth issues. If the markets are popular, they wont scale because if its 10k+ per contract(not including the image) then this can bring your blockchain to a crawl. This doesnt include images. Images need to be heavily compressed. Halo compresses images to 10kb no matter if its a 3 mb image or 20 mb image. Also, you can perform contracts without being connected, you just need to reconnect eventually. Even if you use the blockchain, you need to be connected to sign anything no matter what method you use.

Thanks! Expired offers can be pruned to make it a linear problem. Bloat won't be an issue I talk about that. Images can be but shouldn't be stored in the blockchain.

Spv can be used to reduce bandwidth issues.

Smart contracts will work on the network ready to sign.. They would work offline but yes to sign you would connect and it would send off. IMO it's better than working offline in p2p system because of the random times it rebroadcasts after the pruning cutoff time limit (2 days)...

I was thinking same thing.. We have a lot to discuss. Personally if bloat is solved via pruning then blockchain really doesn't have any  drawbacks

it depends on how you are doing the markets. Bitmessage could do offline transactions with dedicated servers thats no different from SPV in theory. SPV can be insecure due to not confirming enough blocks. It may be more susceptible to botnet attacks. Like for BitHalo, i rely on Biteasy, Electrum and Blockchain.info servers to avoid downloading the blockchain but imagine if they get something wrong like the size of an input. Then it could cause loss of coins. In BitBay, even with 10kb images, we use anonymous pastebins. The big advantage is not having bloat. Its my primary argument against Etherium. For example you can do distributed p2p smart contracts with hashes of approved code that can be downloaded via torrent for full nodes. Anyways... this link is something you and all of us should take seriously. Bitcoin has serious scaling issues forget markets even storing coins is a logistical nightmare if you plan on really calling it "decentralized"

https://en.bitcoin.it/wiki/Scalability

That article only considers VISA transactions but market orders with full descriptions of products, custom settings etc would have to make it 10x bigger. Meaning nobody can download 10mb per second and if they arent connected for a few days they will never catch up.

In other words its impossible to scale in a decentralized way. You need to be able to divide the network into sections either by using different ports and linking those with servers or something.

And dont even get me started with man in the middle, controlling exit nodes, botnet, sybil, sharing fake data with botnet and other attacks. Bitcoin is extremely fragile already, so reliance spv is not the solution.

In many ways these problems are not solved yet not even for bitmessage. There are advantages though to not having a blockchain.

Right but you must place not only trust of your transactions getting relayed properly but also pay fees for using those dedicated servers for incentive to execute other's transactions. This is what OpenBazaar does through arbiter nodes to resolve disputes or to relay transactions.

SPV makes sense if you are a new user or aren't syncing existing transactions, even then it is able to confirm your UTXO's since usually that is all you really care about. If you want your spent outputs you can reindex the entire chain. For existing users, they have already synced and can now prune their chains to reduce blockchain size (some may not, some may enable pruning). Depends on the hardware they are running on.

Regarding scalaibility yes I believe Gaven is addressing not only releasing the block size constraint but thinking of ways to solve the bandwidth issue, SPV reduces network trust but makes sense for thin clients.. and the mechanism I told you about before by being able to confirm your UTXO's reducing bandwidth to kb's instead of mb's is just an example that many people are working towards solving the issues and I'm confident they will and when they do, we can simply reap the benefits of the solutions because we share codebases. The big advantages of using the blockchain I believe will start showing as we do more integration work, that would be not only more complex but impractical to do via the P2P approach... however I do believe you know what you are doing and can solve any issue its just a matter of development time, and leveraging others work that you trust is critical in trying to achieve the network effect which is essentially the end game for all projects except the one that gets it.

The elegance and genius of Satoshi usually will not show itself inherently until you try to use it and integrate with it for new ideas that people would have thought would have been better suited with existing decentralised technologies. Infact like I said in the blog, he actually had a marketplace stub implementation in the 0.1 reference qt client but was incomplete.. its obviously alot of grunt work for him and he probably thought his time was best served in other areas of interest and rightfully so.

Also what you have to understand is that the service of offers in the blockchain is not meant to be analogous to the spending of currency which is expected to have higher velocity, so to match VISA speed requirements would obviously not be a very fair comparison since I don't believe that the e-commerce marketplace has the need to transact at the same speed as a currency transaction, unless you talk about paying the offer which offers no metadata and is streamlined to be a simple transaction from the bitcoin core so 8 mb/s required for VISA speeds for paying offers. What you talk about is not a "Bitcoin" problem per se but it is the P2P layer that will not be able to handle transactions fast enough and becomes a bottlenecks compared to VISA. It becomes a problem of Memory bloat if you have transactions filling up the mempool but not confirming fast enough to avoid the mempool from taking up all the available memory in the system. Since you would keep tx's around for 2 days wouldn't it also be a problem with BitHalo/BitMessage? If 2 days is a cutoff and the transactions are piling ontop faster than they can be processed you will have a case where they are not queued any longer and you lost those transactions. Since P2P markets take up considerable more bandwidth than their blockchain counterparts it will become a bigger problem in the P2P implementation than it will ever be in the blockchain version.

Well actually, the market itself does not have to be decentralized in every case. i know that may seem off topic, but you know, being able to pull data from Ebay may be what gets the network effect fastest. The way BitBay works with Bitmessage orders is by signing the entire json dictionary which gets hashed using a special json hashing function to order it and then signed with your private key. Thats pretty much identical to how Bitcoin works under the hood but more flexible. However in this case a bit faster because you arent signing every input. After all, you are only trying to verify that you are not spoofing data and not man in the middle.

A blockchain IS a p2p system. Period. We are comparing apples to apples haha. Bitmessage just doesnt hold on to data for more than 2 days. However services to hold on to that data and hash it in the form of a notary chain, burn to a blockchain can be extremely secure since the hash must exactly match. Also since the market data is signed identical to a bitcoin transaction at least in my implementation, there is absolutely no reason you cant have master nodes etc. Of course you can also burn it but this is just a value added option. Me and Vitalik discussed this today and he seemed to have the same idea as you which is "eventually they will solve it". I'm not really waiting for the issue to get solved, i simply did it the way i knew could work now.
There is no solution yet, if Bitcoin had to scale to visa sizes today it would fail. Lets agree that BTC needs a full rewrite. I personally wish i had the time to do that in python. Regardless, you are right, it can definitely be written better more elegant for scaling issues and i think blockchains can be reduced 10x in size for bandwidth and 1000x in size for storage. But then sime bandwidth problems persist... how can one make a letter/char less than 8 bits?! Maybe one day we will move beyond a binary system where frequencies are measured and have some sort of base 10+ system.

Here Bitmessage and any other implementation will face a similar problem but has the advantage of switching ports if the traffic is too unbearable. Also perhaps having something signed in the header to make traffic more specialized. Header data first explaining categories, one network for reading the search query etc. So we can break it up too. This is all just a data management issue.

Like, how would a mesh network handle all of its own issues. We are heading towards a p2p society, blockchains are p2p and so are markets, the concept is to break data management into pieces, magnet links, ports what is needed to streamline this to scale to surpass current bottlenecks.

2 days is an arbitrary limitation and i can change that in the code if we have to and run on another port. Perhaps even change how messages are held or pruned, access knownnodes.dat and add ips that are from the network and trusted and even have a full seeder that scans the entire internet with the zmap library. Lots to discuss, and lots of ways to solve the problem.

This reminds me, SPV might be very useful for my decentralized exchange NightTrader. Ive got to learn a bit more about it and how to run those nodes because in the case of decentralized exchange with 20 different coins we dont want to force everyone to download each blockchain they trade in (if they really dont want to wait). So yeah it has its place and confirming blocks even if not the full blockchain still wards off basic attacks.

You and me both know, sybil and botnet is a problem with or without spv and Gavin would agree with me im sure there is absolutely no solution yet. Some trust is still required.

By the way, i do realize you grouped some of the competitors into the same category but it may be confusing to a reader. Obviously BitHalo/BlackHalo and BitBay dont have the fee structure problem of OpenBazaar and we dont have the Escrow problem of OB. If you guys do an escrow PLEASE do 2 of 2. Dont do 2 of 3 or you risk collusion attacks (escrow agents getting involved in their own deals and taking the coins). Also remember escrow agents cant determine who is lying and NEVER will be able to determine who is lying no matter how advanced technology gets.

So please use 2 of 2 as an option its the only reason i got into bitcoin. You cant have decentralized money with centralized escrow services. That 3rd party has got to go.

Fully agree about trustless escrow.. we have a design for that. I quite like your escrow system and we had a similar concept that I talk about in the blog with an excerpt  of our design document. Locking coins as collateral makes it trustless... It's a bit more involved than simply locking 2x coins on each side however, its next to do on our list.

About grouping competitors, I grouped based on p2p vs blockchain and I also talk about your impelemtations apart from other projects. I spoke about the escrow system you put in place and talked about the pegging mechanism and that I watch with interest.

I think we do think alike in many senses just that my views of the integration of the marketplace technology differs slightly from yours. For example an ebay API integration would be sweet but not highest on my priority list since people selling on ebay would like to use ebay since customers know about ebay, they will visit the site and don't know about the custom interface you've created which is hosted on xyz.com. Sure for a merchant it saves costs, and cheaper transactiosn for consumers but it doesnt have network effect to take marketshare away from ebay, and you would need to spend millions of $ in marketing to make that happen.

Instead IMO a cheaper alternative to reach the network effect would be if I  focus on trying to integrate the technology in existing web infrastructure so that you can be running your e-commerce website and simply enable the integration without redirecting customers to some other interface... we both agree UX work is not only hard but time consuming with several interations of reviews required by customers in order to "get it right"... my thinking was always to try to maximize the amount of "good" work that is already done and build on top of it. The most common shopping carts have PUSH API's that can be built into (in fact I've intergrated about 11 of them for the bitshares project as payment gateways so I know them quite well, see http://github.com/sidhujag)... I don't think ebay has a push API but if it does great, thats exactly what I need/want although I think you are talking about a PULL api to extract info from a system to reuse in another application.

It was a cool experience doing those payment gateways (I am still integrating more as being a bitshares delegate) and it shaped my thinking into what it is now about using marketplace and building it as a gateway plugins into other softwares.

[dzimbeck]

Here you go my blog post as promised: http://syscoin.org/in-depth-look-at-the-syscoins-decentralized-marketplace-and-comparing-it-to-the-competition

Ok cool thanks! And good luck on you project, there a lot of text I don't have the time yet to look over all of it. Perhaps on day we could chat about markets and stuff. Ive always thought about plugging BitBay into existing sites. Its always possible to put an api in. Personally, from all that data that gets transacted in one contract I can say its took expensive to store that on a blockchain and will bloat very fast. Like if i put all the contract data on blockchain it would be about 100-200 outputs with 6a. Also, bloating in blockchain size is not going to be your primary issue but simply bandwidth issues. If the markets are popular, they wont scale because if its 10k+ per contract(not including the image) then this can bring your blockchain to a crawl. This doesnt include images. Images need to be heavily compressed. Halo compresses images to 10kb no matter if its a 3 mb image or 20 mb image. Also, you can perform contracts without being connected, you just need to reconnect eventually. Even if you use the blockchain, you need to be connected to sign anything no matter what method you use.

Thanks! Expired offers can be pruned to make it a linear problem. Bloat won't be an issue I talk about that. Images can be but shouldn't be stored in the blockchain.

Spv can be used to reduce bandwidth issues.

Smart contracts will work on the network ready to sign.. They would work offline but yes to sign you would connect and it would send off. IMO it's better than working offline in p2p system because of the random times it rebroadcasts after the pruning cutoff time limit (2 days)...

I was thinking same thing.. We have a lot to discuss. Personally if bloat is solved via pruning then blockchain really doesn't have any  drawbacks

it depends on how you are doing the markets. Bitmessage could do offline transactions with dedicated servers thats no different from SPV in theory. SPV can be insecure due to not confirming enough blocks. It may be more susceptible to botnet attacks. Like for BitHalo, i rely on Biteasy, Electrum and Blockchain.info servers to avoid downloading the blockchain but imagine if they get something wrong like the size of an input. Then it could cause loss of coins. In BitBay, even with 10kb images, we use anonymous pastebins. The big advantage is not having bloat. Its my primary argument against Etherium. For example you can do distributed p2p smart contracts with hashes of approved code that can be downloaded via torrent for full nodes. Anyways... this link is something you and all of us should take seriously. Bitcoin has serious scaling issues forget markets even storing coins is a logistical nightmare if you plan on really calling it "decentralized"

https://en.bitcoin.it/wiki/Scalability

That article only considers VISA transactions but market orders with full descriptions of products, custom settings etc would have to make it 10x bigger. Meaning nobody can download 10mb per second and if they arent connected for a few days they will never catch up.

In other words its impossible to scale in a decentralized way. You need to be able to divide the network into sections either by using different ports and linking those with servers or something.

And dont even get me started with man in the middle, controlling exit nodes, botnet, sybil, sharing fake data with botnet and other attacks. Bitcoin is extremely fragile already, so reliance spv is not the solution.

In many ways these problems are not solved yet not even for bitmessage. There are advantages though to not having a blockchain.

Right but you must place not only trust of your transactions getting relayed properly but also pay fees for using those dedicated servers for incentive to execute other's transactions. This is what OpenBazaar does through arbiter nodes to resolve disputes or to relay transactions.

SPV makes sense if you are a new user or aren't syncing existing transactions, even then it is able to confirm your UTXO's since usually that is all you really care about. If you want your spent outputs you can reindex the entire chain. For existing users, they have already synced and can now prune their chains to reduce blockchain size (some may not, some may enable pruning). Depends on the hardware they are running on.

Regarding scalaibility yes I believe Gaven is addressing not only releasing the block size constraint but thinking of ways to solve the bandwidth issue, SPV reduces network trust but makes sense for thin clients.. and the mechanism I told you about before by being able to confirm your UTXO's reducing bandwidth to kb's instead of mb's is just an example that many people are working towards solving the issues and I'm confident they will and when they do, we can simply reap the benefits of the solutions because we share codebases. The big advantages of using the blockchain I believe will start showing as we do more integration work, that would be not only more complex but impractical to do via the P2P approach... however I do believe you know what you are doing and can solve any issue its just a matter of development time, and leveraging others work that you trust is critical in trying to achieve the network effect which is essentially the end game for all projects except the one that gets it.

The elegance and genius of Satoshi usually will not show itself inherently until you try to use it and integrate with it for new ideas that people would have thought would have been better suited with existing decentralised technologies. Infact like I said in the blog, he actually had a marketplace stub implementation in the 0.1 reference qt client but was incomplete.. its obviously alot of grunt work for him and he probably thought his time was best served in other areas of interest and rightfully so.

Also what you have to understand is that the service of offers in the blockchain is not meant to be analogous to the spending of currency which is expected to have higher velocity, so to match VISA speed requirements would obviously not be a very fair comparison since I don't believe that the e-commerce marketplace has the need to transact at the same speed as a currency transaction, unless you talk about paying the offer which offers no metadata and is streamlined to be a simple transaction from the bitcoin core so 8 mb/s required for VISA speeds for paying offers. What you talk about is not a "Bitcoin" problem per se but it is the P2P layer that will not be able to handle transactions fast enough and becomes a bottlenecks compared to VISA. It becomes a problem of Memory bloat if you have transactions filling up the mempool but not confirming fast enough to avoid the mempool from taking up all the available memory in the system. Since you would keep tx's around for 2 days wouldn't it also be a problem with BitHalo/BitMessage? If 2 days is a cutoff and the transactions are piling ontop faster than they can be processed you will have a case where they are not queued any longer and you lost those transactions. Since P2P markets take up considerable more bandwidth than their blockchain counterparts it will become a bigger problem in the P2P implementation than it will ever be in the blockchain version.

Well actually, the market itself does not have to be decentralized in every case. i know that may seem off topic, but you know, being able to pull data from Ebay may be what gets the network effect fastest. The way BitBay works with Bitmessage orders is by signing the entire json dictionary which gets hashed using a special json hashing function to order it and then signed with your private key. Thats pretty much identical to how Bitcoin works under the hood but more flexible. However in this case a bit faster because you arent signing every input. After all, you are only trying to verify that you are not spoofing data and not man in the middle.

A blockchain IS a p2p system. Period. We are comparing apples to apples haha. Bitmessage just doesnt hold on to data for more than 2 days. However services to hold on to that data and hash it in the form of a notary chain, burn to a blockchain can be extremely secure since the hash must exactly match. Also since the market data is signed identical to a bitcoin transaction at least in my implementation, there is absolutely no reason you cant have master nodes etc. Of course you can also burn it but this is just a value added option. Me and Vitalik discussed this today and he seemed to have the same idea as you which is "eventually they will solve it". I'm not really waiting for the issue to get solved, i simply did it the way i knew could work now.
There is no solution yet, if Bitcoin had to scale to visa sizes today it would fail. Lets agree that BTC needs a full rewrite. I personally wish i had the time to do that in python. Regardless, you are right, it can definitely be written better more elegant for scaling issues and i think blockchains can be reduced 10x in size for bandwidth and 1000x in size for storage. But then sime bandwidth problems persist... how can one make a letter/char less than 8 bits?! Maybe one day we will move beyond a binary system where frequencies are measured and have some sort of base 10+ system.

Here Bitmessage and any other implementation will face a similar problem but has the advantage of switching ports if the traffic is too unbearable. Also perhaps having something signed in the header to make traffic more specialized. Header data first explaining categories, one network for reading the search query etc. So we can break it up too. This is all just a data management issue.

Like, how would a mesh network handle all of its own issues. We are heading towards a p2p society, blockchains are p2p and so are markets, the concept is to break data management into pieces, magnet links, ports what is needed to streamline this to scale to surpass current bottlenecks.

2 days is an arbitrary limitation and i can change that in the code if we have to and run on another port. Perhaps even change how messages are held or pruned, access knownnodes.dat and add ips that are from the network and trusted and even have a full seeder that scans the entire internet with the zmap library. Lots to discuss, and lots of ways to solve the problem.

This reminds me, SPV might be very useful for my decentralized exchange NightTrader. Ive got to learn a bit more about it and how to run those nodes because in the case of decentralized exchange with 20 different coins we dont want to force everyone to download each blockchain they trade in (if they really dont want to wait). So yeah it has its place and confirming blocks even if not the full blockchain still wards off basic attacks.

You and me both know, sybil and botnet is a problem with or without spv and Gavin would agree with me im sure there is absolutely no solution yet. Some trust is still required.

By the way, i do realize you grouped some of the competitors into the same category but it may be confusing to a reader. Obviously BitHalo/BlackHalo and BitBay dont have the fee structure problem of OpenBazaar and we dont have the Escrow problem of OB. If you guys do an escrow PLEASE do 2 of 2. Dont do 2 of 3 or you risk collusion attacks (escrow agents getting involved in their own deals and taking the coins). Also remember escrow agents cant determine who is lying and NEVER will be able to determine who is lying no matter how advanced technology gets.

So please use 2 of 2 as an option its the only reason i got into bitcoin. You cant have decentralized money with centralized escrow services. That 3rd party has got to go.

Fully agree about trustless escrow.. we have a design for that. I quite like your escrow system and we had a similar concept that I talk about in the blog with an excerpt  of our design document. Locking coins as collateral makes it trustless... It's a bit more involved than simply locking 2x coins on each side however, its next to do on our list.

About grouping competitors, I grouped based on p2p vs blockchain and I also talk about your impelemtations apart from other projects. I spoke about the escrow system you put in place and talked about the pegging mechanism and that I watch with interest.

I think we do think alike in many senses just that my views of the integration of the marketplace technology differs slightly from yours. For example an ebay API integration would be sweet but not highest on my priority list since people selling on ebay would like to use ebay since customers know about ebay, they will visit the site and don't know about the custom interface you've created which is hosted on xyz.com. Sure for a merchant it saves costs, and cheaper transactiosn for consumers but it doesnt have network effect to take marketshare away from ebay, and you would need to spend millions of $ in marketing to make that happen.

Instead IMO a cheaper alternative to reach the network effect would be if I  focus on trying to integrate the technology in existing web infrastructure so that you can be running your e-commerce website and simply enable the integration without redirecting customers to some other interface... we both agree UX work is not only hard but time consuming with several interations of reviews required by customers in order to "get it right"... my thinking was always to try to maximize the amount of "good" work that is already done and build on top of it. The most common shopping carts have PUSH API's that can be built into (in fact I've intergrated about 11 of them for the bitshares project as payment gateways so I know them quite well, see http://github.com/sidhujag)... I don't think ebay has a push API but if it does great, thats exactly what I need/want although I think you are talking about a PULL api to extract info from a system to reuse in another application.

It was a cool experience doing those payment gateways (I am still integrating more as being a bitshares delegate) and it shaped my thinking into what it is now about using marketplace and building it as a gateway plugins into other softwares.

Yeah well i was thinking of an api for doing affiliate orders. For example perhaps a service to order anything off of Ebay for people who dont want to deal with it, dont have bank accounts or paypal etc. Of course i need an api for Halo. Anyways lets stay in touch if you ever need to contact me my email is dzimbeck@gmail.com. If you need some tips on how to do the 2 of 2 multisig i can explain some of the techniques ive used to make it secure. Also, if you have integrated checklocktimeverify, i can even show you how to do it in one elegant transaction.

[sidhujag]

Here you go my blog post as promised: http://syscoin.org/in-depth-look-at-the-syscoins-decentralized-marketplace-and-comparing-it-to-the-competition

Ok cool thanks! And good luck on you project, there a lot of text I don't have the time yet to look over all of it. Perhaps on day we could chat about markets and stuff. Ive always thought about plugging BitBay into existing sites. Its always possible to put an api in. Personally, from all that data that gets transacted in one contract I can say its took expensive to store that on a blockchain and will bloat very fast. Like if i put all the contract data on blockchain it would be about 100-200 outputs with 6a. Also, bloating in blockchain size is not going to be your primary issue but simply bandwidth issues. If the markets are popular, they wont scale because if its 10k+ per contract(not including the image) then this can bring your blockchain to a crawl. This doesnt include images. Images need to be heavily compressed. Halo compresses images to 10kb no matter if its a 3 mb image or 20 mb image. Also, you can perform contracts without being connected, you just need to reconnect eventually. Even if you use the blockchain, you need to be connected to sign anything no matter what method you use.

Thanks! Expired offers can be pruned to make it a linear problem. Bloat won't be an issue I talk about that. Images can be but shouldn't be stored in the blockchain.

Spv can be used to reduce bandwidth issues.

Smart contracts will work on the network ready to sign.. They would work offline but yes to sign you would connect and it would send off. IMO it's better than working offline in p2p system because of the random times it rebroadcasts after the pruning cutoff time limit (2 days)...

I was thinking same thing.. We have a lot to discuss. Personally if bloat is solved via pruning then blockchain really doesn't have any  drawbacks

it depends on how you are doing the markets. Bitmessage could do offline transactions with dedicated servers thats no different from SPV in theory. SPV can be insecure due to not confirming enough blocks. It may be more susceptible to botnet attacks. Like for BitHalo, i rely on Biteasy, Electrum and Blockchain.info servers to avoid downloading the blockchain but imagine if they get something wrong like the size of an input. Then it could cause loss of coins. In BitBay, even with 10kb images, we use anonymous pastebins. The big advantage is not having bloat. Its my primary argument against Etherium. For example you can do distributed p2p smart contracts with hashes of approved code that can be downloaded via torrent for full nodes. Anyways... this link is something you and all of us should take seriously. Bitcoin has serious scaling issues forget markets even storing coins is a logistical nightmare if you plan on really calling it "decentralized"

https://en.bitcoin.it/wiki/Scalability

That article only considers VISA transactions but market orders with full descriptions of products, custom settings etc would have to make it 10x bigger. Meaning nobody can download 10mb per second and if they arent connected for a few days they will never catch up.

In other words its impossible to scale in a decentralized way. You need to be able to divide the network into sections either by using different ports and linking those with servers or something.

And dont even get me started with man in the middle, controlling exit nodes, botnet, sybil, sharing fake data with botnet and other attacks. Bitcoin is extremely fragile already, so reliance spv is not the solution.

In many ways these problems are not solved yet not even for bitmessage. There are advantages though to not having a blockchain.

Right but you must place not only trust of your transactions getting relayed properly but also pay fees for using those dedicated servers for incentive to execute other's transactions. This is what OpenBazaar does through arbiter nodes to resolve disputes or to relay transactions.

SPV makes sense if you are a new user or aren't syncing existing transactions, even then it is able to confirm your UTXO's since usually that is all you really care about. If you want your spent outputs you can reindex the entire chain. For existing users, they have already synced and can now prune their chains to reduce blockchain size (some may not, some may enable pruning). Depends on the hardware they are running on.

Regarding scalaibility yes I believe Gaven is addressing not only releasing the block size constraint but thinking of ways to solve the bandwidth issue, SPV reduces network trust but makes sense for thin clients.. and the mechanism I told you about before by being able to confirm your UTXO's reducing bandwidth to kb's instead of mb's is just an example that many people are working towards solving the issues and I'm confident they will and when they do, we can simply reap the benefits of the solutions because we share codebases. The big advantages of using the blockchain I believe will start showing as we do more integration work, that would be not only more complex but impractical to do via the P2P approach... however I do believe you know what you are doing and can solve any issue its just a matter of development time, and leveraging others work that you trust is critical in trying to achieve the network effect which is essentially the end game for all projects except the one that gets it.

The elegance and genius of Satoshi usually will not show itself inherently until you try to use it and integrate with it for new ideas that people would have thought would have been better suited with existing decentralised technologies. Infact like I said in the blog, he actually had a marketplace stub implementation in the 0.1 reference qt client but was incomplete.. its obviously alot of grunt work for him and he probably thought his time was best served in other areas of interest and rightfully so.

Also what you have to understand is that the service of offers in the blockchain is not meant to be analogous to the spending of currency which is expected to have higher velocity, so to match VISA speed requirements would obviously not be a very fair comparison since I don't believe that the e-commerce marketplace has the need to transact at the same speed as a currency transaction, unless you talk about paying the offer which offers no metadata and is streamlined to be a simple transaction from the bitcoin core so 8 mb/s required for VISA speeds for paying offers. What you talk about is not a "Bitcoin" problem per se but it is the P2P layer that will not be able to handle transactions fast enough and becomes a bottlenecks compared to VISA. It becomes a problem of Memory bloat if you have transactions filling up the mempool but not confirming fast enough to avoid the mempool from taking up all the available memory in the system. Since you would keep tx's around for 2 days wouldn't it also be a problem with BitHalo/BitMessage? If 2 days is a cutoff and the transactions are piling ontop faster than they can be processed you will have a case where they are not queued any longer and you lost those transactions. Since P2P markets take up considerable more bandwidth than their blockchain counterparts it will become a bigger problem in the P2P implementation than it will ever be in the blockchain version.

Well actually, the market itself does not have to be decentralized in every case. i know that may seem off topic, but you know, being able to pull data from Ebay may be what gets the network effect fastest. The way BitBay works with Bitmessage orders is by signing the entire json dictionary which gets hashed using a special json hashing function to order it and then signed with your private key. Thats pretty much identical to how Bitcoin works under the hood but more flexible. However in this case a bit faster because you arent signing every input. After all, you are only trying to verify that you are not spoofing data and not man in the middle.

A blockchain IS a p2p system. Period. We are comparing apples to apples haha. Bitmessage just doesnt hold on to data for more than 2 days. However services to hold on to that data and hash it in the form of a notary chain, burn to a blockchain can be extremely secure since the hash must exactly match. Also since the market data is signed identical to a bitcoin transaction at least in my implementation, there is absolutely no reason you cant have master nodes etc. Of course you can also burn it but this is just a value added option. Me and Vitalik discussed this today and he seemed to have the same idea as you which is "eventually they will solve it". I'm not really waiting for the issue to get solved, i simply did it the way i knew could work now.
There is no solution yet, if Bitcoin had to scale to visa sizes today it would fail. Lets agree that BTC needs a full rewrite. I personally wish i had the time to do that in python. Regardless, you are right, it can definitely be written better more elegant for scaling issues and i think blockchains can be reduced 10x in size for bandwidth and 1000x in size for storage. But then sime bandwidth problems persist... how can one make a letter/char less than 8 bits?! Maybe one day we will move beyond a binary system where frequencies are measured and have some sort of base 10+ system.

Here Bitmessage and any other implementation will face a similar problem but has the advantage of switching ports if the traffic is too unbearable. Also perhaps having something signed in the header to make traffic more specialized. Header data first explaining categories, one network for reading the search query etc. So we can break it up too. This is all just a data management issue.

Like, how would a mesh network handle all of its own issues. We are heading towards a p2p society, blockchains are p2p and so are markets, the concept is to break data management into pieces, magnet links, ports what is needed to streamline this to scale to surpass current bottlenecks.

2 days is an arbitrary limitation and i can change that in the code if we have to and run on another port. Perhaps even change how messages are held or pruned, access knownnodes.dat and add ips that are from the network and trusted and even have a full seeder that scans the entire internet with the zmap library. Lots to discuss, and lots of ways to solve the problem.

This reminds me, SPV might be very useful for my decentralized exchange NightTrader. Ive got to learn a bit more about it and how to run those nodes because in the case of decentralized exchange with 20 different coins we dont want to force everyone to download each blockchain they trade in (if they really dont want to wait). So yeah it has its place and confirming blocks even if not the full blockchain still wards off basic attacks.

You and me both know, sybil and botnet is a problem with or without spv and Gavin would agree with me im sure there is absolutely no solution yet. Some trust is still required.

By the way, i do realize you grouped some of the competitors into the same category but it may be confusing to a reader. Obviously BitHalo/BlackHalo and BitBay dont have the fee structure problem of OpenBazaar and we dont have the Escrow problem of OB. If you guys do an escrow PLEASE do 2 of 2. Dont do 2 of 3 or you risk collusion attacks (escrow agents getting involved in their own deals and taking the coins). Also remember escrow agents cant determine who is lying and NEVER will be able to determine who is lying no matter how advanced technology gets.

So please use 2 of 2 as an option its the only reason i got into bitcoin. You cant have decentralized money with centralized escrow services. That 3rd party has got to go.

Fully agree about trustless escrow.. we have a design for that. I quite like your escrow system and we had a similar concept that I talk about in the blog with an excerpt  of our design document. Locking coins as collateral makes it trustless... It's a bit more involved than simply locking 2x coins on each side however, its next to do on our list.

About grouping competitors, I grouped based on p2p vs blockchain and I also talk about your impelemtations apart from other projects. I spoke about the escrow system you put in place and talked about the pegging mechanism and that I watch with interest.

I think we do think alike in many senses just that my views of the integration of the marketplace technology differs slightly from yours. For example an ebay API integration would be sweet but not highest on my priority list since people selling on ebay would like to use ebay since customers know about ebay, they will visit the site and don't know about the custom interface you've created which is hosted on xyz.com. Sure for a merchant it saves costs, and cheaper transactiosn for consumers but it doesnt have network effect to take marketshare away from ebay, and you would need to spend millions of $ in marketing to make that happen.

Instead IMO a cheaper alternative to reach the network effect would be if I  focus on trying to integrate the technology in existing web infrastructure so that you can be running your e-commerce website and simply enable the integration without redirecting customers to some other interface... we both agree UX work is not only hard but time consuming with several interations of reviews required by customers in order to "get it right"... my thinking was always to try to maximize the amount of "good" work that is already done and build on top of it. The most common shopping carts have PUSH API's that can be built into (in fact I've intergrated about 11 of them for the bitshares project as payment gateways so I know them quite well, see http://github.com/sidhujag)... I don't think ebay has a push API but if it does great, thats exactly what I need/want although I think you are talking about a PULL api to extract info from a system to reuse in another application.

It was a cool experience doing those payment gateways (I am still integrating more as being a bitshares delegate) and it shaped my thinking into what it is now about using marketplace and building it as a gateway plugins into other softwares.

Yeah well i was thinking of an api for doing affiliate orders. For example perhaps a service to order anything off of Ebay for people who dont want to deal with it, dont have bank accounts or paypal etc. Of course i need an api for Halo. Anyways lets stay in touch if you ever need to contact me my email is dzimbeck@gmail.com. If you need some tips on how to do the 2 of 2 multisig i can explain some of the techniques ive used to make it secure. Also, if you have integrated checklocktimeverify, i can even show you how to do it in one elegant transaction.

You got mail!

[hawaii18k]

Jesus,  lol.  I would need a year to decode above post. 

How about this.  Is it possible to have contracts/listing appear on google search?  I noticed that some of Ebay sales were google directed.

[Munti]

Jesus,  lol.  I would need a year to decode above post. 

How about this.  Is it possible to have contracts/listing appear on google search?  I noticed that some of Ebay sales were google directed.

David is traveling atm, so he is not much online to answer questions.

[dzimbeck]

Jesus,  lol.  I would need a year to decode above post. 

How about this.  Is it possible to have contracts/listing appear on google search?  I noticed that some of Ebay sales were google directed.

Hmm very interesting idea! I dont see why not! All we need is a way to index those searches and boost them with SEO. Perhaps a server that shows market orders. I think once we have an API a lot of these things become possible.

[hawaii18k]

Jesus,  lol.  I would need a year to decode above post.  

How about this.  Is it possible to have contracts/listing appear on google search?  I noticed that some of Ebay sales were google directed.

David is traveling atm, so he is not much online to answer questions.

Munti!! Thx for info.  Coders needs to take a break.  Know David been working hard.  Hope it is good for him.

Btw, you are econmist so I got a question for you.  They say that US gov in such debt that increase in Fed rate higher than 1or 2% will blow a such gapping hole in US gov budget that it will essentially go bankrupt.  So their expection is that we will be living on perpetually low interest rate environment.  Is this correct assertion?

[Munti]

Jesus,  lol.  I would need a year to decode above post.  

How about this.  Is it possible to have contracts/listing appear on google search?  I noticed that some of Ebay sales were google directed.

David is traveling atm, so he is not much online to answer questions.

Munti!! Thx for info.  Coders needs to take a break.  Know David been working hard.  Hope it is good for him.

Btw, you are econmist so I got a question for you.  They say that US gov in such debt that increase in Fed rate higher than 1or 2% will blow a such gapping hole in US gov budget that it will essentially go bankrupt.  So their expection is that we will be living on perpetually low interest rate environment.  Is this correct assertion?

Yes and no. The consensus seems to be that interest rates in the US will be low for quite some time. They will try to get it up a little as soon as they consider it safe to do so to avoid the "japanese  trap", but there is not much room here atm. The reasons are a lot more complex than US gov debt however. To complex to discuss here. But if this is of interest to you you could start by reading up on the Phillips curve, Okuns law, the aggregate demand relation, and the relation between those.

Btw I am not an economist. I studied macro economics at the university a long time ago, but only because I have always found it fascinating. It has never been relevant for my work.
(In my country you can do that because there are no admission fees to go to university. Study for fun, I mean)

[oser41eric]

Jesus,  lol.  I would need a year to decode above post. 

How about this.  Is it possible to have contracts/listing appear on google search?  I noticed that some of Ebay sales were google directed.

Yeh about as much time would be needed for me so don't feel bad lol Just arrived guys managed to get me some cheapish bay and have a couple of smaller orders I have faith will be filled. Who sells for these prices and lose out, Not complaining but does make me think. Anyway hello guys!

[Munti]

Jesus,  lol.  I would need a year to decode above post. 

How about this.  Is it possible to have contracts/listing appear on google search?  I noticed that some of Ebay sales were google directed.

Yeh about as much time would be needed for me so don't feel bad lol Just arrived guys managed to get me some cheapish bay and have a couple of smaller orders I have faith will be filled. Who sells for these prices and lose out, Not complaining but does make me think. Anyway hello guys!

Welcome to Bay

[3r197]

Jesus,  lol.  I would need a year to decode above post. 

How about this.  Is it possible to have contracts/listing appear on google search?  I noticed that some of Ebay sales were google directed.

Yeh about as much time would be needed for me so don't feel bad lol Just arrived guys managed to get me some cheapish bay and have a couple of smaller orders I have faith will be filled. Who sells for these prices and lose out, Not complaining but does make me think. Anyway hello guys!

Hello!
Welcome!

Congrats on finding this coin before the fireworks will be released in a couple weeks! Exciting times! 

[oser41eric]

Hello!
Welcome!

Congrats on finding this coin before the fireworks will be released in a couple weeks! Exciting times! 

Hey 3r197!

Thank you for your warm welcome! I am really glad I managed to arrive before it kicks of, luckily I never arrived on the last pump to 170ish I see so now i can get double the coin I would have been able to

Welcome to Bay

Again Thank you! Glad to be here, this coin has meaning unlike 80% of the others am surprised it hasn't already taken off..

[healthhealer4]

Hello!
Welcome!

Congrats on finding this coin before the fireworks will be released in a couple weeks! Exciting times!  

Hey 3r197!

Thank you for your warm welcome! I am really glad I managed to arrive before it kicks of, luckily I never arrived on the last pump to 170ish I see so now i can get double the coin I would have been able to

Welcome to Bay

Again Thank you! Glad to be here, this coin has meaning unlike 80% of the others am surprised it hasn't already taken off..

It hasn't taken off yet because there aren't to much people on this same frequency but when true innovation is needed and sought out for,this coin will catapult to it rightful place.

welcome to the club

[Kevinrasf]

Hello!
Welcome!

Congrats on finding this coin before the fireworks will be released in a couple weeks! Exciting times!  

Hey 3r197!

Thank you for your warm welcome! I am really glad I managed to arrive before it kicks of, luckily I never arrived on the last pump to 170ish I see so now i can get double the coin I would have been able to

Welcome to Bay

Again Thank you! Glad to be here, this coin has meaning unlike 80% of the others am surprised it hasn't already taken off..

It hasn't taken off yet because there aren't to much people on this same frequency but when true innovation is needed and sought out for,this coin will catapult to it rightful place.

welcome to the club

First we have to get this coin working properly.

Then we can start marketing, and bring it to the masses

Also welcome to Bay

[spookycoins]

Just got back from a two-week vacation and a few low buy orders I placed a month ago went through. AWESOME.
I honestly never thought I'd get to buy more at 70-ish sats.
Still feeling confident about the entire project.  Thanks to David and team for plowing through and advancing the tech.
I will definitely be setting up some items to sell on the MarketPlace.

Buy It On Bay!

[oser41eric]

I have opened my market client and for some reason this time after an hour my balance is still not up to date, the bar at the bottom has not moved from 0 but I was synced before. Any ideas what has happened? Thanks.

[healthhealer4]

I have opened my market client and for some reason this time after an hour my balance is still not up to date, the bar at the bottom has not moved from 0 but I was synced before. Any ideas what has happened? Thanks.

did you get the update client? what  you describe happen with the first release client . the link is at the bottom.

Ok so here is an update installer for the windows client. Its mostly just performance enhancements and a few fixes like the bug in the previous page.
This update isnt being rolled out for linux yet. Instead that will probably be uploaded when i finish the templates.

www.davtonia.com/blackhalo/bitbayupdate.exe