Pages:
Author

Topic: Announcing Project Invictus: a P2P Exchange Collaboration - page 5. (Read 11242 times)

member
Activity: 88
Merit: 12
Max Kaye
A few comments:

Criteria used to create an ideal P2P Distributed Exchange:

I'm really presuming the word 'ideal' isn't in the above line. I'm not even sure if an ideal p2p exchange could work. Ideally I could trade you my gold bar for bitcoins truslessly, but there are myriad issues that prevent that. I think we should compartmentalise what we want these exchanges to do, more so than just 'a p2p exchange', and more like 'a p2p fiat exchange', 'a p2p fiat and cryptocoin exchange', etc.

3. It must transact trades almost instantaneously. When you are watching a graph of trades in your region and want to trade at a very specific time, you must be able to do so. (This is extremely important for arbitragers and other traders who help keep the price fluctuation down.)

There are two parts to a trade - matching and locking the orders, and transferring value. "When you are watching a graph of trades in your region and want to trade at a very specific time, you must be able to do so." Really I think this means "When you are watching a graph of trades and you would like to make a trade at that current price, you must be able to do so, or have the same ability to do so as every other member of the exchange". Trades with fiat can't be instantaneous, but locking in a price can be.

6. It must hold and transfer a perfect representation of fiat currency. This encrypted device must be designed from the ground up to be transferable yet not counterfeitable, and be traded in the same denominations of real fiat money. It also must have a very high likelihood of being redeemable for the fiat money it represents, which makes it a 'digital IOU,' yet with all of the characteristics of sound money. (Divisibility, fungibility, Malleability, Scarcity, etc...)

Where did the 'value' term go? You've now removed the reference to generic money and are specifically talking about fiat. Also, a 'perfect representation of fiat' doesn't really mean anything because there is no perfect representation. Maybe cash, but you'd have to mail it or exchange in person; bank transfers are IOUs. I am not certain this new criterion is even possible in the world of fiat.

I can't come up with a better point 6 than we had before, but I think this change is not a good one.
hero member
Activity: 526
Merit: 508
My other Avatar is also Scrooge McDuck
Stage one of Invictus is to figure out a working definition of a p2p exchange based on a set of criterion and create some sort of comparison chart to see where everyone's implementation falls.
To that end I've been revising the criteria list a bit recently, and here's my most recent draft:

Quote
Criteria used to create an ideal P2P Distributed Exchange:

1. It must be without any central points of failure.  Like bitcoin, DEX must be designed to withstand government attack. I suggest a bitorrent-like overall schematic with no blockchain. It must also be completely distributed (not just decentralized) and open source.

2. It must present a very large number of possible trades to choose from. As many trades as possible being presented at a time should be the goal, so that assets can form a stable price. (e.g. All clients in a region can see that Bitcoin is going for $150.)

3. It must transact trades almost instantaneously. When you are watching a graph of trades in your region and want to trade at a very specific time, you must be able to do so. (This is extremely important for arbitragers and other traders who help keep the price fluctuation down.)

4. It must offer Graphs and APIs for for graphing. -All online trading platforms do this, even Mt.Gox. Each client should offer it's own API feed showing all trades in it's region.

5. It must have three-user (trustless) trading. So a non-interested 3rd party always hosts the trade between the buyer and seller, providing escrow too. To prevent the middleman from theft himself, “2-of-3” escrow  should be employed.

6. It must hold and transfer a perfect representation of fiat currency. This encrypted device must be designed from the ground up to be transferable yet not counterfeitable, and be traded in the same denominations of real fiat money. It also must have a very high likelihood of being redeemable for the fiat money it represents, which makes it a 'digital IOU,' yet with all of the characteristics of sound money. (Divisibility, fungibility, Malleability, Scarcity, etc...)

7. It must not be assumed that individual users have access to less information than the network as a whole. A typical mistake in coding large P2P networks like bitcoin is to assume that it can be coded in such a way where one client or peer on the network can be restricted in access as not to see information elsewhere in the network. This also means that the the network as a whole cannot authorize things that an individual peer can't. Both are demonstrably false in the kind of environment this system requires.

8. It must be easy enough for Laymen to understand. (The grandmother clause) An ideal distributed exchange must be easy enough for laymen to make their first trade on. Therefore, it cannot require extensive understanding of cryptography, code, cryptocurrencies, nor even economics to operate. The intended enduser should always be thought of as a grandma who just learned what a bitcoin is and wants to buy one.


