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/ScalabilityThat 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.