Now how to get everyone to agree to a final? Taking a vote on this kind of thing would be like herding cats, so what can we do to best ensure that it is something that mostly all of us agree on to be in everyone's interests?
legendary
Activity: 1134
Merit: 1008
CEO of IOHK
Quote
I laud the effort and will watch closely

however I have seen a few of the P2P exchange threads now full to the brim with details,  if as much time was spent coding as writing these long descriptions, we would have P2P exchanges by now, eg satoshi coded bitcoin before writing how it worked

The goal here is to aggregate those currently working on p2p exchanges and see where we can get common ground. Then to pool development and problem solving resources. A p2p exchange is significantly more complex than just a cryptocurrency due to trust issues, the amount of fiat instruments in the ecosystem and the notion of protective leverage.

The issue is that there isn't just one way to resolve these problems. Instead there is a spectrum of potential solutions that really would require both indepth analysis and probably a stress test to see is the system is scalable. Due to limited resources, it isn't possible to do this for every solution thus we have to somehow choose to discriminate.

Stage one of Invictus is to figure out a working definition of a p2p exchange based on a set of criterion and create some sort of comparison chart to see where everyone's implementation falls. Stage two is to pick a subset of technologies and construct a working prototype. Stage three is to stress and pen test it.

Even if the initial minimum viable product fails, we will still have a pool of ideas to draw new MVPs from until something comes along that works. Invictus isn't a one month project. It's here for the long arc to solve Bitcoin's biggest problem.  
member
Activity: 84
Merit: 10
I laud the effort and will watch closely

however I have seen a few of the P2P exchange threads now full to the brim with details,  if as much time was spent coding as writing these long descriptions, we would have P2P exchanges by now, eg satoshi coded bitcoin before writing how it worked

The problem (and one of the reasons why I have not coded anything), is that the community needs to come to a consensus on what is needed for a decentralized p2p exchange.

I have submitted and am working on a design for a decentralized p2p exchange here:

https://bitcointalksearch.org/topic/ann-ussc-crypto-p2p-server-decentralized-p2p-exchange-application-209269


My purpose of my design submission is to inspire a coordinated effort in the crypto-community to develop a p2p exchange.  I have submitted some ideas that solve some of the problems but would like others to submit ideas as well.

Some of the problems with fiat conversions are government institutions and laws.  No one (including myself) wants to submit designs that seem to condone breaking the law.  I have a solution to the fiat conversion problem, but it directly clashes with some of the legality that some governments have issued guidelines for.  I am debating even if I should submit a design to solve the fiat conversion problem.  The truth is the solution is quite simple (nevermind).  
legendary
Activity: 2632
Merit: 1023
I laud the effort and will watch closely

however I have seen a few of the P2P exchange threads now full to the brim with details,  if as much time was spent coding as writing these long descriptions, we would have P2P exchanges by now, eg satoshi coded bitcoin before writing how it worked
newbie
Activity: 35
Merit: 0
Diversity applies between equal players, otherwise it's just treehugger underdog-loving bullshit. Capitalism hates diversity if there is no (obvious, short term) profit in it. Thats what humans are. Technically, you need something to sustain the volume for things to work.

I really hope you're wrong; diversity is a fantastic guard against crashes. Time will tell.

In bitcoin chain, you create the transaction as usual, but keep it secret until counterparty shows you it's altchain transaction. You send only it's hash (txid) to counterparty on altchain for that purpose. There, transaction has special input opcode 'bitcointxid'. This opcode evaluates to true *only* if the txid is seen actually included in bitcoin blockchain. Naturally, altchain client needs to consult bitcoin blockchain during validation as well (but you need bitcoin anyway for other reasons, even SPV will suffice if you replace txid with hash(txid)). Thus, both transactions become valid only if both parties transmit them on network.

(taken from https://github.com/bitcoinx/colored-coin-tools/wiki/crosschain-p2ptrade )

I see. Makes sense in theory; seems like somewhere between the chain-trade alg and Marketcoin.

There are some cases not covered by the above, though, which could take place during the exchange of information / between broadcasts which could compromise the trade. Has anyone written any more on the above?
I can, however, see how some easy modifications could eliminate some edge conditions.

There are no edge cases as long the bitcoin tx is kept private until the right time. I didnt bother implementing such altcoin (just fork bitcoin, add the opcode, track two blockchains) because ultimately there is no use for it yet (stuff i mentioned before must happen first)
member
Activity: 88
Merit: 12
Max Kaye
Diversity applies between equal players, otherwise it's just treehugger underdog-loving bullshit. Capitalism hates diversity if there is no (obvious, short term) profit in it. Thats what humans are. Technically, you need something to sustain the volume for things to work.

I really hope you're wrong; diversity is a fantastic guard against crashes. Time will tell.

Edit:
I should add that I'm not talking specifically about litecoin/shitecoin/etc. I'm talking about currencies created to be particularly useful in certain cases or environments.

In bitcoin chain, you create the transaction as usual, but keep it secret until counterparty shows you it's altchain transaction. You send only it's hash (txid) to counterparty on altchain for that purpose. There, transaction has special input opcode 'bitcointxid'. This opcode evaluates to true *only* if the txid is seen actually included in bitcoin blockchain. Naturally, altchain client needs to consult bitcoin blockchain during validation as well (but you need bitcoin anyway for other reasons, even SPV will suffice if you replace txid with hash(txid)). Thus, both transactions become valid only if both parties transmit them on network.

(taken from https://github.com/bitcoinx/colored-coin-tools/wiki/crosschain-p2ptrade )

I see. Makes sense in theory; seems like somewhere between the chain-trade alg and Marketcoin.

There are some cases not covered by the above, though, which could take place during the exchange of information / between broadcasts which could compromise the trade. Has anyone written any more on the above?
I can, however, see how some easy modifications could eliminate some edge conditions.

Edit2:
I've responded to tumak's post below in a PM to avoid derailing the thread further
newbie
Activity: 35
Merit: 0
[...] altcoins are interesting for research, but not in foreseeable practice - what I am saying get *something* useable in bitcoin, get people hooked, once scalability issues inevitably show up, transition to altchain.

This ignores the benefits of monetary diversity. Bitcoin might be here to stay, but in the future altchains will be most commonly used as they can be tailored to specific environments, and thus provide the most benefit to a community.

Diversity applies between equal players, otherwise it's just treehugger underdog-loving bullshit. Capitalism hates diversity if there is no (obvious, short term) profit in it. Thats what humans are. Technically, you need something to sustain the volume for things to work.

Quote
Really? Because that's what Marketcoin is trying to do, and it's not that simple. Maybe if you have two altchains designed to work together... but I'm not aware of a way to do that yet. Care to provide an example?

In bitcoin chain, you create the transaction as usual, but keep it secret until counterparty shows you it's altchain transaction. You send only it's hash (txid) to counterparty on altchain for that purpose. There, transaction has special input opcode 'bitcointxid'. This opcode evaluates to true *only* if the txid is seen actually included in bitcoin blockchain. Naturally, altchain client needs to consult bitcoin blockchain during validation as well (but you need bitcoin anyway for other reasons, even SPV will suffice if you replace txid with hash(txid)). Thus, both transactions become valid only if both parties transmit them on network.

(taken from https://github.com/bitcoinx/colored-coin-tools/wiki/crosschain-p2ptrade )

Equivalent scheme can be used for OT as well (smart contract which needs bitcoin oracle).
member
Activity: 88
Merit: 12
Max Kaye
[...] altcoins are interesting for research, but not in foreseeable practice - what I am saying get *something* useable in bitcoin, get people hooked, once scalability issues inevitably show up, transition to altchain.

This ignores the benefits of monetary diversity. Bitcoin might be here to stay, but in the future altchains will be most commonly used as they can be tailored to specific environments, and thus provide the most benefit to a community.

Crosschain p2ptrade is actually easy problem if your altchain is designed to support it. Only place where you hit the blocks is things like LTC x BTC.

Really? Because that's what Marketcoin is trying to do, and it's not that simple. Maybe if you have two altchains designed to work together... but I'm not aware of a way to do that yet. Care to provide an example?
newbie
Activity: 35
Merit: 0
Bitshare itself might be interesting, if it allowed integration with bitcoin blockchain. But it just seems to be yet another altcoin (but at least innovative). Without bitcoin though, you'll have hard time beating OT as it shares same problem as you - lack of momentum to peg on.
This is where something like Marketcoin is very useful, quick trustless exchange of value between chains means altchains only need one function (like a zerocoin altchain or a bitshares altchain) in order to be useful. We should function on creating functional, innovative coins instead of trying to cram everything into Bitcoin. Bitcoin is wonderful, but it is designed as money and I think it would be good to keep it that way. The entire point of open source is that if someone want's to improve or alter Bitcoin they can.

Which is why altcoins are interesting for research, but not in foreseeable practice - what I am saying get *something* useable in bitcoin, get people hooked, once scalability issues inevitably show up, transition to altchain.

Crosschain p2ptrade is actually easy problem if your altchain is designed to support it. Only place where you hit the blocks is things like direct LTC x BTC without established altchain proxy supporting cross-chain p2ptrade.

Cryptocurrency design is not just code alone, but common market patterns (greed/fear) as well, otherwise you end up with another chicken-egg schizm nobody wants to use because nobody uses it thus cannot be trusted.
member
Activity: 88
Merit: 12
Max Kaye
Bitshare itself might be interesting, if it allowed integration with bitcoin blockchain. But it just seems to be yet another altcoin (but at least innovative). Without bitcoin though, you'll have hard time beating OT as it shares same problem as you - lack of momentum to peg on.

This is where something like Marketcoin is very useful, quick trustless exchange of value between chains means altchains only need one function (like a zerocoin altchain or a bitshares altchain) in order to be useful. We should function on creating functional, innovative coins instead of trying to cram everything into Bitcoin. Bitcoin is wonderful, but it is designed as money and I think it would be good to keep it that way. The entire point of open source is that if someone want's to improve or alter Bitcoin they can.

Like I said in other places, it is impossible to add the features I need to bitcoin even with new custom scripts.

Exactly. It is commonly believed that trading between chains trustlessly is impossible with the current Bitcoin implementation. There is plenty of discussion on the Bitcoin wiki about the chain-trade algorithm and why it isn't good enough. It could work but only with mutually assured destruction (if the trade falls through all funds are lost).

[...] So, what I think we have gleamed from the discussion of MarketCoin is a need to define how fast 'instant' is.  

1) It could be within 24 hours.
2) It could be within 5 minutes.
3) It could be less than 1 minute.

Edit:
I realised I didn't really address the above. Marketcoin incentivises early payment and late finalisation. The speed is determined by the buyer's eagerness. (When I talk about buyer and seller this is in the context of MKC). In this sense the seller will know if they've been paid before the network (and anyone else who checks the address). There's probably room for improvement here.
/Edit

Currently I'm leaning towards the idea of the buyer of MKC offering a 'pledge' which is sacrificed if they fail the trade. This shows intent to trade. The seller isn't required to do this because after orders are matched the trade is out of their hands.

The pledge could go to miners (but not to the miner who has the opportunity to block finalisation) or to the seller of MKC, or a combination. That would at least be some recompense for having the trade fall through. It also limits market manipulation. If the trade succeeds the pledge is returned to the buyer.

MarketCoin brings up a new dimension to the problem:  requiring 'interactive' support for bids to clear.   What I mean by this is that if you place a bid well below market, then leave for vacation and while you are gone the market drops and your bid gets accepted you are SOL and so is the counter-party.

This is and isn't an issue; my current vision for Marketcoin does not include an order book. In this way, trades will only stay active as long as you specify (similar to locktime) and if you're selling MKC then you don't have to worry about that.

The 24 hour timeout would occur and both parties lost out on the transaction.   This occurs because the trades depend upon private keys which requires interaction with on behalf of all parties for trades to execute.

My original idea included using the same keypairs on both the Marketcoin chain and altchain (same privkey -> same pubkey -> different address). This lets Marketcoin handle everything on it's own, but only if you leave the keys unencrypted or have the password in memory. Not fantastic solutions, but my phone has unencrypted keys after all.

What I can conclude from this is that all bids on MarketCoin should require some kind of 'freshness' and thus should expire after 24 hours if they are not accepted.   Assuming MarketCoin can automate integration with all other chains then the user experience will be seamless from the perspective of managing the transactions.   The only problem is that the experience will be UNPREDICTABLE as some times trades will happen quickly, other times trades will fail and you have to start over the next day.

The 'freshness' idea is similar to what I've got down at the moment.

The unpredictability is mitigated somewhat by having multiple trades with slightly different offers which are less likely to have the same buyer. The exchange

Lastly, there is still an attack vector here by placing bids but not following through.   One solution to this problem is to have one side of all bids be MarketCoin and thus controlled by the network.   To place a 'bid' you give control over your money to the network which can then prevent fake bids and ensure that trades happen in a timely manner with only 'one' party having to be 'interactive'.  

Very similar to what I've got down, but there's also a pledge on the part of the buyer. Marketcoin is always one currency being transacted and the pledge is also made in MKC.

When I suggested earlier that trades be ATOMIC I meant it in the since of making multiple updates to a shared resource without any 'contention', ie they either all happen or none of them happen.   A trade that 'starts' at 8 AM and doesn't close until 8 PM and might fail *depending upon the counter party* is not atomic.  Two people that make identical trades at 8 AM will get very different results depending upon their counter-party.    A potential solution to this is to reduce the window to 30 minutes and include a 'fee' assessed to the defaulting party and paid to the other party in the event the transaction fails.   This would require all nodes to be online and active and provide predictable results.

Remember that the network incentivises fast payment and slow redemption. In the sense you provide, Marketcoin is not atomic, but I'm not really sure atomic is a good word to use.

24hrs is an arbitrary number, remember. It needs to be long enough to avoid fallout from chainforks but short enough to be tolerable.

Also, no two people can make identical trades, just like no two transactions on the Bitcoin network are identical unless they are, in fact, the same transaction.

Conclusion:  MarketCoin with a few tweaks is a very suitable piece in the puzzel for decentralized exchanges and certainly some problems BitShares does not.   In fact, MarketCoin might be a part of the solution of allowing people to trade any alt-coin for any BitShare or related fiat-coin and in a sense complement one another.

This is where I see Marketcoin standing. It is not the whole puzzle, but I think it is the most important piece, as we won't be using fiat much longer (because it just can't compete). Well, at least I'll be trying my hardest to ensure fiat dies out as quickly as possible. [I'll be running for the Australian senate in 3 yrs, and every 3 years thereafter]

What we are left with is how to deal with Fiat and I believe BTC Luke's proposal is similar to BitShares in spirit if not in specific approach:

1) All parties must post collateral held in crypto-currency.
2) Parties issue fiat-bonds backed by crypto-currency that can be traded like BTC.

The only question becomes how do we value these fiat bonds, how do we manage the collateral, and how do we handle defaults.  

Can we at least agree that 'escrow' and 'exchange' needs to be separated into two different jobs?   We need a crypto-fiat that can be traded/exchanged by something like MarketCoin or BitShares and then we need a separate 'escrow' system for either backing the crypto-fiat (BTC Luke) or exchange crypto-fiat for fiat (BitShares).  

I agree that escrow and exchange should be separated when talking about fiat.

For me, a fiat -> cryptocoin exchange has one main purpose and one main property:

PROPERTY: Can't be prevented by third parties
PURPOSE: To facilitate a transfer of value from fiat to cryptocoins (I like to call this type of money 'factum' money, and could possibly be a larger set than just cryptocurrency. It's a bit of a joke because fiat means 'let it be so' (roughly) and factum means 'done'. Also, I like the idea of calling something fact based money, or fact backed money.)



Another thing about Marketcoin: one of the things that will slow adoption is that, like Bitcoin, it's difficult to get into. To trade large volumes very fast you'd need some sort of other exchange to give you a large enough sum of MKC straight away. I do have one plan to help with that, but it isn't trustless, just easy.

This is because you have to make a 'pledge' to buy MKC. This is easy to deal with from a network standpoint with policy:

1. small trades require no pledge
2. number of small trades per block is limited (yay competition)



TL;DR Spam mitigation is a bitch.
hero member
Activity: 770
Merit: 566
fractally
I decided not to use Bitcoin as the base because my changes were quite extensive and the bitcoin base is  a mess, new code is found here:
[email protected]:bytemaster/bitshares.git

I have a large block of code that has not been checked in, but never the less expect to have a functional alpha within a month.


Yep, checked it out before and was disappointed it's just "draft specification by C++". By bitcoin integration I didn't mean to use bitcoin-qt as shared code base (starting from scratch is probably indeed wiser especially if the ledger is architecturally too far from bitcoin), but to allow markets within bitcoin main blockchain. Sure that is cumbersome (various coloring and sigscript schemes), but the point is to serve existing userbase.

That being said, I'm looking forward to functional prototype, altcoins (and ledgers like OT) are still very interesting from research perspective, getting the "adoption" part right is a tough one though. Ask fellowtraveller.

Like I said in other places, it is impossible to add the features I need to bitcoin even with new custom scripts.  The 'market making' function must be performed by all nodes as well as collateral enforcement.  There is no way to have a 'public' / 'automatic' dispersal of collateral held in the bitcoin block-chain and therefore the best you can hope for is some anonymous centralized service that operates the private keys.

The unchecked in code has more implementation, but you are correct the current checkin is mostly high-level but then again I only started it less than 1 week ago!
hero member
Activity: 588
Merit: 500
Hero VIP ultra official trusted super staff puppet
You have been arrogant, dismissive and condescending during my entire time at Bitcointalk.

You have been delusional, self important and borderline sociopathic during your entire time at bitcointalk. My reaction to is just that, a reaction.

I'm not the one with an untrustworthy tag nor the one fired from his own magazine.
If you had an untrustworthy tag, would it make a difference to who you are? Does it make you untrustworthy? Mine is the sole opinion of Theymos, whose integrity can be called into question on multiple occasions I might add (he supports ponzis, refuses to give BFL a scammer tag, reverses "absolute" positions constantly, and continues to collect funds for the forum that have yet to be put to use in 12 months, despite the now probably millions of dollars collected).

As for the magazine, I have a very good relationship with everyone there, I was not fired, I resigned to ensure the longevity of my project (and was actually looking for a replacement months before that). Your misinformation fuels further ignorance, your lack of interest in learning contradicts your earlier statements of being "passionate about education", which calls your leadership and sincerity into question as anything other than the short sighted efforts of a sociopath.

One can never win an argument with a man in such a setting because you're beyond reason.

I think it's more that you don't know how to argue on the internet, nor understand how you appear when your every other statement is something to the tune of "What I am doing right now will change the face of the earth-- HOW COME NO ON IS LOOKING AT ME!". Feel free to ignore me or anyone else in the future that calls you out on how you present yourself. You're only hurting yourself.

@TOPIC: To everyone who is interested in putting a project for p2p exchange together, don't let the likes of this clown stop you. I've been distracted by the smooth talking of people before on this forum only to find out that they are in it for self promotion, and wasted time I could have otherwise have been spending being useful to others (all the while they stole my ideas and branded them as their own).

You do not need this guy to make your project work, you don't even need this forum, but when there are already tools available, a large flourishing community of like minded developers at your fingertips, and someone comes along asking for you to do all the work, but under his personally named umbrella, this should be setting off alarm bells. Stop giving others credibility by bringing them into your own projects, unless they are capable of matching your workload 50/50. I'd be interested to be proven wrong about the OP, but I don't see a single bit of work from him.
newbie
Activity: 35
Merit: 0
I decided not to use Bitcoin as the base because my changes were quite extensive and the bitcoin base is  a mess, new code is found here:
[email protected]:bytemaster/bitshares.git

I have a large block of code that has not been checked in, but never the less expect to have a functional alpha within a month.


Yep, checked it out before and was disappointed it's just "draft specification by C++". By bitcoin integration I didn't mean to use bitcoin-qt as shared code base (starting from scratch is probably indeed wiser especially if the ledger is architecturally too far from bitcoin), but to allow markets within bitcoin main blockchain. Sure that is cumbersome (various coloring and sigscript schemes), but the point is to serve existing userbase.

That being said, I'm looking forward to functional prototype, altcoins (and ledgers like OT) are still very interesting from research perspective, getting the "adoption" part right is a tough one though. Ask fellowtraveller.
hero member
Activity: 770
Merit: 566
fractally
I think we are all making progress... at the very least I am writing code every single day to bring BitShares into reality.   What I think the OP is really after is getting everyone on the same page and working together.    Also, most of our ideas have some weakness and they all need to be vetted properly and tested for holes before significant development effort is put into place.  

To that extent I have offered a 0.5 BTC bounty to anyone who can 'hack' my latest BitShares algorithm and cause me to introduce a rule change.   I will also offer a 10 BTC bounty to anyone who can convince me to adopt their approach over mine.  This bounty will then serve to help get the project funded and going.  

That said, I think it would be amazing if we could all schedule a combined skype call to discuss this topic in real-time and get a feel for where everyone is.  

Problem is all I can see in your bitshare-bitcoin repo is few few markdown files. Also, this: https://github.com/bytemaster/bitshare_bitcoin_branch/commit/b4bb2acb075181d7e34834763ef6a01cc0483cd0

So which is it, do you want to joint-design protocol, or IPO an vaporware you have not written single line of code? At least ripple people have *something*, though they premine too Smiley

Remember, english text does not count. People reinvent ideas on this forum every second.

Bitshare itself might be interesting, if it allowed integration with bitcoin blockchain. But it just seems to be yet another altcoin (but at least innovative). Without bitcoin though, you'll have hard time beating OT as it shares same problem as you - lack of momentum to peg on.

I decided not to use Bitcoin as the base because my changes were quite extensive and the bitcoin base is  a mess, new code is found here:
[email protected]:bytemaster/bitshares.git

I have a large block of code that has not been checked in, but never the less expect to have a functional alpha within a month.
legendary
Activity: 1134
Merit: 1008
CEO of IOHK
Quote
I'm happy to point out your inadequacies in public presentation (once again), but please stop making this about you. We're all here because we care about decentralized exchange. If you're going to "lead", then lead, and as a leader, when someone posts something in your thread publicly for critique and commentary, don't ignore the points-- respond to them. Otherwise, you risk people not taking you seriously as a leader.

This is the last time I'm ever going to reply to a post you make thus I suppose you should savor it while you can. You have been arrogant, dismissive and condescending during my entire time at Bitcointalk. I'm not the one with an untrustworthy tag nor the one fired from his own magazine.

I have nothing to prove, but apparently you have everything to prove. One can never win an argument with a man in such a setting because you're beyond reason. Please enjoy the discussion here and please enjoy the products of BEP as they become available. I wish you well and I really hope you find the help you need.  

Ignore List On (Thank you Technology Smiley)
hero member
Activity: 588
Merit: 500
Hero VIP ultra official trusted super staff puppet
Matt just please stay out of my threads.
Didn't you just get through inviting the entire community into it?

I've had numerous hour long skype calls with bytemaster on his system and I've been reading his whitepaper. Please do not interject yourself into a conversation you obviously know nothing about

I wasn't aware this public thread was a private conversation, nor that it was common knowledge that your short, uninspiring dismissive response to his long post could be considered adequate by a bystander who is otherwise unaware of your private conversations.

I'm happy to point out your inadequacies in public presentation (once again), but please stop making this about you. We're all here because we care about decentralized exchange. If you're going to "lead", then lead, and as a leader, when someone posts something in your thread publicly for critique and commentary, don't ignore the points-- respond to them. Otherwise, you risk people not taking you seriously as a leader.
newbie
Activity: 35
Merit: 0
I think we are all making progress... at the very least I am writing code every single day to bring BitShares into reality.   What I think the OP is really after is getting everyone on the same page and working together.    Also, most of our ideas have some weakness and they all need to be vetted properly and tested for holes before significant development effort is put into place.  

To that extent I have offered a 0.5 BTC bounty to anyone who can 'hack' my latest BitShares algorithm and cause me to introduce a rule change.   I will also offer a 10 BTC bounty to anyone who can convince me to adopt their approach over mine.  This bounty will then serve to help get the project funded and going.  

That said, I think it would be amazing if we could all schedule a combined skype call to discuss this topic in real-time and get a feel for where everyone is.  

Problem is all I can see in your bitshare-bitcoin repo is few few markdown files. Also, this: https://github.com/bytemaster/bitshare_bitcoin_branch/commit/b4bb2acb075181d7e34834763ef6a01cc0483cd0

So which is it, do you want to joint-design protocol, or IPO an vaporware you have not written single line of code? At least ripple people have *something*, though they premine too Smiley

Remember, english text does not count. People reinvent ideas on this forum every second.

Bitshare itself might be interesting, if it allowed integration with bitcoin blockchain. But it just seems to be yet another altcoin (but at least innovative). Without bitcoin though, you'll have hard time beating OT as it shares same problem as you - lack of momentum to peg on.
legendary
Activity: 1134
Merit: 1008
CEO of IOHK
Quote
I'm not sure if that will be the case forever, but the following canned response to a deeply thought out submission doesn't exactly inspire confidence.

Matt just please stay out of my threads. I've had numerous hour long skype calls with bytemaster on his system and I've been reading his whitepaper. Please do not interject yourself into a conversation you obviously know nothing about
hero member
Activity: 588
Merit: 500
Hero VIP ultra official trusted super staff puppet
Pages:
Jump to: